ITDR vs EDR: Where Each Sees and Stops Identity Attacks

Endpoint detection and response watches what runs on a device, but many of today's intrusions never need to run anything malicious on a device you own. An attacker who replays a stolen session cookie from their own laptop, talks a help desk into resetting MFA, or uses a leaked cloud access key is acting entirely inside identity systems, and the endpoint sensor has nothing to see. Identity threat detection and response (ITDR) exists to cover that ground, but it has its own blind spots on the host. This guide compares the two at the level a detection engineer or security architect needs: what each tool actually observes, the threat model each fits, how each fails, what response actions each owns, and how to run them as one playbook. For the ITDR fundamentals, see the ITDR Guide; for endpoint tooling, the EDR Guide.

Key takeaways

• They watch different planes. EDR sees processes, files, memory and connections on managed hosts; ITDR sees authentication, token, directory and permission events in identity providers, directories and cloud control planes.
• Malware-free is now the norm. CrowdStrike's 2026 Global Threat Report says 82% of its detections in 2025 were malware-free, which is exactly the activity an endpoint sensor is least suited to judge on its own.
• Each has a hard blind spot. EDR cannot see sign-ins from unmanaged attacker devices or SaaS-to-SaaS token use; ITDR cannot see the infostealer or credential dumping on the endpoint that produced the stolen credential.
• Containment differs by plane. EDR isolates a host and kills a process; ITDR disables accounts, revokes sessions and refresh tokens, and removes persistence such as new MFA methods, app credentials and federation trusts.
• Non-human identities fall between them. Service accounts, workload identities and API keys often act from servers or cloud runtimes with no EDR agent and no interactive sign-in, so both tools need deliberate tuning to cover them.

Short answer: which one do you need?

Most organisations need both, because they answer different questions. EDR answers "what did this device do?" and ITDR answers "what did this identity do, and is it still the rightful owner?". If you have mature EDR and no identity detection, your largest gap is attacks that begin and end in your identity provider, directory and SaaS estate. If you have strong identity logging but patchy endpoint coverage, your largest gap is credential theft and lateral movement on hosts, which is usually where the stolen identity came from. The rest of this guide shows where to draw the boundary.

ITDR vs EDR compared

Threat model: what EDR is built to catch

Architecture in words: a sensor on each managed host records process, file, registry, memory and network events, applies local prevention, and streams telemetry to a cloud or on-premises console that correlates events into alerts and supports host-level response. Its strength is detail: it can show the exact process that read credential material or launched a remote session.

• Credential theft at source: infostealers harvesting browser cookies and saved passwords, and tools reading LSASS memory, are endpoint events. This is the stage that later becomes an identity attack, so EDR is often the first and best chance to stop it.
• Lateral movement with stolen material: pass-the-hash (T1550.002) and pass-the-ticket (T1550.003) leave process and logon traces on the source and destination hosts when both have sensors. See the Pass-the-Hash and Pass-the-Ticket Guide.
• Tooling on domain controllers: EDR on a domain controller can see suspicious processes and service installs on that server, which matters for DCSync tooling and NTDS extraction attempts.
• Payload delivery: ransomware and remote access tools still need to run somewhere, and EDR is the control that blocks them.

EDR failure modes for identity attacks:

• The attacker uses a stolen cookie or token from their own device (T1539, T1550.001), so no managed host is involved after the theft.
• The attack happens in the IdP or cloud console: help desk resets, new MFA registration (T1098.005), new app credentials (T1098.001) or a federation trust change (T1484.002).
• Kerberos abuse is legitimate protocol use. A Kerberoasting request (T1558.003) is a normal service ticket request from the host's point of view; the meaningful signal, such as an RC4 ticket for a service account that should only use AES, is on the domain controller.
• Remote management tools and even the EDR's own remote shell can be abused with valid credentials. CISA's Scattered Spider advisory (AA23-320A) describes the actors abusing the remote shell capabilities of EDR tools already installed on victim networks.
• EDR itself can be disabled or tampered with (T1685 Disable or Modify Tools). See the EDR Evasion and Defence Guide.

Threat model: what ITDR is built to catch

Architecture in words: ITDR collects authentication and change events from identity providers, directories, cloud IAM and SaaS platforms, builds behavioural baselines per identity, detects attack patterns and risky configuration, and drives identity-plane response through IdP and directory APIs. Some products add sensors on domain controllers to parse Kerberos and replication traffic. Its strength is context: it knows that a sign-in is the first from that device, that it follows a help desk reset, and that the account holds a privileged role.

• Session and token theft: the same session used from two networks or devices, token use after a password change, and refresh token use from new infrastructure. See the Session Hijacking and Cookie Theft Guide.
• MFA abuse: push volumes not tied to user-initiated sign-ins (T1621), adversary-in-the-middle phishing (T1557) and new methods registered after a reset. See the MFA Fatigue and Bypass Guide.
• Kerberos and directory attacks with no malware: Kerberoasting (T1558.003), golden and silver tickets (T1558.001, T1558.002) and DCSync (T1003.006). Microsoft's documentation for event 4769, which is generated only on domain controllers, recommends alerting on ticket encryption types other than 0x11 and 0x12, which surfaces RC4 (0x17) requests. See the Kerberoasting and AS-REP Roasting Defence Guide and Golden Ticket, Silver Ticket and DCSync Guide.
• Persistence in identity objects: federation trusts, OAuth consents, app secrets and role assignments that survive a password reset. CISA's Scattered Spider advisory describes actors adding a federated identity provider to the victim's SSO tenant and enabling automatic account linking so they could sign in as any account.
• NHI key and token misuse: cloud keys used from unfamiliar infrastructure (T1078.004), service accounts signing in interactively, and stolen application tokens (T1528). These map to OWASP NHI7:2025 Long-Lived Secrets and NHI10:2025 Human Use of NHI.

ITDR failure modes:

• Missing sources: a SaaS platform, secondary IdP or on-premises directory not connected, so its sign-ins never reach the detection logic.
• Cloud-only and service identities ignored: rules tuned for interactive human sign-ins miss workload identities, which authenticate with keys and certificates and never see an MFA prompt.
• Baselines that learn the attacker: long-lived credential abuse that began before deployment looks normal.
• No host context: ITDR can flag a token replay but not identify the infostealer that took it, so the same device keeps leaking credentials after every reset.
• Response permissions withheld: the tool can alert but cannot revoke, because nobody granted it, or the SOC, the IdP roles needed.

Worked scenario: one intrusion, two tools

A contractor's unmanaged laptop is infected with an infostealer that takes browser cookies and saved passwords, including an SSO session for your tenant and a cloud access key in a configuration file.

The pattern is typical. The Snowflake Breach 2024 began with infostealer credentials taken from machines outside the victims' control, then password-only logins accepted from anywhere: no customer endpoint was involved after the theft. The Storm-2949 Azure Attack 2026 ran on reset and MFA social engineering followed by method changes, and Microsoft says the actor did not rely on traditional malware. In both, the decisive signals were in identity logs.

Response: who revokes what

Containment is where the tools differ most, and where combined playbooks most often break. Isolating a laptop does nothing about a refresh token already replayed elsewhere; revoking sessions does nothing about an infostealer still running on the host.

• Token lifetimes: Microsoft's guidance for revoking access in Entra ID notes that access tokens are valid for about one hour by default and stay valid after sessions are revoked unless the application supports Continuous Access Evaluation; refresh tokens are revoked, and session tokens issued by applications themselves must be ended by those applications.
• Hybrid directories: the same guidance recommends disabling the on-premises account and, where compromise is possible, resetting the password twice to mitigate pass-the-hash, then disabling the user's registered devices.
• Browser sessions: Google Workspace documentation states that resetting a user's sign-in cookies signs them out of browsers and mobile devices but not desktop apps, and recommends revoking third-party app access and resetting the password. Identity providers are listed alphabetically; check your own provider's equivalent.
• Propagation: the OpenID Continuous Access Evaluation Profile 1.0 (final, 29 August 2025) defines events such as session-revoked, credential-change and device-compliance-change that let an identity provider and applications share revocations and EDR device health in near real time. See How to Revoke All Sessions for a Compromised User.

Combined playbook order for a suspected identity compromise:

1. ITDR or SOC: revoke sessions and refresh tokens, disable or force reauthentication, and block sign-in from the observed attacker infrastructure.
2. Identity team: remove attacker-added MFA methods, app credentials, OAuth grants, role assignments and federation changes, comparing against the audit log since first suspicious activity.
3. EDR: isolate every managed device the identity used recently, collect a triage package and hunt for infostealers and remote tools.
4. Rotate any NHI credentials the identity could read, starting with those in configuration files and secrets stores on affected hosts.
5. Restore access only from a clean device, with phishing-resistant MFA re-registered through a verified process.

Reversing steps 1 and 3 is the common mistake: isolating the device first tips off the attacker while their tokens remain valid. The Session Token Theft Response Playbook covers the full sequence.

Decision guidance

ITDR vs XDR: XDR platforms increasingly ingest identity signals, so the question becomes whether the XDR covers your identity sources, NHIs and response actions, not what the product is called. Test it against the scenario above. See the XDR Guide and ISPM vs ITDR.

Where identity fits: non-human identities

NHIs are the sharpest gap between the two tools. A service account on a Linux batch server may have an EDR agent on the host but authenticate to cloud APIs with a key; a workload identity in a managed cloud service has no host you can instrument at all. Practical coverage:

• Baseline each service account's source hosts, networks and APIs, and alert on interactive logons by service accounts (OWASP NHI10:2025 Human Use of NHI).
• Feed secrets manager reads and cloud key usage into identity detections, and alert on keys used from outside expected infrastructure.
• Use EDR on hosts that hold NHI credentials to detect reads of credential files and configuration by unexpected processes.
• Prefer short-lived, workload-bound credentials so a stolen value expires before it can be replayed. See the Service Account Security Guide.

Detection and measurement

• Source coverage: percentage of identity providers, directories, cloud accounts and critical SaaS platforms whose sign-in and audit logs reach ITDR detection; percentage of endpoints and servers with a healthy EDR agent.
• NHI coverage: percentage of service accounts and workload identities with a behavioural baseline or explicit allowed-source rule.
• Time to revoke: median minutes from identity alert to sessions and refresh tokens revoked, measured separately from time to host isolation.
• Persistence clean-up: percentage of identity incidents where MFA methods, app credentials and grants added during the incident were reviewed and removed.
• Correlated cases: share of identity incidents linked to an endpoint investigation of the source device, and the reverse.

Common failure patterns

• Assuming EDR covers identity: the SOC treats a clean EDR console as evidence of no compromise while sign-in logs show replayed sessions.
• Device-first containment: isolating hosts before revoking tokens, leaving the attacker active in SaaS.
• Human-only rules: identity detections that never fire for service principals, keys or agents.
• Uncorrelated MFA and reset events: repeated push prompts, help desk resets and MFA re-registrations not tied to the sign-ins that follow. In the Uber Breach 2022 a contractor password, believed taken by malware on a personal device, was followed by repeated approval requests until one was accepted: no managed endpoint saw either step.
• Single-reset recovery: resetting the password without removing attacker-added methods and grants, so access survives.
• No feedback to the endpoint: the leaking device is never found, so credentials leak again.

Framework mapping

Practitioner checklist

• List every identity source and confirm its sign-in and audit logs reach identity detection with enough retention to scope an intrusion.
• Deploy EDR to every domain controller and federation server, and collect event 4769 and replication events from domain controllers.
• Write one playbook that revokes sessions and tokens before isolating devices, and test it quarterly.
• Grant the SOC or ITDR tool the IdP roles needed to revoke sessions and remove MFA methods, with approval for privileged accounts.
• Add rules for service accounts, workload identities and API keys, not just interactive users.
• Correlate help desk resets and MFA registrations with the sign-ins that follow.
• When identity detection flags a stolen session, open an endpoint investigation for the source device, managed or not.
• Adopt CAEP or equivalent signal sharing where your IdP and applications support it.
• Validate both tools with simulated identity and endpoint attacks; see ITDR validation.

Standards and references

• CISA: Scattered Spider advisory AA23-320A
• OpenID Foundation: OpenID Continuous Access Evaluation Profile 1.0
• MITRE ATT&CK: Credential Access (TA0006)
• OWASP: Non-Human Identities Top 10 2025
• Microsoft Learn: Event 4769, a Kerberos service ticket was requested
• Google Workspace: Sign a user out of a managed Google Account
• Microsoft Learn: Revoke user access in Microsoft Entra ID
• CrowdStrike: 2026 Global Threat Report

Related NHI Mgmt Group resources: ITDR Guide, ITDR Buyer's Guide, EDR Guide, Identity Incident Response Playbook, ITDR vs UEBA.