The ITDR buyer's guide

what ITDR is actually for

When prevention fails, there is a window between the moment an attacker gets in and the moment they do real damage. Across breaches generally, that window is alarmingly wide: the average time to identify and contain a breach runs into the hundreds of days (IBM, 2025). ITDR exists to shrink it for identity attacks specifically, by spotting the signals that an identity is being abused and cutting the attacker off before the dwell time turns into a disaster.

The signals it looks for are the fingerprints of identity attacks: a login that is geographically impossible given the last one, a flood of MFA prompts that smells like fatigue bombing, a session token showing up from a new device that suggests hijack, a dormant account suddenly waking up, a privilege quietly escalating, someone tampering with the identity provider's own configuration. None of these is necessarily caught by endpoint or network tools, because they happen in the identity layer, which is exactly the gap ITDR is built to close.

where buyers go wrong

The first mistake is buying detection before prevention. ITDR sits on top of a working identity foundation; it does not replace one. If your MFA is patchy, your offboarding is manual, and half your apps are outside single sign-on, fix that first, because ITDR will mostly just narrate attacks that better hygiene would have prevented.

The second is buying detection with no plan to respond. This is the big one. An alert that nobody sees, or sees and cannot act on, changes nothing. Either the tool needs to take automated action, like disabling an account or killing a session on its own, or you need someone, in-house or managed, whose job is to respond. Decide which before you buy, not after.

The third is confusing ITDR with the things next to it. Endpoint detection watches devices, a SIEM aggregates logs from everywhere, and XDR spans multiple domains. ITDR is the identity-focused slice, and it is sometimes a standalone tool, sometimes a feature of a broader platform you already run.

The fourth is a coverage mismatch. A lot of ITDR grew up around on-premises Active Directory, while plenty of modern attacks target cloud identity providers and SaaS. A tool that watches your AD beautifully and ignores your cloud IdP, or the reverse, leaves the attacker a clear lane. Match the coverage to where your identities and your risk actually live. Under all four is the familiar prerequisite: you cannot detect threats to an identity estate you cannot see.

before you shop: get the foundation and the response sorted

Two things need to be in place before ITDR makes sense.

First, the preventive basics. MFA enforced broadly, ideally phishing-resistant on what matters. A consolidated identity provider with apps behind single sign-on. Automated deprovisioning so leavers actually lose access. Privileged access under some control. ITDR is far more useful sitting on top of this than bolted onto a leaky foundation, so if these are not solid, that is the first spend, not ITDR.

Second, decide where alerts will go and who acts on them. If you have a security operations capability, in-house or through a managed provider, ITDR feeds it. If you do not, your realistic options are a tool that can respond automatically, or a managed detection and response service that does the watching and responding for you. Be honest about this now, because it changes which products even make sense. Then size yourself honestly: a small company with no security team and a cloud-only stack is in a completely different position from a regulated enterprise with a 24/7 SOC and a sprawling Active Directory.

the category in plain terms

what it detects

The core is watching your identity systems for attack signals. The useful ones include impossible-travel and anomalous logins, MFA fatigue and bombing patterns, signs of session or token theft like a token appearing from an unexpected device, dormant accounts reactivating, suspicious privilege escalation, risky changes to the identity provider's own configuration, and the lateral movement patterns where one compromised identity is used to reach others. The breadth and accuracy of this detection, across the identity systems you actually run, is the heart of what you are buying.

what it can do about it

Detection without response is the trap, so look hard at the response side. The strongest tools can take action on their own: disable a compromised account, force a re-authentication, revoke active sessions, or quarantine an identity, automatically and fast. Weaker ones only raise an alert and leave the doing to you. For a company without a 24/7 team, automated response is the thing that makes the tool worth owning.

where it watches

Three broad surfaces, and tools vary in which they cover well. On-premises Active Directory, still a major attack path in established companies. Cloud identity providers, where a growing share of modern attacks land. And SaaS and the broader cloud, including the machine identities that now outnumber humans. The best fit depends on where your identities live, and a tool strong in one surface and weak in another is common, so check explicitly.

the categories next to it

A SIEM collects and correlates logs from across your environment, identity included, but is not identity-specialized. XDR spans endpoints, network, and identity together, and often includes ITDR as one component. Endpoint detection watches devices. User behavior analytics looks for anomalies in how people act. And on the preventive side, identity security posture management is the cousin that finds weak identity configuration before an attack, which pairs naturally with the detection ITDR provides.

why this became its own category

Identity is now the primary battleground. Stolen and misused credentials are involved in a large share of breaches, the human element shows up in most of them, and the rise of real-time phishing that defeats MFA means catching the attacker after authentication has become essential rather than optional. The identity provider itself has become a top-tier target, as the major IdP breaches of recent years showed. Watching the identity layer specifically, rather than hoping a general tool happens to notice, is the gap ITDR fills.

what's right for your size and situation

• Lean / small (under ~50) · What good looks like: Turn on the identity-risk detection your IdP already includes, and make sure its alerts go somewhere a human sees. If you have no team to respond, a managed service that watches identity is more valuable than a tool you cannot action. · What to skip: A standalone ITDR platform with no one to respond to it.
• Growing mid-market (50 to 500) · What good looks like: Identity detection from your IdP or your XDR, with defined response playbooks, and either some in-house response or a managed detection service covering identity. Automated response for the clear-cut cases. · What to skip: Buying detection breadth you have no capacity to act on.
• Larger / multi-entity (500 to 2000) · What good looks like: A dedicated ITDR capability feeding a security operations function, covering both your cloud IdP and any Active Directory, with posture management alongside it. · What to skip: Watching only AD or only cloud when you run both.
• Enterprise / regulated (2000+, finance) · What good looks like: ITDR across all identity surfaces, integrated with the SOC and SIEM, automated containment, and the detection-and-response evidence regulators expect, running around the clock. · What to skip: Any blind spot in coverage an attacker can route through.

A few situations change the answer regardless of size. No security team: managed detection and response that covers identity is almost always the right answer over a tool you cannot run. Heavy Active Directory or legacy: weight tools strong on AD attack detection. Cloud-native: weight detection for your cloud IdP, SaaS, and machine identities, and do not pay for deep AD coverage you do not need. High-value target: if you are in finance, hold valuable data, or have been targeted before, the case for dedicated identity detection and fast response is strongest.

sourcing: four ways to get there

Use what your IdP includes. Modern identity providers include identity-risk detection and some automated response in their higher tiers. For many companies this is the right starting point, and the work is to turn it on and make sure its signals reach someone who acts.

Add ITDR through a platform you already run. If you have XDR or a broad security platform, ITDR may be a module or an add-on rather than a separate purchase, which keeps it integrated with the rest of your detection.

Buy a dedicated ITDR tool. Justified when you need deep, identity-specialized detection across surfaces your existing tools cover poorly, and you have the response capacity to use it.

Buy managed detection and response. For the very common case of not having a 24/7 team, an MDR service that covers identity gives you both the detection and the people to respond. Through an MSSP or a VAR, this is often the most honest answer for a mid-market company, because it solves the response problem rather than just the detection one.

the decision criteria that actually matter

• Detection breadth and accuracy · What to look for: Does it catch the identity attacks that matter, across the systems you run, without burying you in false positives?
• Response capability · What to look for: Can it actually act: disable, force re-auth, revoke sessions, contain, automatically and fast, or does it only alert?
• Surface coverage · What to look for: Active Directory, cloud IdP, SaaS, and machine identities, in the mix that matches where your identities live?
• Does it need a SOC · What to look for: Be honest about whether the tool is useful without a team to respond, and if not, whether you have or will buy that team.
• Integration · What to look for: Does it feed your IdP, SIEM, and existing workflow cleanly, or add another disconnected console?
• Posture management · What to look for: Does it also find the weak identity configuration that makes attacks easy, or is that a separate buy?
• False-positive behavior · What to look for: Can you tune it to a signal a real team will actually act on?
• Data residency and EU · What to look for: Where does the identity telemetry live and get analyzed?

The row that decides the project is response capability, including the human side of it. The most accurate detection in the world is worthless if nobody and nothing acts on what it finds, and that, far more than detection cleverness, is where ITDR projects succeed or fail.

how ITDR is priced, and the real cost

ITDR is usually priced per identity or per user, sometimes as a module on a platform you already pay for, and managed detection and response is typically a monthly service fee. The built-in detection in your IdP is often bundled into its upper tiers.

The license is rarely the real cost. Budget for the response, which is the part that makes detection useful: the people who respond, whether in-house analysts or a managed service, which is the dominant cost and the one buyers most often leave out; tuning, to keep the signal clean and avoid alert fatigue; integration, to connect it to your identity systems, SIEM, and response workflow; and the renewal and tier that holds the response automation you need.

how to run the evaluation

Build a shortlist that reflects your response reality, including the managed-service option if you have no team, and the use-what-your-IdP-includes option. Ask response-focused questions: which identity attacks they detect across AD and cloud and SaaS, what they can do automatically and how fast, whether you need your own SOC, how they keep false positives low, and where your identity data is analyzed.

Then run a proof of concept that tests detection and response together. Simulate real identity attacks in a controlled way: an impossible-travel login, an MFA fatigue pattern, a privilege escalation, a token replayed from a new device. Watch not just whether it detects, but what it does next and how quickly. Measure the false-positive rate over the trial. Set success criteria up front, and make automated or rapid response one of them. Then take references with the sharp question: when it detects something real, who responds and how fast, and is the tool still configured the way you deployed it.

the traps behind a clean dashboard

The signature ITDR failure is detection with no response: a beautiful stream of alerts flowing to a team that does not exist or cannot keep up, so the attacks get logged and not stopped. The dwell time the tool was supposed to shrink stays exactly as long as before, now with a paper trail.

Close behind is buying ITDR before the prevention basics are solid, so the tool spends its life narrating attacks that MFA and clean offboarding would have prevented. Then there is the coverage mismatch, watching AD while the attacker hits your cloud IdP. There is alert fatigue, the slow death of any detection tool that is not tuned. And there is the false comfort of a dashboard that is green because it is only watching the part of your identity estate that was never the problem.

where this meets the rules

Detection and response are increasingly explicit obligations. NIS2 requires in-scope entities to handle incidents, which presumes you can detect them, and identity is where many incidents begin. DORA requires financial entities to detect, manage, and report ICT-related incidents, with tight reporting timelines that are impossible to meet if you cannot see an identity attack happening. Insurers and auditors increasingly ask how you detect account compromise. None of these mandates a particular tool, but they all assume you can notice an identity attack and respond to it.

a sequenced path

Crawl: make sure prevention is solid first, then turn on the identity-risk detection your IdP already includes and route its alerts somewhere a human actually sees. Decide, concretely, who responds: a person, a managed service, or automated action.

Walk: add real identity detection through your XDR or a managed service, covering both your cloud IdP and any Active Directory. Write response playbooks so a detection leads to a known action. Bring in posture management to find and fix the weak identity configuration that makes attacks easy in the first place.

Run: extend detection across all your identity surfaces including machine identities, automate containment for the clear cases, integrate with your SOC and SIEM, and run it around the clock. At this point the identity layer is watched as closely as it is attacked.

ITDR is one of the higher-value security investments for a company that has already done the prevention basics, and one of the most wasted for a company that has not, or that buys detection with no way to respond. The deciding factor is whether the foundation is solid and whether someone or something acts on what is found, far more than the cleverness of the detection.