Containment vs Eradication: Sequencing Incident Response Without Tipping Off Attackers

Most failed incident responses do not fail because the team chose the wrong tool, they fail because containment and eradication were run in the wrong order or blurred into one rushed step. Containment limits what an attacker can do next; eradication removes every way they have of being there at all. The two use many of the same actions (disabling accounts, rotating credentials, isolating hosts), which is exactly why teams confuse them and why a well-meant password reset can turn into a warning shot that sends the attacker deeper. This guide compares the two phases as decisions: what each is for, what threat each addresses, how to time the hand-off, how to sequence credential resets for human and non-human identities, and what evidence must be secured before either begins. It is written for incident commanders, IR leads and identity teams. The broader question of how to scope an incident and choose containment options by layer is covered in the Incident Scoping and Containment Strategy Guide, so this page goes deeper on sequencing and does not repeat it.

Key takeaways

• Different goals, overlapping actions. NIST CSF 2.0 lists them as separate outcomes, RS.MI-01 "Incidents are contained" and RS.MI-02 "Incidents are eradicated"; containment buys time and limits harm, eradication ends the attacker's presence.
• Short answer: contain fast, eradicate once. Contain immediately where damage is fast or irreversible; otherwise contain quietly, finish scoping, and run eradication as one coordinated window, which the NCSC describes as carrying out actions simultaneously.
• Premature eradication is the costliest mistake. Removing one foothold before you know the others shows the attacker what you can see; the NCSC asks responders to consider whether the attacker might react or bury themselves more deeply.
• Credential order matters. Remove persistence and attacker-added credentials, then rotate from the most privileged down, revoke sessions and tokens explicitly, and handle non-human identities in the same window, not afterwards.
• Evidence first, unless safety or irreversible harm says otherwise. Collect volatile data and logs before isolation or rebuild, and record every action, as CSF 2.0 RS.AN-06 and RS.AN-07 require.

The two phases side by side

NIST SP 800-61 Rev. 3, published in April 2025 as a CSF 2.0 Community Profile and superseding Rev. 2, maps incident response onto CSF 2.0 outcomes rather than the older four-phase lifecycle. Containment and eradication remain distinct outcomes inside the Respond function. The NCSC's incident response process describes containment as limiting impact and stopping things getting worse "once you're certain it's safe to do so", and eradication as the stage that aims "to fully remove the threat from your network and systems".

The practical consequence: containment can be partial by design, eradication cannot. A partial containment step that stops exfiltration is a success. A partial eradication step that misses one service account is a failure that has also told the attacker you are coming.

Threat model for each phase

What containment defends against

Containment answers the threat that the attacker is causing harm right now. The relevant attacker behaviours are fast and visible in telemetry: ransomware staging, bulk downloads from storage or mailboxes, a stolen bearer token in active use (ATT&CK T1550.001 Application Access Token, T1550.004 Web Session Cookie), or lateral movement with valid accounts (T1078). The risk of containing is low because the attacker already knows they are active; the risk of not containing is measured in records lost or systems encrypted.

What eradication defends against

Eradication answers a different threat: that the attacker can come back. Capable intruders plant several routes in: web shells (T1505.003), credentials added to existing cloud applications or service principals (T1098.001), changes to hybrid identity authentication (T1556.007), stolen application tokens (T1528), and, at the extreme, the ability to forge SAML tokens (T1606.002) after stealing a signing key. Each of these survives an ordinary password reset. Eradication is therefore a completeness problem, and the attacker's reaction to an incomplete attempt is the main risk.

How the attacker reacts

• Burrowing: after losing one foothold, the attacker activates dormant ones or creates new ones; the NCSC explicitly warns that an attacker may "bury themselves more deeply in the network", particularly in targeted attacks.
• Acceleration: a financially motivated attacker who sees accounts being disabled may trigger encryption or data publication early.
• Counter-monitoring: an attacker with mailbox or chat access reads the incident channel and watches the response unfold.
• Waiting: an attacker with unrotated credentials may simply go quiet and return weeks later, which is why eradication needs a monitoring period before recovery is declared.

Architecture of each phase in practice

Containment architecture is built around pre-approved, reversible controls at choke points: EDR network isolation, firewall and proxy deny lists, conditional access block policies, revocation of a single user's sessions, and cloud deny policies attached to a compromised role. These should be executable by the SOC within minutes and reversible by the same team. The identity layer matters most because sessions and tokens are independent of passwords: Microsoft documents that Entra ID access tokens last one hour by default, that refresh token revocation does not end access held in an unexpired access token, and that the identity provider "can't directly revoke a session token issued by an application" unless that application supports Continuous Access Evaluation.

Eradication architecture is a plan, not a control. It consists of an eviction list (every account, credential, token, key, host, persistence mechanism, access path and infrastructure indicator in scope), clean administrative infrastructure that the attacker cannot see (a separate tenant or out-of-band channel for communications, clean admin workstations, break-glass accounts not synchronised from the compromised directory), staged replacement credentials, a run order with owners and timings, and verification checks for each action. Its last component is a post-eviction monitoring plan using the indicators gathered during scoping.

Timing the hand-off from containment to eradication

The incident commander's question is not "contain or eradicate" but "when is scope good enough to eradicate?". Use explicit gates and record the decision against them in the incident log (see the Incident Response Guide).

Not every incident waits for all six gates. Where the attacker is about to cause irreversible harm, contain and eradicate what you can immediately, accept that scope is incomplete, and plan a second, fuller eviction. Record that trade-off explicitly. Conversely, an observation period with no deadline is not a strategy: every "watch and learn" decision needs an end time, tripwires that force action and legal input, because a delay can let the attacker escalate access or reach other systems.

Credential reset sequencing, including non-human identities

Credential work spans both phases, which is where most sequencing errors occur. A useful rule: during containment, revoke only credentials that are being actively abused and cheap to replace; during eradication, rotate everything in scope, in order.

Containment-phase credential actions

• Stolen bearer token or session in active use: revoke now. Revocation is cheap and the token gives immediate access. Accept that this alerts the attacker to that one credential.
• Compromised human account used for lateral movement: where minutes allow, scope what else it reached first; then disable and revoke sessions together, because disabling alone does not end existing tokens.
• Long-lived cloud keys seen in attacker activity: deactivate rather than delete where the platform allows, so the key's identifier remains for log correlation and the change can be reversed if a production dependency breaks.

Eradication-phase run order

1. Block known attacker infrastructure and close the entry vector. Patch, disable the exposed service or cut the supplier connection, so rotated credentials are not stolen again the same way.
2. Remove persistence and attacker-created identities. Delete web shells, tasks and services; remove accounts, app registrations and credentials the attacker added (check service principals and OAuth grants, not just users). Doing this before rotation stops the attacker using a backdoor to read the new secrets.
3. Rotate trust anchors. In Active Directory compromise, reset the krbtgt password twice. Microsoft's forest recovery guidance explains that krbtgt password history holds two values, so two resets clear old passwords, and says to wait 10 hours between resets because that is the default maximum Kerberos ticket lifetime (longer if your policy is longer). Where federation was compromised, rotate token-signing keys and review trusts. See the krbtgt account guide.
4. Rotate privileged human credentials, most powerful first. Domain and cloud administrators, break-glass accounts, then other administrators. Revoke sessions and refresh tokens for each, and re-register MFA methods where the attacker could have added their own.
5. Rotate non-human credentials in the same window. Service account passwords, API keys, cloud access keys, CI/CD and deployment tokens, database credentials, OAuth client secrets and certificates. Work from an inventory with owners and dependencies, staging new secrets in the secrets manager first so dependent workloads pick them up without an outage. See the Credential Rotation at Scale guide.
6. Rotate every secret in stolen material. If code, configuration or a password vault export was taken, every credential inside it is in scope, whether or not you have seen it used.
7. Rebuild what cannot be trusted. Reimage hosts with confirmed or likely persistence from known-good images, verifying backup integrity first (CSF 2.0 RC.RP-03).
8. Verify. Confirm each old credential fails, each session is gone and each removed identity cannot authenticate; then begin heightened monitoring.

Two live incidents show why non-human identities belong inside the eradication window. After the October 2023 Okta support system breach, Cloudflare left one service token and three service accounts unrotated because it believed they were unused; an attacker used them in November, and Cloudflare's subsequent remediation rotated more than 5,000 production credentials and reimaged every machine in its global network. See the Cloudflare Thanksgiving Breach 2023. At the Internet Archive in 2024, Zendesk API tokens found in stolen source code were not rotated after the first breach, and the attacker used one weeks later to email people who had contacted the Archive. See the Internet Archive Breach 2024. For the wider playbook see the Leaked Credential Response Playbook.

Evidence preservation across both phases

Both phases destroy evidence: isolation drops live network connections, reboots clear memory, and rebuilds erase disks. The NCSC lists preservation of evidence and recording of actions taken among the minimum legal and regulatory preparations, and notes that responses may later be reviewed by regulators or courts.

Record each action, who took it and when (CSF 2.0 RS.AN-06), and preserve the integrity and provenance of incident data (RS.AN-07). For collection technique see the Memory Forensics Guide and the Forensic Readiness Guide.

Failure modes of premature eradication

• Single-account reset during an active intrusion: resetting the one account the SOC spotted tells the attacker which credential is burnt and prompts them to switch to the others. Contain quietly and add it to the eviction list instead, unless it is causing active harm.
• Rotating before removing persistence: new secrets are stored where a backdoor or attacker-added app credential can still read them. Remove persistence first.
• Password reset treated as eviction: refresh tokens, application session cookies, OAuth grants and API keys remain valid. Revoke sessions and tokens explicitly, and confirm which applications need to end their own sessions.
• Skipping "unused" non-human credentials: the Cloudflare pattern. Rotate every exposed credential, verified by inventory, not by belief.
• Rebuilding before imaging: wiping the patient-zero host removes the evidence that would have shown the entry vector, so the attacker returns the same way.
• Declaring recovery without a monitoring period: the NCSC advises confirming that remediation has been successful before moving to recovery, which may mean monitoring for a period.

Worked scenarios

Scenario 1: ransomware staging detected

EDR alerts on a backup deletion tool running under a domain administrator account on two file servers. Containment wins outright: isolate both servers, disable the account and revoke its sessions, protect backups and block the known command and control domains. Eradication follows once scope is clearer, and because a domain administrator was used, it will include a krbtgt double reset and a full privileged rotation, scheduled after the evidence from the two servers has been captured.

Scenario 2: quiet cloud intrusion through a CI/CD token

Threat hunting finds API calls from an unfamiliar network using a deployment pipeline's cloud access key, with a new access key added to a second service identity (T1098.001). No data has left yet. The team contains quietly: tightens egress alerts on storage, snapshots affected volumes and exports cloud audit logs, and avoids touching the keys. Two days of scoping find a stolen CI/CD token, the added key and a third identity with a new trust policy. Eradication runs in one window: revoke the CI/CD token, remove the added key and trust policy, rotate every secret the pipeline could read, then rotate the original key. Monitoring continues on the attacker's old network indicators as tripwires.

Scenario 3: misbehaving AI agent

An AI agent with delegated tool access starts acting outside its task. Containment is the agent's kill switch and revocation of its tokens; eradication is finding the cause (a poisoned prompt source, an over-broad tool grant or a compromised MCP server) and fixing it before the agent is re-enabled. See the AI Agent Kill Switch and Containment Guide and the AI Agent Observability and Incident Response Guide.

Decision guidance

Small organisations usually cannot run a long observation period; prefer fast containment, then a short, complete eviction with help from a retainer or managed provider, prioritising cloud administrator and email account resets plus session revocation. Large organisations should keep a standing eviction planning cell (identity, cloud, network, application owners) and rehearse an identity provider eviction at least once a year.

Detection and measurement

• Re-compromise rate: incidents where attacker activity reappears within 30 or 90 days of eradication; the clearest signal of premature or incomplete eviction.
• Eviction list completion: percentage of listed items executed and verified within the window.
• Non-human credential coverage: percentage of exposed service accounts, keys and tokens rotated in the eviction window, not afterwards. See NHI incident metrics.
• Time from containment to eradication: by severity; very short times on complex incidents can indicate skipped scoping, very long ones drifting observation.
• Evidence capture rate: percentage of priority hosts with memory and disk captured before isolation or rebuild.

Monitor after eviction for use of any rotated credential (failed authentications with old secrets are a strong re-entry signal), new credentials added to applications and service principals, and connections to infrastructure seen during the incident.

Framework mapping

Practitioner checklist

• Define in the IR plan which actions are containment (pre-approved, reversible) and which are eradication (planned, coordinated).
• Use written gates for the hand-off and record each decision with time, owner and accepted risk.
• Set a deadline and tripwires for any observation period.
• Capture memory, disk and identity logs before isolation or rebuild on priority hosts.
• Build an eviction list that includes service accounts, API keys, OAuth grants, CI/CD tokens and attacker-added app credentials.
• Remove persistence and attacker-created identities before rotating secrets.
• Rotate trust anchors (krbtgt twice, signing keys) in the documented order and timing.
• Revoke sessions and tokens explicitly, and confirm which applications must end their own sessions.
• Rotate every secret in stolen code or configuration, used or not.
• Monitor for re-entry for a defined period before declaring recovery.

Standards and references

• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NCSC: Cyber incident response processes
• Microsoft Learn: AD Forest Recovery, Resetting the krbtgt password
• Microsoft Learn: Revoke user access in Microsoft Entra ID
• AWS: Remediating potentially compromised AWS credentials
• MITRE D3FEND: Evict and Isolate techniques
• MITRE ATT&CK: T1098.001 Additional Cloud Credentials

Related NHI Mgmt Group resources: Incident Scoping and Containment Strategy Guide · Identity Incident Response Playbook · Secrets Rotation Runbook Template · Ransomware Response and Recovery Guide