Secrets rotation
Hand over the consumer list with the secret reference
The next operator needs to know who uses a credential, how they refresh it and what a failed transition looks like. A secret-store location alone is not enough.
In this article
Record purpose without recording the value
Document the target service, intended permissions, secret reference and owner. Keep plaintext values out of the runbook.
List every consumer class and its refresh mechanism, including deployment-time injection, runtime retrieval and manual operational use.
Include infrequent jobs and recovery environments. These are often the last places still depending on an old value.
Explain the normal transition
Provide the chosen rotation sequence and evidence for target validity, consumer adoption and previous-credential retirement. Link the maintained automation and safe diagnostic procedure.
State the expected overlap and any session behaviour that affects the result. The operator should know why existing connections may continue while new ones fail.
Keep a partial-state recovery procedure for interruptions between target and secret-store changes.
Separate urgent revocation
Name the incident authority and the procedure for a suspected exposed credential. Explain how that policy differs from routine rotation, including whether overlap is allowed.
Identify the likely service impact and the operation-recovery path for failed or uncertain requests.
Do not leave the next team choosing between security and availability without an agreed decision process.
Rehearse a delayed consumer
Ask the receiving team to run a safe rotation with one worker held on the old version. Verify that they can identify it, refresh it and confirm the final authority state.
Use the exercise to fix missing access, unclear ownership or undocumented refresh behaviour. Remove test copies and temporary grants afterwards.
Schedule review when new consumers are added or authentication changes. The handover remains useful only while its consumer map matches the running system, so maintaining that map belongs to the service's ordinary change process.
Explain the delayed connection failure
Include one timed example in the handover. The secret changes at 10:00, a long-running worker reloads only at startup and its database pool opens a new connection at 10:40. The delayed failure belongs to the 10:00 rotation even though the visible error begins much later.
Show the receiving team where version metadata and connection errors can be correlated without revealing the credential. That evidence helps them choose between refreshing the consumer, repairing a partial rotation and investigating an unrelated network failure.
Primary sources
OWASP: secrets managementReferences checked 11 September 2026.