ITDR

How it works

ITDR products monitor identity infrastructure itself, Active Directory, Entra ID, Okta, and other IdPs, for attack techniques like Kerberoasting, golden ticket forgery, MFA fatigue bombing, and impossible-travel logins, then correlate those signals across the identity layer instead of the network layer. Deployment is usually an agent on domain controllers plus API integration into the IdP, feeding alerts into your SIEM or XDR rather than replacing it. Vendors include Microsoft Defender for Identity, CrowdStrike Falcon Identity Protection, SentinelOne Singularity Identity, and Semperis.

When it matters

ITDR matters because identity is now the primary attack surface at most companies; Verizon's DBIR has put credential-based attacks near or above 80% of breaches for several years running. If your only identity monitoring is manually reviewing IdP login logs, you will miss a Kerberoasting attack in progress because it doesn't look like a failed login, it looks like a normal service ticket request. Skipping ITDR means your MFA and zero trust investments have no detection layer behind them once an attacker gets past authentication.

Common misconceptions

• "MFA makes ITDR unnecessary." MFA blocks some initial-access paths. It does nothing once an attacker holds a valid session token or compromises a service account exempt from MFA.
• "ITDR is just SIEM with an identity dashboard." SIEM correlates logs after the fact. ITDR is built to recognize identity-specific attack chains, like an AD replication request that looks legitimate but isn't, that generic log correlation misses.
• "This only matters for on-prem Active Directory shops." Cloud-only teams running Entra ID or Okta carry the same exposure; the vendors above cover cloud-native IdPs too.