Why identity has a bigger blast radius than endpoint
A compromised mailbox can phish contacts, re-route payments, and forward sensitive mail outside the org in minutes. The ITDR response model is sharper than EDR's for that reason.
ITDR looks like EDR with different vocabulary. The incidents, recommendations, remediations, and isolation analogues are all present. The temptation is to bring the EDR tempo across. That misses the central thing. Identity has the biggest blast radius on the platform. The same minute of attacker access on an identity does more damage than on a typical endpoint, and the compromise playbook is sharper for it.
The radius is measured in users, not hosts
An EDR incident is mostly bounded to one host. The attacker has to do active work to spread. An identity incident is bounded by what the user can reach times how fast an attacker can act:
flowchart LR I["Compromised identity"] M["Mailbox<br/><em>read, send, delete,<br/>forward</em>"] C["Contacts<br/><em>phishing from a<br/>trusted mailbox</em>"] P["Permissions<br/><em>SharePoint, Teams,<br/>OneDrive</em>"] F["Financial workflows<br/><em>AP, AR, payroll</em>"] A["Delegated admin<br/><em>whatever the role<br/>can do</em>"] I --> M I --> C I --> P I --> F I --> A
Mailboxes are read in seconds. Forwarding rules apply immediately. Phishing emails to contacts can be sent within minutes. The damage compounds before anyone notices.
Three ways the response shape changes
Faster default actions. EDR’s containment action is isolation, strong but reversible without lasting impact on the endpoint. ITDR’s containment includes session revocation, password reset, and MFA reset. These are destructive by design. They kick the user out of their own account at the same time they kick the attacker out. The trade-off is accepted because the alternative, letting the attacker keep working while you verify, has higher cost.
Less waiting for user verification. On a High EDR incident with user-verify in the Recommendation, you call the user, confirm, then act. On many ITDR incidents the SOC’s Recommendation leads with “revoke sessions, reset password,” and user verification (was that you?) happens after the lockout. The sequence is reversed. The lockout is cheap to reverse on confirmation. The cost of waiting is higher.
Wider escalation triggers. Multi-user signals on the same tenant, admin-credential involvement, and OAuth grants from suspicious sources push the incident toward tenant-wide-compromise territory (lesson 14) faster than equivalent EDR patterns push toward Critical.
What stays the same
The keystone rules from the Beginner course still apply. The SOC has done the analysis. The tech reads the Recommendation. Second-guessing or acting on context instead of the Recommendation is the cardinal mistake. The aggressiveness of the response model doesn’t lower the bar on those.
Single-identity playbook execution is in scope for the helpdesk. Tenant-wide response is not.
A worked ticket: Able Moose Group
A High-severity ITDR Incident Report lands. User: bob.smith@example.com. Bob is Able Moose Group’s CFO. Summary: sign-in from an unusual country, followed within four minutes by an inbox rule that forwards mail with “invoice” in the subject to an external address. Recommendation: revoke sessions, reset password and MFA, remove the malicious inbox rule. Bob is in a board meeting and unreachable for the next two hours.