A credential has leaked. The single most important property of your response is speed, and speed comes from not having to look up syntax under pressure. These are the commands, in the right order, per provider.
Revoke first
The instinct during an incident is to investigate — work out what happened, how bad it is, who did it. That instinct costs you the window in which the attacker still has access.
Revocation takes seconds. Investigation takes hours. Do the fast thing that stops the bleeding, then investigate with the door closed. Nothing you learn in the first hour changes the fact that the key must die.
Deactivate before delete, where you can
AWS supports setting an access key to Inactive before deleting it. That is worth using: if the key turns out to be load-bearing for something nobody documented, reactivating takes a second, whereas a deleted key is gone. Deactivate, confirm nothing broke, then delete.
Where deactivation is not available — Stripe rolls keys, GitHub deletes tokens — go straight to revocation and accept the breakage. A brief outage is cheaper than an open credential.
Prove it worked
Every recipe includes a verification step, because assuming revocation succeeded is how credentials stay live after an incident is declared closed. Make the call with the old key and confirm you get a 401. A dashboard that no longer lists the key is good evidence; a rejected request is proof.
Read the whole audit window
The most commonly skipped step. Pull the provider's audit log for the key's *entire validity period*, not just the day you found the leak. A key committed six months ago may have been used quietly for five of them.
- AWS — CloudTrail, filtered by
AccessKeyId. - Google Cloud — Cloud Logging, filtered by the service account's principal email.
- GitHub — the account or organisation security log.
- Stripe — the events endpoint, plus the dashboard's API request log.
The checklist exists because steps get skipped
Under pressure people revoke, deploy and stop. The three steps that get missed are the ones that matter later: checking whether the same value was reused elsewhere, working out how it leaked, and adding detection so the same path is caught next time. Rotating the key without fixing the leak path means doing this again.
Frequently asked questions
Should I revoke immediately even if it might break production?
Yes, when the credential is confirmed exposed. A brief outage is recoverable; an attacker with a live production key may not be. Where uncertainty exists, deactivate rather than delete so the decision is reversible.
The key was in a public repository for ten minutes. Is that long enough to matter?
Yes. Automated scanners watch the GitHub public event firehose and claim credentials within seconds of a push. Ten minutes is an eternity. Treat any public exposure as compromised regardless of duration.
How do I find every place the key is used before rotating?
You often cannot, which is the argument for the two-key overlap: issue the new key, accept both, watch the provider's last-used timestamp on the old one, then revoke when it goes quiet. The rotation planner sets out that sequence. In a live incident, skip the overlap and accept the breakage.
Do I need to rewrite git history?
Rotation is what revokes access; history rewriting does not. Do it anyway with git filter-repo so the next person to read the repository does not find a credential and waste time on it — but never treat it as the remediation.