Once a credential is in an attacker's hands, every hour it stays valid is an hour of access you did not grant. D3-CR Credential Revocation is the MITRE D3FEND countermeasure that ends it: D3FEND defines it as "Deleting a set of credentials permanently to prevent them from being used to authenticate." It sits in the Evict tactic as a child of Credential Eviction, beside Account Locking and Authentication Cache Invalidation. This card covers what D3-CR removes, the ATT&CK techniques D3FEND relates it to, how revocation behaves on common platforms, how to prove a revoked credential no longer works, and where revocation leaves access behind. It is written for incident responders and identity engineers who run containment. For the full response sequence, see the Leaked Credential Response Playbook.
Key takeaways
- Revocation is permanent by design. D3FEND's definition is deletion, which sets it apart from rotation (regenerate and replace) and account locking (reversible disablement).
- Revoking the parent does not always kill the children. Short-lived tokens, sessions and cached tickets issued from a credential often survive its deletion until they expire or are revoked separately.
- Scope decides success. One unrevoked credential from a compromised set is enough to keep the attacker in, so revocation must follow a scoped list, not the first finding.
- Disable first, delete after, when you can afford to. Vendors recommend a reversible disable step to catch hidden dependencies, but during an active intrusion speed outranks convenience.
- Proof is a failed authentication. Close the action only when a test with the revoked credential fails and logs show no successful use after the revocation time.
D3-CR at a glance
| Field | D3-CR Credential Revocation |
|---|---|
| D3FEND ID | D3-CR (d3f:CredentialRevocation) |
| Tactic | Evict |
| Parent technique | Credential Eviction (siblings: Account Locking, Authentication Cache Invalidation) |
| Digital artefact | Credential (D3FEND relation: deletes Credential) |
| What it changes | The credential stops being accepted anywhere it was valid, permanently |
| D3FEND reference | Microsoft: Revoke a previously issued verifiable credential |
| Typical implementation points | Identity provider and directory, cloud IAM consoles and APIs, secrets managers, OAuth authorisation servers, certificate authorities, source code and SaaS platforms |
| Typical verification data | Credential last-used data, authentication and API audit logs, token introspection results, certificate status responses |
| Effort | Low per credential; high to scope, sequence and complete across an estate |
| Main limitation | Derived artefacts (sessions, tokens, tickets) and copies of the secret may remain usable |
How it works
D3FEND's knowledge base entry is brief: management servers with enterprise account policies can remove permissions, accounts or credentials, and compromised credentials should be revoked to prevent further malicious activity. The practical depth lies in what "a credential" means on each platform and what was issued from it.
- Long-lived secrets: passwords, API keys, cloud access keys, service account keys, personal access tokens and client secrets. Deleting them stops new authentications.
- Derived credentials: refresh tokens, access tokens, session cookies, Kerberos tickets and cloud temporary credentials minted while the parent was valid. Many keep working until they expire unless revoked separately.
- Asserted credentials: X.509 certificates and verifiable credentials are checked against a status source. Revocation only bites where relying parties actually check that status.
The D3FEND reference illustrates the third case. Microsoft Entra Verified ID revokes a credential by setting a flag in a W3C StatusList2021 status list; verifiers see the presentation as REVOKED, and whether it then fails depends on the verifier's request configuration. A credential can only be found for revocation if one claim was marked as indexed when it was issued, and indexing is not retroactive. Revocation that was not designed in at issuance cannot be added later.
OAuth works similarly in principle. RFC 7009 (Proposed Standard) defines a revocation endpoint. When a refresh token is revoked, the authorisation server should also invalidate access tokens from the same grant if it supports access token revocation, but this is a SHOULD, and self-contained access tokens may stay usable until expiry. The RFC suggests short-lived access tokens to limit that window. See the Global Token Revocation Guide for cross-application revocation.
Where identity and NHIs fit
Most credentials revoked in incident response today belong to non-human identities: API keys, service account keys, CI/CD tokens and OAuth grants held by integrations. They have no person to notice a lockout, often have no recorded owner, and are frequently copied into several systems. Revocation of an NHI credential therefore needs an owner, a list of consumers and a replacement path, or containment turns into an outage. See How to revoke a leaked GitHub personal access token and check what it touched for a worked example.
ATT&CK techniques D3FEND relates to D3-CR
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CR. Every row below is inferred through the Credential artefact that D3-CR deletes, so techniques that create, access or use a Credential or one of its sub-types are related (D3FEND checked November 2026; IDs checked against ATT&CK v20). D3FEND lists Keychain under an ID ATT&CK has since revoked; its v20 successor is T1555.001. D3FEND shows Steal Web Session Cookie, Steal Application Access Token and Unsecured Credentials without IDs; they are T1539, T1528 and T1552. The last column is NHI Mgmt Group's assessment, not part of D3FEND.
| ATT&CK ID | Technique | What revocation does (NHI Mgmt Group assessment) |
|---|---|---|
| T1098, T1098.001 | Account Manipulation; Additional Cloud Credentials | Strong: deleting keys and secrets the attacker added removes the persistence itself |
| T1110.001, T1110.002, T1110.003 | Password Guessing, Password Cracking, Password Spraying | Strong after the fact: a guessed or cracked password stops working once the credential is deleted |
| T1003.003, T1003.005, T1003.008 | NTDS, Cached Domain Credentials, /etc/passwd and /etc/shadow | Partial: dumped hashes for revoked credentials die, but a dump usually exposes far more accounts than are revoked |
| T1555.001 | Keychain | Partial: harvested secrets fail once revoked at the service |
| T1552 | Unsecured Credentials | Strong for each exposed secret, if every copy is found and revoked |
| T1558.001 | Golden Ticket | Requires a specific action: forged tickets survive until the krbtgt key is reset twice |
| T1606.001 | Web Cookies (Forge Web Credentials) | Requires revoking the signing secret, not the user's password |
| T1528, T1539 | Steal Application Access Token, Steal Web Session Cookie | Partial: needs token and session revocation, not only the parent credential |
| T1550.001, T1550.004 | Application Access Token, Web Session Cookie (Use Alternate Authentication Material) | Partial: same as above |
| T1134.001, T1134.002, T1134.003 | Token Impersonation/Theft, Create Process with Token, Make and Impersonate Token | Minimal: local access tokens persist for the life of the logon session |
For the techniques in depth, see MITRE ATT&CK T1098.001 Account Manipulation, MITRE ATT&CK T1552 Unsecured Credentials Guide and the Golden Ticket, Silver Ticket and DCSync Guide.
Where it is implemented
Revocation controls by credential type:
| Credential type | Revocation action | What it leaves behind |
|---|---|---|
| User password (directory, IdP) | Reset to an unknown value or disable, then revoke sessions | Refresh tokens and cookies until sessions are revoked |
| Cloud access key or service account key | Disable, confirm, delete | Temporary credentials already minted from the key |
| OAuth refresh and access tokens | Revocation endpoint (RFC 7009) or admin grant removal | Self-contained access tokens until expiry |
| Personal access tokens and API keys | Delete in the issuing platform | Copies of the same value elsewhere are dead, but anything the attacker created with it is not |
| Kerberos (domain) | Password reset for the account; krbtgt double reset for forged tickets | Tickets until their lifetime ends unless krbtgt is reset; see krbtgt account |
| X.509 certificate | Revoke at the CA and publish CRL or OCSP status | Relying parties that do not check status; see the Certificate Revocation Guide |
| Verifiable credential | Set the status list flag | Verifiers configured to accept revoked credentials |
Platform behaviour, from each vendor's documentation as of November 2026 (platforms are listed alphabetically):
- Amazon Web Services: IAM access keys can be set Inactive (reversible) before deletion, and the console's delete flow requires deactivation first. For roles, revoking active sessions attaches an inline AWSRevokeOlderSessions policy that denies all actions to credentials issued before the revocation time (with a buffer of about 30 seconds); new sessions assumed after that remain allowed, so change trust or permissions as well if the role itself is compromised.
- Google Cloud: a service account key can be disabled and re-enabled before deletion. Disabling a key does not revoke short-lived credentials already issued from it; to cut those off, disable or delete the service account, which stops every workload using it.
- Microsoft Entra ID: revokeSignInSessions invalidates a user's refresh tokens and browser session cookies by resetting signInSessionsValidFromDateTime; Microsoft notes a delay of a few minutes before tokens are revoked. It does not apply to external users, who sign in through their home tenant.
Implementation steps
- Scope the compromised set. List every credential the attacker could have read or created, from the host, vault, repository or tenant involved. See D3-CCSA Credential Compromise Scope Analysis.
- Find owners and consumers. For each credential, record what uses it, so revocation can be paired with a replacement where the workload must keep running.
- Decide revoke or rotate per credential. Revoke credentials the attacker created and those no longer needed. Rotate (issue new, then revoke old) where a legitimate consumer depends on it. See D3-CRO Credential Rotation.
- Sequence to avoid re-entry. Revoke credentials that grant access to other credentials (vault tokens, identity admin, CI/CD secrets) first, and do the whole set in one window so the attacker cannot use one to recover another.
- Revoke derived artefacts. Revoke sessions, refresh tokens and temporary credentials for the affected identities, and reset krbtgt twice if domain-level compromise is suspected.
- Use the reversible step only when time allows. Disable-then-delete is good practice for planned clean-up; during active compromise, accept breakage and repair forward.
- Record and verify. Log the revocation time per credential, then run the checks below before closing.
How to verify it works
- Negative test: attempt authentication with the revoked credential from a controlled host. It must fail at every service that accepted it.
- Last-used and audit logs: confirm no successful use after the revocation time, and alert on any attempt; a failed attempt with a revoked key is a strong sign the attacker still holds it.
- Derived artefact check: for the affected identities, confirm active sessions and refresh tokens are gone and temporary credentials issued before revocation are denied.
- Persistence sweep: look for credentials the attacker added (new keys, app secrets, OAuth grants, SSH keys) that were not on the original list.
| Metric | What it shows | Target direction (example) |
|---|---|---|
| Time from confirmed exposure to revocation, per credential | Containment speed | Hours, not days |
| Share of scoped credentials revoked or rotated | Completeness | 100% before closure |
| Successful authentications with revoked credentials | Revocation that did not take effect | Zero |
| Failed authentications with revoked credentials | Attacker still holding material | Investigated, falling to zero |
| Credentials with no known owner at revocation time | Inventory gap that slows response | Falling |
Limits, bypasses and failure patterns
- Incomplete set: in the Cloudflare breach, one service token and three service account credentials exposed in the October 2023 Okta support system breach were left unrotated because they were believed to be unused, and the attacker used them to reach internal systems in November 2023. See Incomplete rotation breaches.
- Tokens outliving their parent: deleting a key or resetting a password without revoking sessions and temporary credentials leaves working access for the token lifetime.
- Attacker-created credentials missed: responders revoke the stolen secret but not the new key or OAuth grant the attacker added with it.
- Relying parties that never check status: a revoked certificate or verifiable credential still works wherever revocation status is not checked.
- Revocation without replacement: production outages push teams to re-enable the old credential, undoing containment. Prepare the replacement path before revoking where the workload is critical.
Framework mapping
| Framework | Reference | Relationship to D3-CR (NHI Mgmt Group mapping) |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management | Revoking authenticators is part of authenticator management |
| NIST SP 800-53 Rev 5 | AC-2 Account Management | Disabling and removing accounts and their credentials |
| NIST SP 800-53 Rev 5 | SC-17 Public Key Infrastructure Certificates | Certificate issuance and revocation |
| NIST CSF 2.0 | PR.AA-01 | Identities and credentials are managed, including removal |
| MITRE ATT&CK | M1018 User Account Management | Account and credential lifecycle mitigation |
| IETF | RFC 7009 OAuth 2.0 Token Revocation | Protocol for revoking OAuth tokens |
Related countermeasures
- Siblings under Credential Eviction: D3-AL Account Locking for a reversible stop, and D3-ANCI Authentication Cache Invalidation for cached tickets and sessions.
- Before and after: D3-CCSA Credential Compromise Scope Analysis builds the list; D3-RIC Reissue Credential restores legitimate access.
- Session side: D3-ST Session Termination ends live sessions the revoked credential opened.
For how D3FEND is organised, see the MITRE D3FEND Guide.
Practitioner checklist
- Build the full compromised credential list before revoking anything, including attacker-created credentials.
- Record an owner, consumers and a replacement path for every credential on the list.
- Revoke credentials that unlock other credentials first, and complete the set in one window.
- Revoke sessions, refresh tokens and temporary credentials as well as the parent secret.
- Reset krbtgt twice where forged Kerberos tickets are possible.
- Confirm relying parties check certificate and credential status before relying on revocation.
- Test each revoked credential and review logs for any use after the revocation time.
- Alert on failed attempts with revoked credentials for at least the length of the investigation.
Standards and references
- MITRE D3FEND: Credential Revocation (D3-CR)
- IETF: RFC 7009 OAuth 2.0 Token Revocation
- Microsoft: Revoke a previously issued verifiable credential
- Amazon Web Services: Revoke IAM role temporary security credentials
- Google Cloud: Disable and enable service account keys
- Microsoft: user revokeSignInSessions
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: Leaked Credential Response Playbook · Incomplete rotation breaches · Global Token Revocation Guide · MITRE D3FEND Guide