I've watched two identity threat detection and response (ITDR) procurement cycles fall apart in the last year, both at companies close enough that I sat in on the vendor calls.
The first was a 3,500-person SaaS shop on Okta and Microsoft E3, drowning in service account sprawl, that had narrowed to two finalists before anyone pulled the Okta System Log API and looked at what was already in their security information and event management (SIEM) platform.
By month three the buyer realized that half of the new tool's alerting overlapped with detections they already had, and the capability gap they wanted closed was thinner in the vendor than the demo suggested. The second cycle went sideways for different reasons but the same root cause, which is why I now run the audit before I take the first vendor call.
ITDR sits in the gap between your endpoint detection and response (EDR), your SIEM, and your identity provider (IdP), which is the detection layer where credential theft, session hijacking, privilege escalation, and federation abuse live.
Microsoft's 2025 Digital Defense Report describes the shift as "adversaries aren't breaking in, they're logging in," with identity-based attacks up 32% in the first half of 2025, and CrowdStrike's 2025 Global Threat Report put malware-free detections at 79%.
Most teams I work with end up in an awkward middle where their existing stack covers more than the vendor pitching them will admit, and the remaining gap turns up somewhere the audit never thought to look.
In brief:
- ITDR detects attackers operating with valid credentials, who aren't dropping malware so much as authenticating their way into your IdP, SaaS apps, and OAuth grants.
- Most teams already cover the basics through their existing SIEM, including password spray, multi-factor authentication (MFA) abuse, and IdP-log detection, so the gap is narrower than vendor pitches imply.
- The remaining gap shows up at four hard limits: Entra ID P2 licensing, slow-and-low spray below thresholds, cross-system hybrid attack chains, and Kerberos ticket forgery.
- Whether you fix it with detection engineering or a new tool depends on which of those four limits applies to your environment.
What ITDR catches
ITDR is the practice of detecting and responding to attacks that exploit identity infrastructure instead of dropping malware on endpoints. The patterns it catches include credential abuse, account takeover, session hijacking after MFA, OAuth and consent grant abuse, adversary-in-the-middle (AiTM) phishing, Kerberos ticket forgery, federation abuse, and lateral movement that rides on legitimate sessions.
Most of these patterns are invisible to the rest of your detection stack, since an attacker operating an Okta session from a residential proxy IP isn't going to generate an EDR alert, and the user whose GitHub OAuth grant got abused by a malicious app last weekend didn't trip a network signature either.
The abusive token activity sat inside GitHub audit logs the SOC may or may not have been ingesting, and when SCATTERED SPIDER calls your help desk and walks them through an admin MFA reset, none of it shows up in CloudTrail.
The trail is in the IdP system log and the help desk ticketing system, and nobody is correlating the two in real time, which is the gap ITDR exists to close.
Your identity plane has no dedicated monitor
EDR was scoped to endpoint behavior and SIEM to log aggregation, with identity-layer activity falling in the gap between them.
Your EDR and SIEM can't see the identity layer
The gap is architectural, in that attackers route around your tools instead of going through them, and your existing detection stack was never built to follow that path.
Your EDR watches processes on endpoints, while your SIEM correlates whatever logs you feed it, which in most shops includes the IdP system log but rarely with identity-specific detection content tuned against it.
Neither tool maintains an identity graph, meaning the view of which accounts and privileges connect across your environment is exactly where the attack path lives.
Where ITDR sits in a stack you've already paid for
ITDR watches the authentication flows, token issuance, and privilege changes your other tools weren't built to monitor directly, and while your SIEM can ingest the same logs, dedicated ITDR tools correlate them on a schema built for identity.
Placement depends on the architecture you're starting from. CrowdStrike shops typically evaluate Falcon Identity Protection inside the Falcon console, Microsoft E5 customers get Defender for Identity (which relies on sensors on domain controllers, so uncovered DCs are explicitly not covered), and Okta customers evaluate Okta Identity Threat Protection or a third-party tool correlating Okta System Log events with Active Directory and cloud identity telemetry.
The architecture question I usually open with is which IdP holds the production identities and what licensing tier it runs at, since that pair of answers is usually enough to narrow the shortlist before any vendor walks in.
Attackers stopped deploying malware and started logging in
Credential theft, session hijacking, and federation abuse are the problem set
The numbers back the category up. Mandiant M-Trends 2025 reports stolen credentials hit the number-two initial infection vector at 16%, the Verizon 2025 Data Breach Investigations Report (DBIR) found stolen credentials involved in 22% of breaches, and Microsoft's Digital Defense Report 2025 shows identity-based attacks rose 32% in the first half of 2025.
The tactics, techniques, and procedures (TTPs) that keep my team up at night exploit legitimate protocol behavior in ways the protocols were never designed to flag.
Golden Ticket attacks forge Kerberos Ticket Granting Tickets (TGTs) that the Key Distribution Center (KDC) itself can't distinguish from real ones, APT29 used Golden Security Assertion Markup Language (SAML) in SolarWinds, and SCATTERED SPIDER is still running help desk social engineering campaigns to reset MFA and hijack single sign-on (SSO) sessions.
None of these techniques are new, and the documentation is detailed enough that your existing stack should be catching more of it than it currently is.
MFA bypass made identity the new endpoint
The Microsoft Digital Defense Report 2025 adds nuance to the MFA story, in that token theft and AiTM phishing are the growth techniques, and once an attacker has a post-authentication session token, MFA is irrelevant for that session.
The Verizon DBIR 2025 found 46% of infostealer-compromised systems with corporate logins were unmanaged devices hosting both personal and business credentials, which describes the risk pattern cleanly: an employee logs into their corporate Okta tenant from a personal laptop, the token gets harvested by an infostealer, sold through an access broker marketplace, and replayed from a different continent.
Your SIEM logs the replay as a successful login because, from the IdP's perspective, that's exactly what a successful login looks like.
Your stack covers more than vendors claim, but it has hard limits
Native IdP logs cover more than you'd expect
Before I sign a PO, I want to know what I already have. Okta's System Log API surfaces the events you'd be building detections on anyway, including user.mfa.factor.reset_all, API token creation, admin deactivation patterns, and a wider set of admin-tier signals that Okta's security team publishes detection guidance for (super admin deactivation, log stream disabling, and MFA policy downgrades are all documented).
Your engineers can build password spray detection and OAuth consent grant monitoring from raw IdP logs in the SIEM, and the community rule repositories (Elastic's, Okta's, and the Sigma collections maintained by named researchers) cover most of what's left.
When a dedicated ITDR tool pays for itself
The build path has hard limits, and these are the four cases where I'd write the check:
- The Entra ID P2 licensing gate: Token Issuer Anomaly, SAML Token Issuer Anomaly, Unfamiliar Sign-in Properties, and Verified Threat Actor IP detections all require Entra ID P2, so if you're on E3 or P1, no amount of SIEM engineering closes that gap and you're either upgrading to E5 or buying a third-party tool. (I've watched buyers spend six months trying to engineer around this before concluding the same thing.)
- Slow-and-low attacks that evade thresholds: password spraying deliberately stays below lockout thresholds, and one attempt per user per hour across a thousand users walks straight past static SIEM rules built on per-user thresholds. ITDR tools use behavioral baselines tuned for that attacker pacing, and I haven't found a way to replicate that in-house cheaper than the tool license.
- Cross-system hybrid attack chains: when an attack chain traverses Okta to Amazon Web Services Identity and Access Management (AWS IAM) to Azure with incompatible schemas and no common correlation key across them, your SIEM rules miss the novel paths even when they're well-tuned. ITDR tools that maintain a unified identity graph close that gap, and the same approach covers non-human identity behavioral anomalies, which most teams I talk to still treat as a blind spot they haven't budgeted for.
- Golden Ticket and Silver Ticket detection: Golden Ticket attacks are hard to detect from standard logs, though Windows Security Event logs surface anomalies a tuned engineer can catch, while Silver Ticket bypasses the KDC entirely (the attacker forges a service ticket without ever needing to interact with the domain controller after initial compromise). If these techniques are in your threat model, standard telemetry leaves material gaps you should plan to close.
MDR providers don't cover identity by default
If you're running a managed detection and response (MDR) engagement, assume identity is a coverage gap until you've verified otherwise.
I learned this on a renewal at my last company, where we were on Falcon Complete and getting solid endpoint work out of them, and then we had a credential-stuffing incident where the alert came from the IdP rather than the EDR.
When I asked the account team about identity coverage on a follow-up, the honest answer was that Falcon Identity Protection would need scoping separately and the service level agreements (SLAs) around identity alerts weren't in our current contract, which is the conversation I now have before signing anything.
Falcon Complete covers identity threats only when Falcon Identity Protection is part of the deployment, and SentinelOne's Singularity Identity isn't default in Vigilance MDR either.
A handful of newer providers are extending into identity-anchored MDR from AI-native architectures, and Daylight is one I've sat through evaluations of, running with senior practitioners on follow-the-sun coverage, business context loaded into every investigation, and a published evidence chain attached to each verdict.
If your MDR contract doesn't specify the telemetry sources in scope (identity in particular), you're paying for endpoint coverage and guessing about the rest.
Most ITDR evaluations miss the structural questions
Vendor demos hide the gaps that matter most
Vendors demo well against human SSO flows and less well against service accounts and non-human identities, which often hold hundreds of times the permissions of any real user and rotate every 90 days.
The first thing I ask in a demo is whether the tool baselines those identities separately, and the answer is usually some flavor of "on the roadmap."
Integration claims deserve the same scrutiny. "Native integration with Okta" has meant, in calls I've sat through, anything from a Splunk connector that ingests Okta logs to a webhook that fires on a subset of events, and in one memorable case a CSV export from the customer's Okta admin that the vendor parsed offline.
Find out which version you're getting before the proof of concept (POC) gets scheduled.
Response actions are where the category sorts itself. Session revocation and conditional access blocking are containment actions you can use during an incident, while sending an alert to the security orchestration, automation, and response (SOAR) platform is reporting, and reporting isn't what I'm buying when I scope an ITDR tool.
Total cost of ownership also includes the analyst hours to maintain integrations and tune rules, which the license fee never reflects.
Track identity MTTD separately or you'll understate the gap
I track identity mean time to detect (MTTD) separately from endpoint MTTD when I report to leadership, because pooling the two understates the identity gap (valid-credential attacks rarely fire the same kinds of detections malware does). I establish a 90-day internal baseline and trend against it from there.
Mandiant M-Trends 2025 reports global median dwell time at 11 days, and the identity-specific number runs worse than that in the programs I've audited.
When I brief execs on coverage gaps, I frame them in business terms (saying "service accounts with access to financial systems that aren't yet monitored" lands with a CFO in a way that "ITDR coverage gap" never will).
If you do end up shortlisting tools, the names you'll see across analyst writeups and customer references are BeyondTrust, CrowdStrike, CyberArk, Delinea, Microsoft, Okta, and Saviynt, and the lens to weight them on is what they ship today rather than what's on the roadmap.
Before I take a vendor call, I run that four-gap audit against my own telemetry, and the audit doesn't always close cleanly.
What comes out the other side varies, with one team needing detection engineering work to close the SIEM-side gap, another needing the P2 license upgrade that had been deferred for two budget cycles, and a third ending up with a real business case for a dedicated tool. The line item I defend in budget review depends entirely on which.
Frequently asked questions about identity threat detection
Can my SIEM handle ITDR if I build the right detections?
Partially, yes. Credential stuffing, MFA abuse, and admin persistence all map to native IdP logs you can pipe into your SIEM, while the harder cases (Golden Ticket and Silver Ticket detection, session cookie hijacking from infostealers, cross-IdP attack chain correlation) don't translate cleanly to SIEM rules, which is where dedicated tooling earns its keep.
Do I need ITDR if I already have MFA everywhere?
MFA blocks the unauthorized access attempt at the front door but doesn't help you once an attacker has a post-authentication session token.
The Microsoft Digital Defense Report 2025 flags token theft and AiTM phishing as the growing techniques, and the Verizon DBIR 2025 found 46% of infostealer-compromised systems were unmanaged devices, which is exactly the population where MFA enforcement tends to be thinner in the first place.
Which ITDR vendors are rated highest by analysts?
The names that show up consistently across analyst writeups and customer references are BeyondTrust, CrowdStrike, CyberArk, Delinea, Microsoft, Okta, and Saviynt. Weight what each tool ships today against what's still on the roadmap, and pressure-test integration claims before the POC.
Does my MDR provider already cover identity threats?
Probably not at the depth you need, because Falcon Complete covers identity only if you've licensed Identity Protection, and Singularity Identity isn't default in Vigilance MDR.
The conversation to have with your account team is about the telemetry sources in scope and the detection content the provider runs against them, since asking "do you cover identity?" gets you a yes either way, while the specifics tell you what kind of yes you're getting.
What's the first metric I should track for an ITDR program?
Identity-specific MTTD, tracked separately from endpoint metrics. Pull 90 days of confirmed identity incidents and measure the gap between the earliest observable indicator and the timestamp on the alert that fired, since that gap is the audit's actual target.