Rotate a leaked credential

A leaked key is being used by somebody or it is not, and you cannot tell which. Treat every one as in use. The order below never has a window where the service holds no valid credential, and it ends with proof rather than an assumption.

Steps

1. Find every place it is stored before issuing anything: the secret manager, the deploy platform's environment, CI secrets, any .env committed by accident, and the tool configuration in this product that holds it. A rotation that misses one copy is a second incident on the day something restarts.
2. Issue a new credential at the provider, scoped no wider than the old one. Where the provider supports two live keys, make the new one before revoking anything.
3. Write the new value into the secret manager and into every other place from step 1. Nowhere else — never into a ticket, a chat message, a commit, or a transcript.
4. Restart or redeploy what reads it, then exercise one real call through the service to prove the new key works.
5. Revoke the old one at the provider. This is the step people skip, and skipping it makes the whole exercise decorative.
6. Prove it is dead: one call with the old credential that comes back refused.
7. Look for use. Read the provider's audit or access log for the exposure window and say plainly whether the key was used by anything you do not recognise.
8. Close the exposure itself. If it leaked into a repository, the history still holds it — rotating does not remove it, and the file has to be dealt with separately.

Stop and ask a human

• Before revoking a credential you cannot prove is replaced everywhere (step 4 not done).
• When the provider only supports one live key, so there will be a gap — that needs a chosen moment, not a convenient one.
• When the audit log shows use you cannot account for. That is an incident and someone owns it.

Never

Paste the old or new value anywhere to "check" it, including into a message reporting the rotation is done.