Thanks to the cloud, identity is now the primary attack surface in enterprise environments. Mandiant's M-Trends 2025 report, drawn from over 450,000 hours of incident response investigations, recorded a global median dwell time of 11 days in 2024, and when external parties, rather than internal teams, identified breaches, that number rose to 26 days. Adversaries moving through an environment using valid credentials can remain undetected for weeks.
This shift has exposed a gap that traditional security tools were not designed to close. Endpoint detection and response (EDR) monitors devices. Identity and access management (IAM) enforces who can access what. Neither one is watching for threats actively moving through the identity layer itself. Identity threat detection and response fills that gap.
The NIST National Vulnerability Database and CISA's Known Exploited Vulnerabilities catalog both show that credential abuse and identity-based attacks are common in the initial access or persistence phase of many major ransomware and nation-state intrusion chains. Attackers are not using zero-days as often as phishing a service desk employee and abusing their AD access gets them further, faster, and with far less noise. The identity infrastructure was never designed to be a detection surface. ITDR is the discipline that makes it one.
What is identity threat detection and response (ITDR)?
Identity Threat Detection and Response (ITDR) is a security discipline focused on protecting identity infrastructure from misuse. Where IAM governs access, ITDR detects and responds to threats targeting the identity systems themselves, including Active Directory, Entra ID (formerly Azure AD), and privileged account stores.
The category was named by Gartner in 2022 after analysts observed a consistent gap in security architectures, even in organizations that had deployed IAM, PAM, MFA, and EDR, yet attackers were still successfully abusing identity infrastructure because none of those tools were designed to detect threats in motion. ITDR addresses that gap by treating identity systems as a threat detection surface.
A mature ITDR capability continuously monitors identity infrastructure for signs of compromise, detects anomalous behavior tied to credential misuse and privilege abuse, triggers automated or analyst-guided response actions, and provides enough forensic context for an investigation to understand scope and impact.
How ITDR differs from IAM, PAM, EDR/XDR, and SIEM
Security teams evaluating ITDR often ask how it relates to tools they already have. The honest answer is that ITDR overlaps with all of them at the edges but is not replaceable by any of them.
The critical distinction is what happens after a credential is compromised. IAM cannot distinguish a legitimate user from an attacker who stole that user's password. EDR/XDR may see suspicious process activity, but if the attacker is using native tools like PowerShell and legitimate admin utilities, there may be nothing for the endpoint agent to flag. ITDR looks at the identity plane itself, where authentication patterns, ticket requests, and directory queries reveal what is actually happening.
What to look for in an ITDR solution
Not every product that claims ITDR coverage delivers the same depth. The capabilities that define a credible ITDR implementation include:
Continuous identity posture assessment. ITDR should evaluate the security configuration of the identity infrastructure itself, not just behavior. This means finding misconfigured service accounts, over-privileged users, stale delegations, and Entra settings that create exploitable attack paths.
Effective permissions calculation. Assigned roles and group memberships rarely reflect what an identity can actually do. In hybrid and cloud environments, effective permissions emerge from the intersection of direct role assignments, nested group memberships, inherited permissions, service principal delegations, and conditional access exceptions. An ITDR solution should compute effective permissions rather than rely on nominal role listings, because attackers target the gap between what an account appears to have access to and what it can actually reach. Knowing which accounts hold effective admin-equivalent access, even without explicit admin role assignments, is essential context for both detection prioritization and blast radius assessment during an active incident.
Real-time behavioral detection. The system needs to analyze authentication and authorization activity across cloud identity providers and federated services, including sign-in events, token issuance, conditional access evaluations, API calls, and cross-tenant access patterns. This extends to Kerberos and LDAP, and cloud signals like anomalous OAuth consent, impossible travel, token reuse, or session hijacking become primary indicators. Anomalies such as a service principal initiating unfamiliar API activity, a user granting high-risk application permissions, or authentication patterns that deviate from established device and network baselines should trigger high-fidelity alerts rather than contributing to alert fatigue.
Cloud identity and hybrid directory protection. Modern identity infrastructure spans platforms like Microsoft Entra ID alongside on-premises Active Directory. ITDR solutions must collect native telemetry from identity providers, including sign-in logs, audit logs, token activity, and directory changes, while maintaining visibility into synchronization mechanisms such as AD Connect. High-risk scenarios include privilege escalation through role assignments, abuse of service principals, manipulation of federation trust settings, and persistence through backdoor applications or credentials. Without coverage of both cloud and hybrid identity layers, critical attack paths remain unmonitored.
Threat response integration. Detection without response is just alerting. In cloud environments, ITDR should be able to enforce conditional access policies dynamically, revoke active sessions and refresh tokens, disable or quarantine compromised accounts, remove malicious OAuth grants, and trigger automated SOC workflows. Response actions should align with risk signals and confidence levels, enabling rapid containment of identity-based threats without unnecessarily disrupting legitimate access.
Forensic investigation support. When analysts need to understand the scope of an identity-based compromise, they require timeline reconstruction across cloud and hybrid identity systems. This includes correlating sign-in activity, token usage, application access, privilege changes, and lateral movement across SaaS and infrastructure environments. The ability to trace how a compromised identity traversed systems through federated access, API calls, or delegated permissions is what distinguishes ITDR from basic anomaly detection and enables accurate scoping and remediation.
Identity attack surface management
Before detection can be effective, identity infrastructure must be understood as a cloud-exposed attack surface. This is the domain of identity attack surface management (IASM), a discipline that sits adjacent to ITDR and focuses on continuously identifying exploitable conditions across cloud identity providers, SaaS applications, and federated access paths.
Most enterprise environments built on platforms like Microsoft Entra ID accumulate configuration drift over time. Applications are granted permissions that are broader than required. Service principals and OAuth apps retain persistent access long after their original use case has ended. Users are assigned privileged roles temporarily but never de-scoped. External identities and guest accounts accumulate through B2B collaboration without consistent governance. Conditional access policies are layered incrementally, creating gaps or unintended exceptions.
Each of these conditions represents an attack path that does not require malware or noisy behavior. An attacker who compromises a user account can consent to a malicious OAuth application, inherit existing permissions, and gain persistent API access without triggering traditional detection mechanisms. Similarly, abuse of refresh tokens or misconfigured federation trust can allow long-lived access that bypasses password resets entirely. These are legitimate configurations operating in unintended ways.
IASM addresses this by continuously evaluating cloud identity configurations and access relationships against known attack paths. This includes identifying over-privileged roles, risky OAuth grants, excessive API permissions, stale service principals, weak conditional access coverage, and trust relationships that enable cross-tenant or hybrid pivoting. In hybrid environments, this extends to synchronization paths between cloud identity and on-premises directories, where compromise in one layer can propagate to the other.
An IASM assessment identifies where exploitable conditions exist across identity systems, while ITDR detection identifies when those paths are actively being used. Organizations that combine both approaches reduce alert volume by eliminating entire classes of attack paths before they are exploited. The detections that remain are higher fidelity because they represent activity in areas that should already be secured.
This is why ITDR evaluations should include identity posture assessment as a core capability, not just behavioral detection. A system that only detects activity in flight cannot identify that a dormant OAuth application, excessive API permission, or misconfigured conditional access policy already provides a path to persistent compromise.
MFA fatigue and modern credential attacks
The threat landscape ITDR must address extends beyond classic Active Directory exploitation. MFA fatigue attacks have become a reliable initial access technique. In an MFA attack, an attacker who has obtained valid credentials triggers repeated MFA push notifications to the target user's device, hoping the user will eventually approve one to stop the interruptions.
CISA published guidance on this technique after it appeared in several high-profile breaches involving technology and healthcare organizations. The attack requires no malware, no vulnerability, and no network presence before the MFA approval. Once the user approves the request, the attacker has a valid, authenticated session indistinguishable from a legitimate one.
ITDR detection of MFA fatigue requires behavioral analysis at the authentication layer. Signals include repeated failed MFA challenges within a short window, authentication attempts from IP addresses with no prior history for the account, and successful authentications that follow a pattern of rejected prompts. None of these signals is unusual in isolation, which is why detection depends on correlation rather than threshold alerting.
The same logic applies to credential stuffing, where attackers test large volumes of breached username and password combinations against enterprise login portals. A single failed login means nothing. Thousands of failed logins across thousands of accounts from rotating IP addresses over a 48-hour window is credential stuffing, and it requires identity-layer visibility to detect because no individual endpoint is involved.
These attack patterns illustrate why ITDR cannot be reduced to Active Directory monitoring alone. The identity attack surface includes every authentication system, every federated identity provider, and every external-facing login endpoint. In hybrid environments, a credential stuffing campaign that compromises an Entra ID account can be the first step toward pivoting to on-premises AD through synchronization relationships, which makes hybrid coverage a requirement rather than an option.
How ITDR protects from lateral movement
Okta, Entra ID, Active Directory, and similar services are the target of many major ransomware and nation-state intrusions, because whoever controls AD controls the network. Attackers who reach a domain controller can create accounts, change passwords, disable security tools, and deploy payloads across every domain-joined system simultaneously.
The attack path typically looks like this:
At each stage, identity-based signals exist that ITDR can act on, but in cloud environments, those signals originate from authentication flows, token activity, and application access rather than Kerberos or LDAP. In platforms like Okta and Microsoft Entra ID, this includes anomalous sign-in patterns, suspicious MFA behavior, token reuse across geographies, and high-risk OAuth or SAML activity. A user who suddenly begins accessing unfamiliar SaaS applications, a service account initiating new API calls, or a spike in failed and successful authentication attempts across multiple tenants are all indicators of credential misuse or session compromise. Detection at the point of token issuance or anomalous access is critical because once a valid session is established, attackers can operate without generating traditional network or endpoint signals.
Persistence in cloud identity systems often takes the form of application and token abuse. An attacker with sufficient privileges can register a malicious OAuth application, grant it persistent API access, and maintain control even after the original credentials are reset. Similarly, abuse of refresh tokens or manipulation of federation settings can allow long-lived access that survives password changes and standard remediation steps. These persistence mechanisms are frequently underdetected because they rely on legitimate identity features rather than exploits. ITDR solutions that monitor application registrations, consent grants, token lifecycles, and federation changes provide a detection layer that many SIEM-based approaches miss or treat as low-priority noise.
The reason these attacks succeed so often is that they generate no malware, no unusual binaries, and no activity that endpoint-focused tools are designed to detect. They rely on valid credentials, trusted identity providers, and standard protocols like OAuth and SAML. Without a system specifically analyzing identity-layer behavior across cloud services, these attacks remain effectively invisible.
ITDR closes this visibility gap by treating identity events from cloud providers as a primary detection signal. Integrated with a SOC detection and response capability, these signals can be correlated with endpoint and network telemetry to build a complete picture of attacker behavior, enabling faster investigation and more precise containment in SaaS and hybrid environments.
ITDR and MITRE ATT&CK
The MITRE ATT&CK framework maps the specific techniques adversaries use across attack stages. ITDR capabilities map most directly to three tactic categories, and security teams should evaluate vendors against coverage of specific techniques rather than general claims.
Credential Access (TA0006): This covers techniques including Kerberoasting (T1558.003), AS-REP Roasting (T1558.004), LSASS credential dumping (T1003.001), and DCSync (T1003.006). ITDR solutions should detect all of these natively, with high-fidelity alerts that carry enough context to distinguish a penetration test from an active attack.
Discovery (TA0007): Attackers performing reconnaissance use techniques like Account Discovery (T1087.002), Domain Trust Discovery (T1482), and Permission Groups Discovery (T1069.002). Behavioral baselines built from normal LDAP query patterns make these queries detectable even when they come from accounts with legitimate access.
Lateral Movement (TA0008): Pass-the-Hash (T1550.002), Pass-the-Ticket (T1550.003), and Remote Service abuse all involve identity-layer activity that ITDR is positioned to detect. The correlation between an anomalous Kerberos ticket request and a subsequent remote login to a high-value server is exactly the kind of multi-event pattern that ITDR analytics should surface automatically.
Mapping ITDR coverage to MITRE ATT&CK is useful not just for procurement decisions but for communicating detection posture to leadership. CISA's guidance on identity-based attacks references ATT&CK techniques explicitly, making this mapping a useful common language across security, compliance, and executive conversations.
ITDR in a Zero Trust architecture
Zero Trust's core principle, "never trust, always verify," depends entirely on the assumption that the identity verification itself is trustworthy. If an attacker can abuse identity infrastructure to generate valid tokens or impersonate privileged accounts, the Zero Trust model breaks down from the inside.
ITDR is the control that validates the integrity of the identity layer that Zero Trust relies on. Without it, Zero Trust architectures have a blind spot because they enforce access policies based on identity assertions, but cannot detect when those assertions have been compromised.
In practice, this means ITDR sits alongside IAM and PAM as a continuous validation mechanism. IAM enforces policies. PAM vaults credentials. ITDR monitors for evidence that those controls have been bypassed. An AI-native SOC architecture can integrate all three data streams, correlating identity anomalies with endpoint and network signals to detect attacks that cross detection layers.
The NIST Cybersecurity Framework identifies identity management and access control as foundational capabilities under the "Protect" function, with detection of anomalous access as a "Detect" function requirement. ITDR is where those two functions connect. It applies detection logic to the assets that the access controls are designed to protect.
For organizations running hybrid environments with both on-premises Active Directory and Entra ID, ITDR coverage needs to span both. Attackers increasingly exploit the synchronization relationship between on-premises AD and cloud identity to pivot from one environment to the other.
What agentic AI adds to identity threat response
Most ITDR solutions today operate in an alert-and-investigate model, where the system flags suspicious activity, and an analyst decides what to do. This works when the volume of alerts is manageable, but identity-based attacks often generate dozens of correlated signals across a short time window. By the time a human analyst has reviewed the queue and begun investigating, a fast-moving attacker may have already escalated privileges.
Agentic SOC capabilities change this dynamic by enabling automated investigation and response to identity-based threats without requiring a human analyst to initiate each step. When an ITDR system detects suspicious identity activity in Entra ID or Okta, such as anomalous token usage, impossible travel, risky sign-ins, or privilege escalation events, an agentic AI can immediately correlate signals across the environment. It can pull endpoint telemetry tied to the user session, analyze recent authentication patterns and conditional access decisions, validate whether the source IP or device appears in threat intelligence feeds, compute the identity’s effective permissions across nested groups, delegations, and inherited roles rather than relying on nominal role assignments, and map the potential blast radius across SaaS and cloud workloads. In parallel, it can generate a containment plan, such as revoking active sessions, enforcing MFA reauthentication, disabling the account, or tightening access policies, before the alert reaches an analyst’s queue.
This is not the same as AI-assisted triage, where a model scores alert priority but a human still performs the investigation. Agentic response means the investigation itself happens autonomously, with human-in-the-loop decisions reserved for the response actions that carry material risk or require policy judgment. The difference in time-to-context is substantial: minutes versus hours for the initial investigation, and seconds versus minutes for automated containment of high-confidence threats.
The blast radius question is particularly important in identity-based incidents. A compromised domain admin account may have access to hundreds of systems, dozens of applications, and years of sensitive data. Understanding that scope quickly enough to contain the damage requires the kind of parallel investigation that human analysts cannot execute manually under time pressure. Agentic AI can traverse the account's access graph, identify which systems it has authenticated to recently, and flag downstream systems that may have been accessed before the alert was raised, all within the time it would take an analyst to open the first ticket.
For security teams assessing AI detection capabilities that include identity threat coverage, the relevant question is not whether the system generates alerts, but whether it can complete an investigation and recommend or execute a response action without human intervention at each step.
What ITDR means for your security program
The identity layer is now where most enterprise breaches play out. Attackers have learned that bypassing authentication controls is faster and quieter than fighting through perimeter defenses, and that Active Directory provides a leverage point that turns a single compromised credential into total network access.
Identity threat detection and response is the security discipline built specifically for this threat pattern. It does not replace IAM, PAM, EDR/XDR, or SIEM, unless the system is fully built out to include ITDR. It covers the detection gap that those tools leave open, which is everything that happens after an attacker has valid credentials and before they have triggered a response.
The most effective implementations treat ITDR not as a standalone product but as a capability integrated into the full SOC lifecycle. An AI SOC that includes ITDR as a native component can correlate identity signals with endpoint, network, and cloud telemetry in a single detection and response workflow. Instead of an analyst pivoting between an identity tool and a SIEM to reconstruct what happened, an integrated AI SOC surfaces the complete attack chain, from initial credential abuse through lateral movement to privilege escalation, in one investigation context. That integration is what makes response fast enough to matter. Identity-based attacks move quickly, and a detection capability that operates in a separate silo, requiring manual handoff to the broader SOC, will consistently lag behind the pace of the threat.
Frequently asked questions
How is ITDR different from IAM and PAM?
IAM and PAM are access governance tools. They define and enforce who can access what. ITDR detects threats that bypass or abuse those controls. An attacker with a stolen privileged credential has already defeated IAM and PAM. ITDR is what detects the misuse of that credential in real time.
Is ITDR part of endpoint detection and response?
No. EDR focuses on threats affecting devices, including malware, process injection, and file-based attacks. ITDR focuses on threats affecting identity infrastructure, including Active Directory, Kerberos, and authentication systems. The two are complementary. Many identity-based attacks generate no endpoint signals because they use legitimate credentials and native tools.
How does ITDR differ from SIEM and UEBA?
SIEM ingests and correlates log data from across the environment, while UEBA builds behavioral baselines to flag anomalous user activity. Both are broad-scope tools. They process signals from many sources but treat identity events as one input among many. ITDR is purpose-built for the identity layer. It collects native telemetry from Active Directory, Entra ID, and cloud identity providers rather than relying on forwarded logs, which means it has deeper visibility into authentication flows, directory changes, and token behavior. A SIEM may surface a suspicious login, an ITDR can explain what happened at the identity infrastructure level, correlate it with lateral movement indicators, and trigger a targeted response. The two are complementary, and an AI SOC should encompass both categories.
Can ITDR prevent Active Directory, Entra ID, or Okta attacks?
ITDR is primarily a detection and response capability, not a preventive one. It cannot block a stolen password from being used. What it can do is detect the behaviors that follow credential theft, including Kerberoasting, and lateral movement, quickly enough to contain the attack before domain compromise occurs. Reducing mean time to detect on identity-based threats is the core value proposition.
What are the core capabilities of an ITDR solution?
A credible ITDR solution monitors identity infrastructure continuously, detects behavioral anomalies in authentication and directory activity, provides native Active Directory and Entra ID coverage, integrates with SOC response workflows, and supports forensic investigation of identity-based incidents.
What MITRE ATT&CK techniques does ITDR cover?
ITDR maps primarily to Credential Access (TA0006), Discovery (TA0007), and Lateral Movement (TA0008). Key techniques include DCSync (T1003.006), Kerberoasting (T1558.003), Pass-the-Hash (T1550.002), and LDAP-based reconnaissance (T1087.002, T1069.002). Coverage depth across these techniques varies significantly between vendors.
