The fastest-growing breach pattern of the past three years does not exploit a vulnerability in the conventional sense. It exploits the assumption that valid credentials mean authorised access. An attacker who obtains a corporate user’s username and password — through phishing, infostealer purchase, or credential stuffing — authenticates to the corporate VPN or identity provider with credentials that are indistinguishable from legitimate use. They move laterally through the environment, escalate privileges, and exfiltrate data. The SIEM sees authenticated sessions. The EDR sees legitimate process execution. Nothing fires.
Identity Threat Detection and Response (ITDR) is the category that addresses this gap. It exists because the controls organisations have invested in — SIEM, EDR, network monitoring — were not designed to reason about identity behaviour patterns, and the attacks exploiting identity have outpaced the tooling built to stop them.
What ITDR Is
Gartner introduced “Identity Threat Detection and Response” as a category in 2022. The core proposition is straightforward: treat identity infrastructure — Active Directory, Entra ID (Azure AD), Okta, IAM roles, service accounts, API tokens — as a security monitoring domain in the same way endpoint security teams treat processes and files.
ITDR platforms sit between identity infrastructure and the rest of the security stack. They ingest signals from directory services, identity providers, authentication logs, and privileged access management systems, then apply behavioural analysis to detect patterns that indicate identity-based attacks in progress.
The patterns ITDR looks for are categorically different from what SIEM rules typically catch:
- Kerberoasting: Requesting service tickets for service accounts at an unusual rate, followed by offline cracking
- Pass-the-ticket / Pass-the-hash: Lateral movement using harvested Kerberos tickets or NTLM hashes rather than cleartext credentials
- DCSync: Replicating domain controller data using directory replication protocols — what Mimikatz uses to dump all domain credentials
- Golden Ticket and Silver Ticket attacks: Forged Kerberos tickets that persist after password resets because they are signed with the KRBTGT account key
- Session token theft: Extracting authenticated browser sessions from endpoints to replay access without requiring credentials
- Unusual service account behaviour: Service accounts authenticating from unexpected hosts, at unexpected times, or accessing resources outside their normal pattern
- Privilege escalation via group membership changes: Adding a user to Domain Admins or a privileged Azure AD role
These attack techniques are not invisible — they produce signals in authentication and directory logs. What ITDR adds is the context and correlation logic to recognise them as attacks rather than noise.
Why SIEM and EDR Do Not Close This Gap
The question executives ask most often: “We have a SIEM ingesting AD logs. Why isn’t that enough?”
The answer is signal-to-noise ratio and the absence of identity context in generic correlation rules.
A SIEM rule that fires on “unusual authentication volume” does not know that the authenticating account is a service account that should never authenticate interactively, or that the target resource is a highly privileged share accessed only by four people. SIEM rules written generically generate enormous false positive rates against identity events; rules written specifically require the kind of domain knowledge about identity behaviour that most SIEM engineering teams don’t have.
EDR tools have a different problem. EDR is excellent at detecting malicious process execution on endpoints — the running of Mimikatz, the injection of a credential-harvesting DLL. Modern attackers increasingly avoid these patterns. DCSync, for example, executes using legitimate Windows replication APIs over the network — there is no malicious process on the attacker’s machine for EDR to detect. The attack is expressed entirely in directory service protocol calls.
The blind spots compound in cloud environments. Entra ID token theft — extracting authenticated session tokens from a browser or from device memory — produces a valid token that can be replayed from any IP address. The attacker’s sign-in looks like a fresh authentication from a new location. Unless there is explicit conditional access logic or impossible travel detection tuned for this pattern, the access is permitted and undetected.
The Numbers Behind the Business Case
The business case for ITDR investment rests on two data points that have become consistent across major threat intelligence and incident response reports.
First, identity-based initial access and lateral movement appear in the majority of significant breaches. CrowdStrike’s 2026 Global Threat Report documents identity-based attacks as the primary technique in 79% of cloud breaches. Mandiant’s incident response data consistently shows Active Directory compromise as a component of nearly every ransomware deployment they investigate — the path from initial access to ransomware deployment runs through domain privilege.
Second, the dwell time before detection for identity-based attacks is significantly longer than for malware-based attacks. Legitimate credentials move laterally during business hours, access resources that the account holder legitimately uses, and generate no process-level anomalies. The absence of endpoint indicators extends the window during which the attacker operates undetected. Shorter dwell time directly reduces breach cost — the IBM Cost of a Data Breach Report correlation between detection speed and total breach cost is consistent year over year.
ITDR addresses both: it increases the probability of detecting identity-based attacks before they complete, which shortens the dwell time and reduces the probability of the highest-cost outcomes (mass credential compromise, domain admin takeover, ransomware deployment).
What ITDR Looks Like in Practice
A mature ITDR deployment has three components.
Identity posture assessment. Continuous monitoring of the identity environment for configurations that create attack risk: accounts with excessive privileges, service accounts with passwords that have never been rotated, legacy authentication protocols enabled on directories, users without MFA, Kerberoastable service accounts with weak encryption. This is not threat detection in the reactive sense — it is attack surface reduction by finding and remediating conditions that make attack easier.
Real-time threat detection. Behavioural analysis against authentication and directory event streams to identify attack techniques in progress. This operates at a different fidelity than SIEM rules — identity-aware baselines per user and account type, context about what a service account should and should not be doing, detection logic for specific attack techniques like DCSync and Golden Ticket that requires understanding of the Kerberos protocol.
Response integration. When a detection fires, the response actions available must be identity-aware: forcing re-authentication, suspending a session token, rotating credentials, disabling an account, or isolating a device from directory access. ITDR platforms integrate with identity providers (Okta, Entra ID, Active Directory) to execute these responses programmatically rather than requiring manual intervention at 2 AM when a DCSync attempt is detected.
The Vendor Market
The ITDR market has consolidated around three segments.
IAM vendor extensions: CrowdStrike Falcon Identity Protection, SentinelOne Singularity Identity, and Illusive (acquired by Proofpoint) offer ITDR as extensions of their endpoint or threat intelligence platforms. The integration benefit is correlated signals across endpoint and identity without requiring a separate data pipeline.
Identity provider native capabilities: Microsoft Entra ID Protection and Okta Identity Threat Protection provide ITDR capabilities within the identity platform itself, with the advantage of access to raw authentication signals not available to external tools. The limitation is vendor lock-in and typically narrower threat detection scope compared to dedicated ITDR tools.
Specialist platforms: Vectra AI Identity, Semperis, and Attivo Networks (acquired by SentinelOne) focus specifically on identity threat detection, often with deeper Active Directory–specific detection capabilities and deception-based detection (honeypots, honey tokens, canary accounts) to catch attackers during reconnaissance.
For most organisations, the evaluation criterion is where the identity telemetry already flows. An organisation heavily invested in Microsoft’s security stack should evaluate Entra ID Protection and Defender for Identity as a starting point before adding third-party tools. Organisations with significant Okta deployment should evaluate Okta’s native capabilities alongside specialist platforms.
What to Tell the Board
The board framing that lands most effectively:
The control gap is specific and describable. SIEM and EDR were built for the threats of the early 2010s — malware and external intrusion. The threat has shifted to identity exploitation. ITDR closes the specific gap that exists in the current tooling stack, not a hypothetical future risk.
The investment is justified by both probability and impact. Identity attacks are the most common breach pattern. Domain compromise — which ITDR is designed to detect — is the enabler of the highest-cost outcomes including ransomware deployment and mass data exfiltration. This is not a tail risk investment; it is core risk reduction.
The regulatory environment is moving toward it. The SEC’s cyber disclosure rules require timely disclosure of material incidents. NIS2 requires effective detection capabilities. An incident involving extended undetected domain compromise, followed by disclosure that the organisation lacked detection capabilities for known attack techniques, is a significant regulatory and reputational risk. ITDR reduces both the probability of that scenario and the defensibility exposure if an incident does occur.
The build-buy decision has largely resolved. Mature ITDR capabilities are available from vendors the board already knows — Microsoft, CrowdStrike, Okta. The discussion is about activating and configuring capabilities that may already be available under existing license agreements, not a greenfield investment.