Secret Rotation vs Revocation for Leaked Secrets

Rotating a leaked secret does not necessarily stop the attacker, because most rotation patterns are built to keep the old value working for a while. Rotation replaces a credential on a schedule and is designed for zero downtime, so it deliberately leaves an overlap window in which old and new values are both accepted. Revocation de-authorises a specific credential now, accepting that something may break. When a secret has leaked, the overlap window that makes routine rotation safe becomes the attacker's window. This guide compares the two operations for incident timing: when to revoke immediately, when a short overlap is defensible, what the leaked-secret sequence looks like, and how to prove the old value is dead. It is for secrets management, platform and incident response engineers who already run rotation and need a clear rule for the day a secret appears in a public repository.

Key takeaways

Rotation is hygiene, revocation is containment. Rotation limits the useful life of a secret nobody knows is stolen; revocation ends the life of one you know is exposed.
Overlap windows keep leaked secrets valid. Alternating users, dual access keys and multiple client secrets all leave the previous value working after the "rotation" finishes, which is the point in routine use and the problem in an incident.
Default to revoke first for confirmed exposure. The OWASP Secrets Management Cheat Sheet orders leaked-secret remediation as revoke, then rotate, then remove from exposed locations, then log review.
Revocation is often not instant. Self-contained tokens, role sessions already issued, CLI credential caches and child credentials such as SSH keys can outlive the parent secret, so revocation needs a residual-validity check.
Prove it, do not assume it. Test the old value against the real target, check last-used data and audit logs after the cutoff, and only then close the alert.

The short answer

If a secret is confirmed exposed outside its trust boundary (public repository, paste site, container image, chat log, departed employee's laptop), revoke the exposed value immediately and accept a controlled outage, unless the business impact of an outage is demonstrably worse than attacker use and you can cap the overlap at minutes with active monitoring. If there is no evidence of exposure, rotate on schedule with whatever overlap your consumers need. Everything in between (an internal log line, a suspected but unconfirmed leak) is a judgement call covered by the decision table below. Planning a rotation programme is covered in Credential Rotation at Scale, and rotation outages in the Secret Rotation Outage Troubleshooting Guide; this page does not repeat them.

Two operations with different intent

The words are often used interchangeably, and many runbooks say "rotate the key" when they mean "kill the key". The OWASP cheat sheet treats them as separate lifecycle stages: creation, rotation, revocation and expiration. The difference is about what happens to the old value and who is allowed to break.

Dimension	Rotation	Revocation
Intent	Limit the useful life of a credential that may be stolen without anyone knowing	Cut off a credential known or strongly suspected to be exposed, or no longer needed
Trigger	Schedule, policy maximum age, staff change, secret manager expiry	Leak detection, compromise, offboarding, decommissioning
Old value after the operation	Often still valid for a defined overlap (alternating users, second access key, second client secret)	Invalid at the target as soon as the change propagates
Availability priority	High: zero downtime is the design goal	Secondary: a controlled outage is acceptable
Who does it	Automation (secret manager rotation jobs, dynamic secret engines)	Incident responder or automation triggered by a detection
Replacement needed?	Yes, the new value is the output	Only if the consumer still needs access; decommissioned identities get none
Typical evidence	Rotation logs, secret version history, age reports	Revocation timestamp, failed-auth evidence for the old value, audit log review window
MITRE D3FEND	D3-CRO Credential Rotation	D3-CR Credential Revocation

A useful test for any runbook step: after this step, would the leaked value still authenticate? If the answer is "yes, until the next step", the step is rotation, whatever the runbook calls it. See the D3-CR Credential Revocation page for the defensive technique in detail.

Threat model: what each operation defends against

Rotation

Threat: undetected theft. A key copied from a laptop backup, a CI log or an old container layer (ATT&CK T1552.001 Credentials In Files) that nobody has noticed yet.
Architecture in words: a secret manager creates a new version, sets it at the target, tests it, promotes it, and keeps the previous version available so consumers can move at their own pace. AWS Lambda rotation runs createSecret, setSecret, testSecret and finishSecret; the alternating-users strategy leaves both the user and the clone valid after rotation.
What it buys: a ceiling on attacker dwell time equal to rotation period plus overlap. A 90-day rotation with a 7-day overlap gives a stolen value up to 97 days of life.
Failure mode: rotation that never completes (old value never retired), or that rotates only one copy of a secret that lives in several places.

Revocation

Threat: known exposure, active misuse of valid cloud accounts (T1078.004), or persistence through added credentials (T1098.001 Additional Cloud Credentials) created with the leaked one.
Architecture in words: the issuer or target marks the specific credential invalid (delete or deactivate the key, revoke the lease, call the OAuth revocation endpoint, apply a deny policy keyed on issue time), and every verifier must honour that state on the next request.
What it buys: immediate end of the leaked value's life at the target, if the verifier checks state.
Failure mode: revoking the parent while children survive (role sessions, refresh tokens, SSH keys, added access keys), or revoking a value that is cached in a verifier that never rechecks.

The overlap window: where leaked secrets stay valid

Overlap is how rotation avoids outages, and it is exactly the property you must switch off in an incident. The table shows where overlap appears by credential type, how long it typically lasts, and what to do when the trigger is a leak.

Credential and pattern	Where the overlap comes from	Leak response
Database password, AWS Secrets Manager alternating users	Two database users; after rotation both user and user_clone are valid until the next rotation	Change the exposed user's password or disable that user directly at the database; do not wait for the next scheduled rotation to overwrite it
Database password, single user	Short window between password change and secret update; open connections are not dropped	Rotate, then terminate existing sessions for that user at the database so open connections opened by the attacker close
AWS IAM user access key	Two active keys per user; AWS's documented process waits and checks last-used data before deactivating the old key	Deactivate the exposed key immediately (reversible), then deny the user's sessions by aws:userId, then create the replacement
Microsoft Entra application secret or certificate	An app registration can hold more than one secret or certificate during rollover	Delete the exposed credential by key ID rather than adding a new one and leaving the old one to expire
OAuth refresh token rotation	Some servers allow a grace period for the previous refresh token to absorb network retries	Revoke the grant at the authorisation server (RFC 7009 endpoint or admin console), not just the single token
Signing key (JWT, JWKS)	Old public key stays published so tokens signed before rollover still verify	Remove the compromised key from the key set at once; tokens signed with it must fail verification
Vault dynamic secret	Lease remains valid until TTL or revocation	Revoke the lease (or the whole prefix after an intrusion); for the AWS engine, Vault deletes the keys from AWS on revocation

The pattern is consistent: the routine procedure adds a new credential first and removes the old one later. The incident procedure removes the old one first. For signing keys see the JWKS Signing Key Rotation Guide.

Decision guidance: revoke now or rotate with overlap

Situation	Default action	Maximum acceptable overlap
Secret in a public repository, image, package or paste site	Revoke immediately; replace afterwards	None. Treat public exposure as already copied
Evidence of use from unknown IPs or identities	Revoke, deny issued sessions, hunt for added credentials	None
Departed staff or contractor had access to the value	Revoke on the departure date; rotate every secret they could read	None for high-value keys (signing, root, CI deploy); short for low-value read-only keys
Secret written to an internal log with restricted access, no sign of use	Rotate with a short overlap; purge the log entry	Hours, with alerting on any use of the old value
Vendor or SaaS partner reports a breach that may include your credential	Rotate urgently; revoke if the vendor confirms your data or credential in scope	Hours
Scheduled rotation, no exposure	Rotate with the overlap consumers need	As designed (days if necessary)

Trade-offs: immediate revocation can break production, especially when one secret is shared by many services. That is a design debt, not a reason to leave a leaked value alive. If you cannot revoke a secret without an outage you cannot tolerate, record the risk acceptance, cap the overlap in minutes, put a detection on every use of the old value, and fix the sharing afterwards.

Small vs large organisations: a small team can often revoke and redeploy by hand within an hour, so immediate revocation is cheap. Large estates with hundreds of consumers need a pre-built path: an inventory of who reads each secret, the ability to push a new value to all consumers fast, and automation that revokes on a high-confidence detection. Without that, responders fall back to rotation-with-overlap because it feels safer, and the leak stays open. See Secret Sprawl Measurement for building the consumer inventory.

The leaked-secret sequence

This sequence follows the OWASP remediation order (revoke, rotate, delete, log review) and adds the residual-validity steps that the platform documentation makes necessary. The wider incident procedure lives in the Leaked Credential Response Playbook.

Confirm the secret is live and identify its owner. GitHub secret scanning treats any committed secret as compromised and offers a validity check for GitHub tokens; for other types, test against the issuer's identity endpoint from a controlled host. Do not spend long here: a plausible live secret is treated as live.
Snapshot evidence before changing anything. Record last-used data (for AWS, get-access-key-last-used), the secret's version history and current permissions. Revocation often deletes the object you wanted to inspect.
Revoke the exposed value at the issuer. Deactivate or delete the key, revoke the lease or token, remove the signing key from the key set. Prefer reversible actions first (deactivate, deny) when you are unsure of dependencies, then delete once confirmed.
Kill what was already issued. For AWS roles, IAM's Revoke active sessions attaches an AWSRevokeOlderSessions policy that denies credentials with an aws:TokenIssueTime before the cutoff. For an IAM user, AWS documents a deny on aws:userId that also covers GetSessionToken sessions. For OAuth, revoke the grant so access tokens issued from a refresh token also stop, where the server supports it.
Hunt for children and persistence. List credentials created by or with the leaked one during the exposure window: new access keys, federated credentials, deploy keys, SSH keys. GitHub notes that revoking a personal access token does not disable SSH keys that the token created.
Issue the replacement through automation. Generate and deliver the new value without human handling where possible, and scope it narrower than the old one if the incident shows it was over-permissioned.
Remove the secret from every exposed location. Code, history, images, logs, tickets, chat. OWASP warns that rewriting git history has side effects; it is cleanup, not containment, because forks and clones already hold the value.
Review use during the exposure window. Pull audit logs from the first exposure time (commit timestamp, image push time) to the revocation time, not just since detection.
Verify, then close. See the verification section below. GitHub does not automatically close secret scanning alerts when the token is removed from the repository, so closure is a deliberate, evidenced step.

For the GitHub-specific path see How to revoke a leaked GitHub personal access token and check what it touched.

Residual validity: why revocation is not always instant

Mechanism	What survives revocation	How to close it
Self-contained access tokens (JWT)	RFC 7009 notes these can be validated without contacting the authorisation server, so it cannot revoke them immediately on its own	Short token lifetimes, introspection at sensitive resource servers, or removing the signing key
OAuth access tokens after refresh token revocation	If the server does not support access token revocation, access tokens stay valid until expiry	Know your server's behaviour; keep access token lifetime short
AWS role sessions	Sessions issued before the cutoff remain valid until expiry unless denied; service-linked role sessions cannot be revoked; Identity Center permission set sessions are revoked in Identity Center	AWSRevokeOlderSessions or an equivalent aws:TokenIssueTime deny, applied in the right console
AWS CLI credential cache	The CLI caches credentials until they expire and may keep using revoked ones	Clear the cache on hosts you control as part of re-authentication
Policy propagation	AWS states permission changes can take a few minutes to take effect	Treat the first minutes after revocation as still open; monitor during them
Vault KV secrets	The KV engine does not issue leases, so lease revocation does nothing to a static KV value	Change the credential at its real target; the vault only stores it
Child credentials	SSH keys, added access keys, deploy keys or federated credentials created with the leaked secret	Enumerate and revoke each; see the Workload Identity Compromise Response Playbook for trust-based persistence

For token-specific propagation (caching of introspection results, gateways that never recheck) see the OAuth Token Introspection and Revocation Guide.

Worked scenarios

Scenario 1: CI deploy key pushed to a public repository

A developer commits a cloud access key used by the deployment pipeline to a public fork. The routine rotation runbook says: create a second key, update the pipeline secret, wait a week, check last used, deactivate the old key. Followed literally, that leaves the public key live for at least a week. The incident path is different. The responder records last-used data, deactivates the exposed key within minutes, applies a deny on the user's ID to catch any session tokens minted with it, and accepts that deployments fail for the twenty minutes it takes to create a narrower replacement and update the pipeline secret. They then search for access keys or roles created during the exposure window, purge the commit, and review CloudTrail from the commit time. The outage cost is a paused deployment; the alternative was a week of public, working cloud access.

Scenario 2: database credential in a restricted application log

A debug flag writes a database connection string to an application log readable by eight engineers and the log platform. There is no sign of external access. Here a short overlap is defensible: the team triggers an immediate alternating-users rotation so the application moves to the clone, then disables the exposed user directly at the database within the hour rather than leaving it valid until the next scheduled rotation. They alert on any login by the old user, purge the log entries, and fix the debug flag. The decision is recorded with its reasoning so a reviewer can see why revocation waited an hour.

Verification and measurement

Containment is complete only when you have evidence the old value no longer works and has not been used since the cutoff.

Negative test: attempt authentication with the old value against the real target from a controlled host and record the failure.
Last-used check: confirm no successful use after the revocation timestamp (key last-used data, database login audit, identity provider sign-in logs).
Child credential inventory: show the list of credentials created during the exposure window and their state.
Alert closure with reason: close scanning alerts as revoked, with a comment linking the evidence; GitHub notes that dismissal comments can be used as audit justification.

Metrics that show the distinction is working:

Time to revoke: median minutes from detection of a confirmed exposure to revocation at the issuer. Track separately from time to rotate.
Exposure-to-revocation window: from first exposure (commit or push time) to revocation, which is what the attacker actually had.
Residual-validity incidents: count of cases where the old value or a child credential worked after "revocation".
Overlap compliance: percentage of incident-triggered rotations where the old value was retired within the agreed cap.
Revocable-without-outage coverage: share of high-value secrets with a known consumer list and a tested fast push path.

Rotation coverage and secret age are measured separately; see How to measure secret age and rotation coverage.

Common failure patterns

Running the routine rotation runbook for a leak. Adding a second key and waiting for consumers to move leaves the exposed key valid for days. The routine and incident procedures need separate runbooks.
Revoking accounts but not machine keys at offboarding. In the Coupang signing key breach a former developer kept a token signing key that was never revoked or rotated, and used it to forge tokens for months after leaving.
No owner to act on the report. In the Home Depot token exposure a GitHub token stayed usable for more than a year and was revoked only after a journalist contacted the company. Revocation speed depends on someone being reachable and empowered.
Revoking the parent, missing the children. Role sessions, refresh-token grants and SSH keys created with the leaked secret keep working.
Rewriting history and calling it fixed. Removing the commit does not revoke anything; the value already sits in clones, forks and scanner caches.
Rolling back to the leaked value during an outage. When a forced revocation breaks production, reactivating the old key restores service and reopens the incident. Push the new value to consumers instead. More on this in Incomplete rotation breaches.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management	Changing and revoking authenticators, including on suspected compromise
NIST SP 800-53 Rev. 5	SC-12 Cryptographic Key Establishment and Management	Key replacement and destruction for signing and encryption keys
NIST SP 800-53 Rev. 5	IR-4 Incident Handling; AC-2 Account Management	Containment of a leaked credential; disabling accounts and credentials on departure
NIST CSF 2.0	PR.AA-01; RS.MI-01	Credentials managed by the organisation; incidents are contained
ISO/IEC 27001:2022 Annex A	5.17 Authentication information; 5.26 Response to information security incidents	Managing secrets through their life; executing the response
MITRE D3FEND	D3-CRO Credential Rotation; D3-CR Credential Revocation	The two defensive techniques this page contrasts
MITRE ATT&CK	T1552.001 Credentials In Files; T1078.004 Cloud Accounts; T1098.001 Additional Cloud Credentials	How secrets leak, how they are used, and the persistence to hunt for after revocation

Practitioner checklist

Keep two runbooks: scheduled rotation (overlap allowed) and leaked-secret response (revoke first).
Define in policy which exposure types require revocation with no overlap, and who may accept a capped overlap.
For each high-value secret, record its consumers and a tested way to push a new value to all of them quickly.
Snapshot last-used data, version history and permissions before revoking.
Revoke issued sessions and grants, not just the long-lived secret, using the platform's documented mechanism.
Enumerate and revoke credentials created with the leaked secret during the exposure window.
Review audit logs from first exposure, not from detection.
Run a negative test against the real target and record it before closing the alert.
Never reactivate a leaked value to fix an outage; push the replacement instead.
Report time to revoke and residual-validity incidents separately from rotation coverage.

Secret Rotation vs Revocation: When to Cut Off a Leaked Secret at Once