RS.MI-02 says incidents are eradicated. Containment stops the spread. Eradication removes what caused the incident, which means the attacker's access, any persistence they set up and, where possible, the weakness they used to get in.
Declaring an incident closed without eradication is how companies get breached twice by the same party.
What good looks like
Eradication is a defined phase with actions and a way to confirm each one. Some actions are automatic through security tooling or features of operating systems and network devices. Others are chosen by responders, and some are carried out by a third party such as a managed security provider on your behalf. The result is verified: the malicious files, accounts, scheduled tasks, tokens and rules are gone, and the entry point is closed.
How to implement it
- Build an eradication checklist per incident type. For account compromise: reset credentials, revoke sessions and tokens, remove forwarding rules and rogue app grants, review multi factor methods. For malware: remove it, check persistence points, rebuild if you cannot be sure.
- Prefer rebuild from known good sources for any system where you cannot establish the full extent of compromise.
- Find the way in. If an attacker used a vulnerable dependency or library, patch or replace it and check whether other services use the same one.
- Rotate every secret the attacker could have read: API keys, database passwords, signing keys, CI tokens.
- Re scan after cleanup and compare with the pre incident state.
- Hold eradication until forensic copies are taken, so evidence is not lost.
- Agree up front what a third party may remove on your behalf and who authorizes it.
Try it yourself
If the entry point was a vulnerable open source component, a free in browser dependency scan at https://gold.safeguard.sh/scan shows which packages in your manifest carry known CVEs, so you can check whether the same weakness exists elsewhere. Reachability analysis helps you judge which of those findings the code actually calls, which is useful when deciding what to fix first after an incident. If you want to see how fixing a flagged dependency flows from finding to closure, here is a walkthrough.
Click through it at your own pace, or open it full screen.
Evidence to collect
- Eradication checklists by incident type.
- Incident records listing actions taken, who did them, and verification results.
- Post cleanup scan output or endpoint health reports.
- Records of secrets rotated.
- Agreements with providers who perform eradication on your behalf.
Common gaps
- The visible malware is removed and the persistence is missed.
- Passwords are reset but API keys, OAuth grants and session tokens remain.
- The vulnerability used for entry is not patched, so the attacker returns.
- No verification step, only a belief that it is clean.
- Eradication starts before evidence is preserved.
- A third party cleans up and nobody records what they did.
Quick check
When should you rebuild instead of clean?
When you cannot be confident you found everything, such as a host with administrator level compromise. A rebuild from a known good image is slower to start and faster to trust.
How do you show eradication worked?
Show a verification record: the scan or review you ran after cleanup, the secrets you rotated, and the fix for the entry point, all tied to the incident ticket.
Sources
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST CSF 2.0 implementation examples for RS.MI-02, as listed in the CSF 2.0 Reference Tool: https://www.nist.gov/cyberframework
CSF is voluntary guidance. There is no CSF certification, so use it to organize and show your own work.
