# Rotation finishes when consumers stop using the old credential

Updating a secret store is one step in a distributed change. The target service and every consumer must agree on which credential works before the old one is retired.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Follow the credential through the system

A database password changes successfully in the secret manager, but a worker loaded the previous value at startup and keeps it in memory. Existing database connections continue working until the pool opens a new connection. The failure appears hours after the rotation job reported success.

Map the secret's target, storage location and consumers. Include scheduled jobs, recovery environments and support tools. Record how each consumer refreshes its value and how long it can retain an old copy.

A rotation schedule without that map can change credentials regularly while leaving availability dependent on accidental connection lifetimes.

## Choose a transition the target supports

Some services allow two valid credentials during a controlled overlap. Others replace one credential directly. The safe sequence depends on those capabilities and the consumer's refresh behaviour.

AWS Secrets Manager documents single-user and alternating-user strategies for supported database rotation through Lambda. Their permission and connection behaviour differs, so choose the strategy for the actual database and application rather than assuming overlap is universal.

### Credential rotation includes consumer adoption

The replacement is established and verified before retirement of the previous credential under the target service's supported model.

1. **Prepare replacement**: Create or update credentials with the intended scope
2. **Verify target**: Prove the new credential performs the required operation
3. **Refresh consumers**: Confirm active and scheduled clients adopt it
4. **Retire previous**: Revoke under the chosen transition and verify failure of old use

## Test use, not just retrieval

A consumer retrieving the new secret proves access to the store. It does not prove that the target accepts the credential or that its permissions are correct.

Perform a safe representative operation under the intended identity. For a database reader, verify the required read and a prohibited write where appropriate. A replacement account with broader access may preserve availability while weakening the boundary.

Keep secret values out of test output. Use version references and operation results to establish adoption.

## Distinguish routine rotation from compromise response

A planned overlap can support availability during routine change. If the old credential is suspected compromised, leaving it valid may be unacceptable under the incident policy.

Define the urgent revocation path and its likely service impact before it is needed. Recovery may require refreshing consumers quickly and reconciling failed operations.

Do not roll back to a compromised credential merely because it is the easiest way to restore connectivity.

## Keep recovery and ownership explicit

Record who owns the target credential, consumer changes and rotation automation. Explain what happens if the process stops after updating the target but before publishing the new version.

Rehearse that partial state and the delayed consumer. Rotation is dependable when the system can move to the replacement, verify its use and retire the old authority without relying on one operator's memory.

## Sources

- [AWS Secrets Manager: rotation strategies](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotation-strategy.html)
- [OWASP: secrets management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)