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.
最も効果的な導入では、ITDRを単体製品としてではなく、SOCライフサイクル全体に統合された機能として扱います。ITDRをネイティブコンポーネントとして含むAI SOCは、IDシグナルをエンドポイント、ネットワーク、クラウドのテレメトリーと単一の検知・対応ワークフローで相関させることができます。アナリストが何が起こったかを再構築するためにIDツールとSIEMの間を行き来する代わりに、統合されたAI SOCは、最初の認証情報悪用からラテラルムーブメント、特権昇格に至るまでの完全な攻撃チェーンを、単一の調査コンテキストで明らかにします。この統合こそが、対応を実用的な速さにするものです。IDベースの攻撃は迅速に進行するため、個別のサイロで動作し、より広範なSOCへの手動での引き渡しを必要とする検知機能では、脅威の速度に常に対応が遅れてしまいます。
よくある質問
ITDRはIAMやPAMとどう違うのですか？
IAMとPAMはアクセスガバナンスツールです。誰が何にアクセスできるかを定義し、強制します。ITDRは、これらの制御を迂回または悪用する脅威を検知します。盗まれた特権認証情報を持つ攻撃者は、すでにIAMとPAMを突破しています。ITDRは、その認証情報の悪用をリアルタイムで検知するものです。
ITDRはエンドポイント検知・対応（EDR）の一部ですか？
いいえ。EDRは、マルウェア、プロセスインジェクション、ファイルベースの攻撃など、デバイスに影響を与える脅威に焦点を当てています。ITDRは、Active Directory、Kerberos、認証システムなど、IDインフラストラクチャに影響を与える脅威に焦点を当てています。両者は補完的な関係にあります。多くのIDベースの攻撃は、正規の認証情報とネイティブツールを使用するため、エンドポイントシグナルを生成しません。
ITDRはSIEMやUEBAとどう違うのですか？
SIEMは環境全体のログデータを取り込み、相関させますが、UEBAは異常なユーザーアクティビティを検出するために行動ベースラインを構築します。どちらも広範なツールです。多くのソースからのシグナルを処理しますが、IDイベントは数ある入力の一つとして扱われます。ITDRはIDレイヤーのために特別に構築されています。転送されたログに依存するのではなく、Active Directory、Entra ID、クラウドIDプロバイダーからネイティブなテレメトリーを収集するため、認証フロー、ディレクトリ変更、トークンの動作についてより深い可視性を持っています。SIEMは疑わしいログインを表面化させるかもしれませんが、ITDRはIDインフラストラクチャレベルで何が起こったかを説明し、それをラテラルムーブメントの指標と相関させ、ターゲットを絞った対応をトリガーすることができます。両者は補完的であり、AI SOCは両方のカテゴリを網羅すべきです。
ITDRはActive Directory、Entra ID、またはOktaへの攻撃を防ぐことができますか？
ITDRは主に検知・対応機能であり、予防機能ではありません。盗まれたパスワードの使用をブロックすることはできません。しかし、認証情報の窃取後に発生するKerberoastingやラテラルムーブメントなどの挙動を、ドメイン侵害が発生する前に攻撃を封じ込めるのに十分な速さで検知することができます。IDベースの脅威に対する平均検知時間を短縮することが、その中核的な価値提案です。
ITDRソリューションの主要な機能は何ですか？
信頼できるITDRソリューションは、IDインフラストラクチャを継続的に監視し、認証およびディレクトリ活動における行動異常を検知し、ネイティブなActive DirectoryおよびEntra IDのカバレッジを提供し、SOCの対応ワークフローと統合し、IDベースのインシデントのフォレンジック調査をサポートします。
ITDRはどのようなMITRE ATT&CKテクニックをカバーしていますか？
ITDRは主に、認証情報アクセス (TA0006)、探索 (TA0007)、およびラテラルムーブメント (TA0008) に対応します。主要なテクニックには、DCSync (T1003.006)、Kerberoasting (T1558.003)、Pass-the-Hash (T1550.002)、およびLDAPベースの偵察 (T1087.002, T1069.002) が含まれます。これらのテクニックに対するカバレッジの深さは、ベンダーによって大きく異なります。
