Identity Compromise Response Checklist
A stolen password, session token or admin account. Work through 33 response steps in order — scope, contain, remove persistence, recover, notify, harden — with sample entries from a real-looking incident, and keep the record as you go.
Template & sample only — a structured starting point with sample content, not legal, audit, certification or investment advice.Customise it with your own details for free; exporting the generated document is part of Pro.
A working checklist for a stolen account, session or token: scope it, contain it everywhere at once, remove what the attacker planted, give access back safely, notify the right people and close the gap. Track each step as Not started, In progress, Done, Blocked or N/A with an owner and notes. The generated record doubles as the incident log for this playbook.
Your context
1. Detect and scope
Confirm what happened, to which accounts, and since when. Scope drives every later decision, so write it down even when it is still a guess.
Confirm the compromise signal and record the time you became aware, who decided, and on what evidencematerial
Export and preserve identity-provider sign-in and audit logs, the unified audit log and mailbox audit data before retention ages them outmaterial
Review at least 30 days of sign-ins for the account: new IPs, hosting-provider ASNs, unfamiliar user agents, impossible travel and successful sign-ins without an MFA prompt
Decide whether this is password theft, session or token theft (adversary-in-the-middle phishing, infostealer) or MFA fatiguematerial
Hunt for other accounts hit by the same campaign: same phishing URL or sender, same attacker IPs, same user agentmaterial
List what the account can reach: roles, groups, SSO apps, OAuth grants, delegated mailboxes, API keys and admin rights
2. Contain
Cut the attacker off everywhere at once. Partial containment tells the attacker you have noticed and gives them time to dig in.
Reset the password and block sign-in; for privileged or service accounts, disable first and reset secondmaterial
Revoke all refresh tokens and active sessions in the identity provider and in high-value apps that keep their own sessionsmaterial
Remove every MFA method on the account and re-register under a verified identity checkmaterial
Revoke OAuth consents and app passwords the user granted during or before the attack windowmaterial
Rotate keys the account held or could read: personal access tokens, SSH keys, cloud access keys, service principal secrets and certificatesmaterial
Block the attacker infrastructure and lure: sign-in policy for attacker IPs or countries, phishing domain at mail and web proxy, purge the lure from mailboxes
If an infostealer is possible, isolate the user's device and reimage it before issuing new credentials on itmaterial
3. Eradicate persistence
Assume the attacker planted a way back in during the window. Check every place they could have.
Mailbox persistence: inbox rules, external forwarding, delegates, send-as rights and mailbox-level forwardingmaterial
New app registrations, new service principals and new secrets or certificates added to existing appsMITRE ATT&CK T1098.001material
New admin role assignments, eligible privileged roles, new users, guest invitations and changes to privileged groupsmaterial
Federation and domain settings: new federated or verified domains, changed token-signing certificates, altered SAML or OIDC trustmaterial
Changes to conditional access, MFA exclusions, trusted locations and named IP ranges
Devices registered or joined by the attacker to satisfy device-based access policies
4. Recover
Give the user access back only after persistence checks are complete, with fresh credentials and phishing-resistant MFAmaterial
Undo what the attacker changed: restore deleted mail, correct altered records (payroll or supplier bank details), recall or correct messages they sent
Add heightened monitoring for 30 days: new MFA method, new consent, new device and sign-ins from new countries for the affected accounts
Agree a quiet period (for example 14 days with no attacker activity) before the incident is closed
5. Notify
Ask legal and privacy to assess whether personal data was accessed and which notification duties apply, with the awareness time on recordGDPR Art. 33material
Notify the cyber insurer in line with the policy's notice conditions before engaging outside responders
Warn people who received mail from the account during the attack window, and finance teams who might act on it
Brief the user's manager, the incident steering group and anyone whose systems are in scope; keep a decision log
6. Harden
Move admins, then finance and executives, to phishing-resistant MFA (FIDO2 security keys, passkeys or certificate-based)NIST SP 800-63Bmaterial
Restrict user consent to low-risk permissions from verified publishers and route everything else through an admin consent workflow
Remove standing admin rights: separate admin accounts, just-in-time elevation, approval for the highest roles
Shorten session lifetimes for privileged roles and enable token binding or continuous access evaluation where supported
Block legacy authentication protocols that cannot do MFA
Check break-glass accounts: at least two, excluded from policies only as designed, strong credentials stored offline, sign-in alerts on every use
Incident timeline
One row per event, in UTC. This becomes the backbone of the post-incident report.
Scope statement
What this template gives you
- Six phases: detect and scope, contain, eradicate persistence, recover, notify and harden — 33 steps, with the material ones marked.
- Containment covers what a password reset misses: revoking sessions and refresh tokens, removing attacker-added MFA methods, OAuth consents, app passwords and keys.
- The persistence sweep checks inbox rules, new app registrations and app credentials, new admins, federation and domain settings, conditional access changes and attacker-registered devices.
- The summary tells you whether containment is complete and whether the persistence sweep is clear, so access is not restored too early.
- Free to use and customise in your browser; exporting the record is part of any PlayCISO plan.
Frequently asked questions
Is resetting the password enough after an account takeover?
No. If the attacker stole a session or refresh token, it can keep working after a password change until you revoke it. Attackers also add their own MFA method, consent to an OAuth app, create inbox rules or add a credential to an app registration so they can come back. Reset, revoke sessions and tokens, remove attacker-added MFA methods and consents, then sweep for persistence.
Should we revoke access first or investigate first?
For an active compromise of a privileged account, contain first: the cost of the attacker keeping access is higher than the evidence you might lose. Export the logs you need in the first minutes, then cut access everywhere at once. For a low-privilege account with no sign of current activity, a short, time-boxed investigation to find every related account can come first so you contain the whole campaign in one move.
How long do stolen tokens stay valid after we revoke sessions?
Revoking sessions stops new access tokens being issued from the stolen refresh token. Access tokens already issued can stay valid until they expire, typically up to about an hour, unless the application supports continuous access evaluation. Applications that keep their own session cookies need to be signed out separately.
Is this a finished document I can rely on?
No. Every tool in this suite is a template with sample content. It gives you a structured, editable starting point and generates a document from your own answers, but it is not legal, audit, certification, investment or professional advice. Review and adapt the output, and have it checked by the appropriate specialist before you rely on it.
Who can use it?
Anyone. Using it and customising it with your own details is free, and your work is saved in your own browser. Exporting the generated document (Word, PDF, Markdown, CSV) is part of any PlayCISO paid plan.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.