D3FEND Credential Eviction (D3-CE) Implementation Guide

Most credential incidents are not lost at detection but at eviction: the team resets the password everyone knows about and leaves the cached ticket, the refresh token and the forgotten service account working. MITRE D3FEND models this work as Credential Eviction (D3-CE), a parent technique in the Evict tactic that it defines as techniques that "disable or remove compromised credentials from a computer network". D3-CE has three children: Account Locking (D3-AL), Authentication Cache Invalidation (D3-ANCI) and Credential Revocation (D3-CR). This guide treats the family as one capability: what each child covers, how to choose and sequence them during an incident, which neighbouring D3FEND techniques you need to finish the job, and how to prove eviction actually worked. It is written for incident responders, identity engineers and detection teams. For D3FEND as a whole, see the MITRE D3FEND Guide; each child technique has its own deep page linked below.

Key takeaways

Eviction is three different actions. Locking an account is reversible, invalidating caches kills credentials already in circulation, and revocation deletes credentials permanently. Each closes a different door.
Order matters. Scope first, contain with locks, purge caches and sessions, then revoke and reissue. Revoking before scoping tells the attacker you are coming and often misses credentials.
Credential Eviction does not include rotation or session termination. D3FEND places Credential Rotation (D3-CRO) under Credential Hardening and Session Termination (D3-ST) under Process Eviction, yet an incident needs both alongside D3-CE.
Non-human credentials are where eviction usually fails. API keys, service account passwords and integration tokens are easy to miss and hard to replace without an outage.
Verification is the deliverable. An eviction is complete only when every credential in scope has been tested as rejected and authentication logs show no further use.

What D3FEND means by Credential Eviction

In the D3FEND ontology, D3-CE is a direct child of Defensive Technique and "enables Evict". Eviction is the tactic that removes an adversary's access after detection, in contrast to Harden (prevent) and Isolate (contain by boundary). The D3FEND page for D3-CE lists the three children and builds its offensive links from two digital artefact relations held by those children: Account Locking "disables" a User Account, while Authentication Cache Invalidation and Credential Revocation each "deletes" a Credential.

The family is deliberately narrow. It covers the credential itself, not the processes, sessions, files or persistence mechanisms an attacker created with it. Those sit in sibling eviction families such as Process Eviction and Object Eviction. A full response therefore combines D3-CE with other techniques, which the sequencing section below sets out.

The child techniques

Every child of D3-CE in the D3FEND ontology, with its definition and the artefact relation D3FEND records.

Technique	D3FEND definition	Artefact relation	Reversible?	Typical tools
D3-AL Account Locking	Temporarily disabling user accounts on a system or domain	disables User Account	Yes	Directory account disable, identity provider suspend, cloud user or key deactivate
D3-ANCI Authentication Cache Invalidation	Removing tokens or credentials from an authentication cache to prevent further account access	deletes Credential	No (holder must re-authenticate)	Kerberos ticket purge, cached logon removal, refresh token and session cookie invalidation
D3-CR Credential Revocation	Deleting a set of credentials permanently to prevent them from being used to authenticate	deletes Credential	No	OAuth token revocation endpoint, certificate revocation (CRL, OCSP), API key and access key deletion

Two adjacent techniques complete the response. D3-ST Session Termination forcefully ends active sessions for compromised accounts or devices, and D3-CRO Credential Rotation issues the replacement secret. Scoping comes from D3-CCSA Credential Compromise Scope Analysis, a child of User Behavior Analysis.

Choosing the right child

The three children are not alternatives so much as escalating levels of certainty and cost. Use the table to pick the first move for each credential type.

Situation	First move	Then	Why
Human account suspected, not confirmed	D3-AL lock	Investigate, then unlock or revoke	Reversible while facts are gathered
Session cookie or refresh token theft (T1539, T1528)	D3-ANCI plus D3-ST	Require fresh phishing-resistant sign-in	A password reset alone leaves stolen tokens valid
Leaked API key or cloud access key	D3-CR after a replacement is in place	D3-CRO for the consumer	Keys cannot be "locked" in many platforms; deletion is the eviction
Compromised service account used by production jobs	D3-AL only if an outage is acceptable	Rotate with D3-CRO, then D3-CR the old secret	Locking breaks dependants; plan the swap
Domain compromise with forged Kerberos tickets (T1558.001)	D3-ANCI at domain level	Planned double reset of the ticket-granting account	Forged tickets survive user password resets
Issued certificate with exposed private key	D3-CR (certificate revocation)	Reissue, check relying parties check revocation	Revocation only works where clients check CRL or OCSP

For the domain case, see the krbtgt account guide; for token-based cases the Global Token Revocation Guide covers cross-application logout.

Sequencing an eviction

D3FEND does not prescribe an order. The sequence below is NHI Mgmt Group's recommendation, built so that each step removes a fallback the attacker could use against the next one.

Scope before acting (D3-CCSA). List every credential the attacker could have touched: logon history on affected hosts, secrets stored on those hosts or in reachable repositories, tokens issued to affected identities, and keys created recently (T1098.001 Additional Cloud Credentials is a common persistence move). Decide in advance which credentials go in the same eviction window.
Prepare replacements. For service accounts and API keys, stage new secrets in the secrets manager and confirm consumers can pick them up. Without this, eviction causes the outage that tempts teams to postpone it.
Contain with locks (D3-AL). Disable human accounts and suspend non-critical machine identities in one coordinated window, so the attacker cannot use one credential to restore another.
Purge caches and sessions (D3-ANCI, D3-ST). Invalidate refresh tokens and session cookies at the identity provider, purge Kerberos tickets and cached credentials on affected hosts, and end live interactive and remote sessions.
Revoke and reissue (D3-CR, D3-CRO). Delete exposed keys, revoke tokens through the authorisation server and revoke certificates. Switch consumers to the replacements staged in step 2.
Remove persistence that can mint new credentials. Check for attacker-created accounts (T1136.003), added cloud roles (T1098.003) and new federation trusts or app credentials, or eviction will be undone within hours.
Verify and watch. Test each evicted credential and confirm rejection, then monitor authentication logs for any attempt to use it.

Testing and rollback

Rehearse: run the sequence as a tabletop and then in a test tenant or lab domain, timing each step. Token invalidation may not take effect instantly everywhere, so check each identity provider's documentation and build waiting time into the plan.
Rollback: D3-AL is the only child you can roll back. Keep a list of locked accounts with an owner who can unlock business-critical ones. Revoked keys and tokens cannot be restored, so a failed consumer is fixed forward by deploying the replacement.

Standards that make eviction work

OAuth 2.0 Token Revocation (RFC 7009): a Proposed Standard defining a revocation endpoint with a token_type_hint of access_token or refresh_token. Servers must support refresh token revocation and should support access token revocation. Revoking a refresh token should also invalidate access tokens from the same grant where supported. Self-contained access tokens are not recalled by the endpoint, which is why short access token lifetimes matter. See the OAuth token introspection and revocation guide.
OpenID Continuous Access Evaluation Profile (CAEP) 1.0: published 29 August 2025 as a profile of the Shared Signals Framework, it defines events including Session Revoked and Credential Change so that one system's eviction can reach the applications that trust it. See the CAEP and Continuous Access Evaluation guide.
Certificate revocation: CRLs and OCSP carry D3-CR for certificates; see the certificate revocation guide.

Where identity fits: non-human credentials

Machine credentials break the assumptions behind locking and password resets. A service account has no user to call, an API key may be embedded in a dozen deployments, and a CI token can mint further tokens. Three practices help. First, keep an owner and consumer list for every machine credential so scoping is a query, not a hunt; see NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments. Second, prefer short-lived, federated credentials so eviction becomes "stop issuing" rather than "find and delete". Third, treat "we think it is unused" as a reason to revoke, not to skip. The Cloudflare Thanksgiving 2023 incident shows why: after rotating thousands of credentials following a third-party breach, one service token and three service accounts believed to be unused were left in place and later used to reach the wiki, bug database and source code repositories. For machine-specific response steps see workload identity incident response and revocation.

ATT&CK techniques D3FEND relates to Credential Eviction

D3FEND lists these relationships on the D3-CE page and labels them inferred and experimental: they come from the shared User Account and Credential artefacts, not from tested coverage. Revoked IDs are not used; all IDs below are current in ATT&CK v20. Use the table as a list of behaviours eviction should cut off, and test each.

ATT&CK tactic	Techniques (selection from the D3FEND page)	Which child cuts it off
Initial Access, Persistence, Privilege Escalation, Stealth	T1078.002 Domain Accounts, T1078.004 Cloud Accounts	D3-AL, D3-CR
Persistence	T1136.003 Cloud Account, T1098.001 Additional Cloud Credentials, T1098.003 Additional Cloud Roles	D3-CR (remove added credentials), D3-AL (disable created accounts)
Credential Access	T1110.003 Password Spraying, T1003.003 NTDS, T1003.005 Cached Domain Credentials, T1558.001 Golden Ticket, T1606.001 Web Cookies	D3-ANCI for caches and forged tickets, D3-CR for dumped secrets
Lateral Movement	T1550.001 Application Access Token, T1550.004 Web Session Cookie	D3-ANCI, D3-CR
Privilege Escalation, Stealth	T1134.001 Token Impersonation/Theft, T1548.005 Temporary Elevated Cloud Access	D3-ANCI, D3-AL
Discovery	T1087.002 Domain Account, T1087.004 Cloud Account	Indirect: limits what discovered accounts can be used for
Impact	T1531 Account Access Removal	Shared artefact only: the attacker's version of D3-AL, so eviction tooling must not be usable by the attacker

See the MITRE ATT&CK T1078 Valid Accounts Guide and MITRE ATT&CK T1550 Use Alternate Authentication Material Guide for the attacker side.

Detection and measurement

After eviction, any authentication attempt with an evicted credential is high-signal: failed sign-ins for disabled accounts, rejected refresh token redemptions, API calls with deleted keys and Kerberos requests with stale tickets. Alert on these for at least the length of your longest token lifetime, and longer for keys. Metrics we suggest:

Time to full eviction: from confirmed compromise to the last in-scope credential revoked.
Scope completeness: credentials evicted divided by credentials identified in scoping, including machine credentials.
Post-eviction use: count of attempts with evicted credentials in the following 30 days (example window), with source.
Re-compromise rate: incidents where the same actor regained access through a credential not evicted.
Machine credential ownership: share of service accounts and keys with a named owner and consumer list.

Framework mapping

Framework	Reference	Link to D3-CE
NIST SP 800-53 Rev. 5	AC-2(3) Disable Accounts, AC-2(13) Disable Accounts for High-risk Individuals	D3-AL
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management, IA-4 Identifier Management	D3-CR, D3-ANCI and replacement
NIST SP 800-53 Rev. 5	IR-4 Incident Handling	Eviction as part of containment and eradication
NIST CSF 2.0	RS.MI-01 Incidents are contained, RS.MI-02 Incidents are eradicated, PR.AA-01	Response outcomes and credential management
NIST SP 800-61 Rev. 3	Incident response as a CSF 2.0 Community Profile	Places eviction within the respond function
CIS Controls v8.1	Control 5 Account Management, Control 6 Access Control Management	Disabling and revoking access

Common failure patterns

Password reset as the whole response. Refresh tokens, session cookies and Kerberos tickets outlive the password change unless D3-ANCI is done too.
Staggered eviction. Evicting credentials one by one over days lets the attacker use a remaining one to re-establish the others.
Skipping "unused" machine credentials. Unverified assumptions about usage leave the most privileged integration accounts live.
Ignoring credential-minting persistence. Added app secrets, federation trusts and new accounts let the attacker issue fresh credentials after eviction.
No verification step. Teams record "revoked" without testing that the credential is rejected at every relying party, including ones that cache or do not check revocation.

Practitioner checklist

Keep a pre-approved eviction runbook naming the tool and owner for D3-AL, D3-ANCI and D3-CR per platform.
Scope with D3-CCSA before the first lock, including tokens, keys and certificates.
Stage replacement secrets for machine credentials before revoking.
Evict all in-scope credentials in one coordinated window.
Pair cache invalidation with session termination for every affected human identity.
Remove attacker-created accounts, credentials, roles and trusts in the same window.
Test each evicted credential and record the rejection.
Alert on use of evicted credentials for at least the longest token lifetime.
Rehearse the runbook twice a year (example cadence) and time each step.

MITRE D3FEND Credential Eviction Implementation Guide: Removing Compromised Credentials Completely and in Order