Back to Blog

The ITDR Buyer's Guide: What to Look For, What to Avoid

Identity Threat Detection and Response is the fastest-growing segment of identity security. That means more vendors, more noise, and more confusion. This guide cuts through the marketing to help you evaluate what actually matters.

A note on who wrote this: This guide is published by Auth Sentry. We sell ITDR. We tried to make this useful regardless of which vendor you choose, but we're obviously not neutral. We built Auth Sentry because current solutions aren't working. The SOC is drowning in noise, attackers are evolving, and siloed identity tools don't help organizations protect themselves from breaches. We think we can fix that - one platform, one view, complete visibility and protection. If that resonates, check us out. If not, use the evaluation framework to find what fits your organization.

What ITDR Actually Is (And Isn't)

Identity Threat Detection and Response (ITDR) detects and responds to identity-based attacks that happen after your perimeter defenses have been bypassed. Your IAM controls who gets access. Your SIEM logs what happens. ITDR catches when legitimate access is being abused.

Think of it this way: IAM is the bouncer checking IDs at the door. SIEM is the security cameras recording everything. ITDR is the detective who notices the employee with a valid badge is actually robbing the place.

ITDR emerged as a category because attackers adapted. Once MFA became widespread, they stopped trying to guess passwords and started stealing sessions, phishing for tokens, and exploiting the trust relationships between systems. Traditional security tools weren't built to catch these attacks.

ITDR is not a replacement for IAM, PAM, or SIEM. It's a layer that sits on top of your existing identity infrastructure and watches for attacks that your other tools miss - specifically, attacks where the attacker already has valid credentials.

Why ITDR Matters Now

The short answer: because identity-based attacks work. According to the 2024 Verizon DBIR, credential-based attacks remain the top initial access vector. Attackers have figured out that it's easier to log in than to break in.

The longer answer involves several converging trends:

  • MFA is no longer enough. Attackers have adapted with session hijacking, MFA fatigue attacks, and token theft. Passing MFA doesn't mean the user is legitimate.
  • Identity sprawl has exploded. Most organizations have 10x or more non-human identities than human ones - service accounts, API keys, machine identities - and most are barely monitored.
  • Cloud complexity creates blind spots. Identities span multiple providers, each with their own logs and limitations. Nobody has unified visibility.
  • Attackers are patient. Modern attacks unfold over days or weeks, using legitimate credentials to move laterally. Point-in-time detection misses them.

The Cost of Not Acting

Organizations without effective identity threat detection face compounding costs:

The math nobody wants to do:
  • Dwell time: Identity-based attacks average 200+ days before detection. Every day an attacker has access, they're mapping your environment and escalating privileges.
  • Investigation burden: Without automated investigation, analysts spend 15-45 minutes per alert. At 50+ identity alerts per week, that's a full-time job just triaging.
  • Breach amplification: Lateral movement goes undetected. What starts as one compromised credential becomes access to sensitive systems, data exfiltration, or ransomware deployment.
  • Compliance exposure: Regulators increasingly expect identity monitoring. Post-breach audits ask: "What did you have in place to detect credential misuse?"

The question isn't whether you can afford ITDR. It's whether you can afford the investigation time, the extended dwell time, and the breach impact that comes without it.

Attack Scenarios: Where ITDR Shines

ITDR is purpose-built for attacks that bypass perimeter security. Here are three scenarios where traditional tools fail and ITDR catches what others miss.

Scenario 1: Credential Compromise and Session Hijacking

An employee clicks a phishing link and unknowingly provides their credentials to an attacker. The attacker logs in, passes MFA (using a real-time phishing proxy), and establishes a session. From there, they access email, download files, and look for escalation opportunities.

Phishing → Credential theft → MFA bypass → Session established → Reconnaissance → Data access

Why SIEM misses it: Every action looks like legitimate user activity. The logs show successful authentication, normal application access.

What ITDR catches: Behavioral anomalies - login from unusual location, rapid access to sensitive resources the user rarely touches, session characteristics that don't match the user's typical device fingerprint. The attack is detected during reconnaissance, not after exfiltration.

Scenario 2: Lateral Movement via Service Account

An attacker compromises a developer workstation. They find credentials for a CI/CD service account stored in a config file. Using that service account, they access the deployment pipeline, then pivot to production systems.

Workstation compromise → Service account discovery → Pipeline access → Production pivot → Persistence

Why SIEM misses it: Service account activity often lacks behavioral baselines. The account "normally" accesses many systems, so lateral movement blends in.

What ITDR catches: Service account accessing systems outside its normal pattern, at unusual times, from an unexpected source IP. The account's relationship to other identities and resources reveals the anomaly that raw logs obscure.

Scenario 3: Third-Party App Token Abuse

A third-party SaaS integration (like a CRM sync tool) has OAuth access to your email and calendar. That third party gets breached. The attacker uses the existing OAuth tokens to access your organization's data without ever touching your authentication systems.

Third-party breach → OAuth token theft → Data access via API → No authentication events generated

Why SIEM misses it: No login events. The access uses existing authorized tokens. Your IdP never sees suspicious authentication because there isn't any.

What ITDR catches: Unusual data access patterns via OAuth - bulk downloads, access to resources the app doesn't typically touch, API calls at unusual times. The token's behavior diverges from its historical baseline.

This third scenario played out publicly when Drift (the chat widget company) was compromised, giving attackers access to customer environments through existing OAuth grants. Organizations without visibility into third-party app behavior had no way to detect the access.

How ITDR Is Evolving

ITDR is the fastest-growing segment of identity and access management - and the category is evolving rapidly. New vendors are entering the space and redefining what ITDR means. Here's where the category is heading:

1. From Alert Floods to Signal Clarity

First-generation ITDR tools inherited SIEM's worst habit: drowning SOC teams in alerts. The next generation focuses on reducing alert volume while increasing signal quality. This means:

  • Correlating multiple weak signals into single high-confidence detections
  • Learning environment-specific patterns to reduce false positives
  • Delivering fewer alerts that require action, not more alerts to ignore

The goal isn't "detect more things." It's "surface the threats that matter and filter the noise." SOC teams are burned out. Good ITDR should reduce their burden, not add to it.

2. From Alerts to Investigations

An alert tells you something might be wrong. An investigation tells you what happened, what's at risk, and what to do about it. The shift from "here's an alert, go figure it out" to "here's a complete investigation package" is the most important evolution in ITDR.

Modern investigation assistance includes:

  • Automated evidence gathering across connected identity providers
  • Timeline reconstruction showing the full attack chain
  • Context about the affected identity - role, typical behavior, related accounts
  • Recommended response actions with one-click execution
  • Clear explanation of why the detection fired and confidence level

This changes the analyst workflow from "spend 30 minutes gathering evidence" to "spend 2 minutes validating a pre-built case." The reduction in mean time to respond is where ITDR delivers measurable ROI.

3. From Reactive Detection to Predictive Action

The most advanced ITDR systems don't just detect attacks in progress - they identify conditions that make attacks likely before they happen:

  • Toxic permission combinations: An identity with access to both sensitive data and external sharing capabilities represents elevated risk.
  • Dormant identity risk: Service accounts that haven't been used in months but retain broad access are prime targets for attackers.
  • Attack path analysis: Mapping how a compromised identity could escalate privileges reveals which accounts need additional controls.

Predictive capabilities shift security from "detect and respond" to "identify and prevent." This is where the category is heading - though not all vendors are there yet.

The inflection point: ITDR is ready for production deployment. The category has matured past early-adopter stage. But we're also at an inflection point where new vendors are rapidly evolving what ITDR means - shifting from alert generation to investigation automation to predictive prevention. When evaluating, look for vendors building toward where the category is going, not just where it's been.

Core Capabilities to Evaluate

Not all ITDR solutions are built the same. Here's what to look for - and what differentiates a real solution from a rebranded SIEM rule pack.

1. Detection Approach

There are three main detection approaches. Most vendors use one or two:

Approach What It Does Limitations
Static Rules Matches known attack patterns (impossible travel, known bad IPs) High false positives, misses novel attacks
Behavioral Analytics Builds baseline of normal behavior, flags deviations Requires tuning period, can miss slow attacks
Identity Relationship Mapping Understands connections between identities, resources, and permissions More complex to implement, requires deep integration

The best solutions combine all three. Static rules catch known-bad patterns immediately. Behavioral analytics catch anomalies. Relationship mapping provides context that reduces false positives and reveals attack paths.

2. Investigation Capabilities

Detection is only half the problem. What happens after an alert fires matters just as much. Ask: does the tool give you an alert to investigate, or a complete investigation?

Good investigation capabilities include:

  • Automated evidence gathering across connected systems
  • Timeline reconstruction of identity activity
  • Correlation of related alerts into single incidents
  • Context about the identity (role, typical behavior, related accounts)
  • Clear explanation of why the alert fired

The difference matters operationally. An alert that says "unusual login" with no context takes 15-45 minutes to investigate. An investigation package with correlated evidence, timeline, and recommended actions takes 2-5 minutes to validate.

3. Response Options

What can the tool actually do when it detects a threat?

  • Alert only - Notifies your team, requires manual response
  • Guided response - Provides recommendations and one-click actions
  • Automated response - Takes action automatically based on policies

Automated response sounds appealing, but requires high confidence to avoid disrupting legitimate users. Most organizations start with guided response and automate specific scenarios over time as they build trust in the detection accuracy.

4. Integration Depth

ITDR is only as good as the identity data it can see. Evaluate integration depth, not just breadth. Surface-level API access is different from deep event streaming.

Questions to ask about each integration:

  • What data do you pull? (Auth logs, admin events, configuration changes?)
  • What's the latency? (Real-time streaming or batch polling?)
  • What actions can you take? (Read-only visibility or response capabilities?)
  • How is the integration maintained? (In-house or third-party connector?)

The Identity Coverage Question

This is where many ITDR evaluations go wrong. Most solutions focus heavily on human identities - employee accounts, SSO sessions, MFA events. But in most environments, non-human identities outnumber humans by 10:1 or more.

Identity Types to Cover:
  • Human identities - Employees, contractors, partners
  • Service accounts - Automated processes, scheduled jobs
  • Machine identities - Servers, containers, workloads
  • API keys and tokens - Application authentication
  • OAuth applications - Third-party integrations with persistent access
  • CI/CD credentials - Pipeline and deployment authentication

Non-human identities are often more dangerous than human ones. They typically have broader access, fewer controls, longer credential lifespans, and almost no behavioral monitoring. When evaluating ITDR, ask specifically how the solution handles each identity type.

Watch out for "we cover machine identities" claims. Ask for specifics. Some vendors count service account usernames in their inventory but don't actually monitor their behavior. Coverage means detection rules, not just awareness.

Questions to Ask Every Vendor

Cut through the marketing with these specific questions. Good vendors will have clear, specific answers. Evasive responses are a red flag.

Detection

  1. What's your false positive rate, and how do you measure it?
  2. How long does it take to baseline a new environment?
  3. What attacks can you detect that my SIEM can't?
  4. Show me a detection for [specific attack you care about]
  5. How do you handle detection tuning? Who does the work?

Identity Coverage

  1. What identity types do you monitor? (Get specifics, not categories)
  2. How do you discover identities I don't know about?
  3. How do you handle third-party app tokens?
  4. What's your approach to service account monitoring?

Investigation

  1. Walk me through what an analyst sees when an alert fires
  2. What evidence is automatically gathered?
  3. How long does a typical investigation take with your tool?
  4. Can I export investigation data to my SIEM/SOAR?

Operations

  1. What does deployment look like? Timeline and requirements?
  2. What ongoing maintenance does the tool require?
  3. How do you handle identity provider API changes?
  4. What's your uptime SLA?

Security & Compliance

  1. What data do you store, and where?
  2. What compliance certifications do you have?
  3. How do you handle tenant isolation?
  4. What happens to my data if I cancel?

Red Flags to Watch For

After evaluating dozens of security tools, these patterns consistently predict problems down the road.

Red Flag What It Usually Means
"AI-powered" without specifics Marketing buzzword. Ask exactly what the AI does and what decisions it makes.
Won't share false positive rates Either they don't measure it (bad) or the number is embarrassing (worse).
"Works out of the box" Probably means static rules only. Good behavioral detection needs baseline time.
Vague integration claims "We integrate with Okta" could mean full API access or just SAML SSO.
No reference customers Early-stage is fine, but they should have at least a few you can talk to.
Requires agents everywhere Deployment complexity, maintenance burden, potential performance impact.
Long professional services engagement Complex deployment suggests complex ongoing maintenance.
Can't explain why an alert fired Black-box detection is impossible to tune and hard to trust.

Running Your Evaluation

The best way to evaluate ITDR is to run it against your actual environment. Here's a practical evaluation process.

Before You Start

  1. Define your use cases. What attacks are you most worried about? What gaps exist in your current detection?
  2. Inventory your identity providers. Know what you need to connect before you start evaluating. Some vendors offer free inventory tools to help with this step.
  3. Identify success criteria. What would make this a successful deployment? Be specific.
  4. Get stakeholder buy-in. You'll need identity team cooperation to connect providers.

During the Evaluation

  1. Connect your actual identity providers - not a sandbox. You need to see real data to evaluate detection quality.
  2. Let it baseline. Behavioral detection needs time. Don't judge alert quality in the first week.
  3. Run attack simulations. Test specific scenarios that matter to you. Can it detect the attacks you're worried about?
  4. Measure investigation time. Have analysts work real alerts. Time how long it takes from alert to resolution.
  5. Count false positives. Track how many alerts were noise. This is the number that determines operational viability.

Questions for Your Team

  • Would analysts actually use this daily?
  • Does it surface threats we weren't seeing before?
  • Is it faster than our current investigation process?
  • What's the maintenance burden?

Final Checklist

Before Signing:
  • Completed proof-of-concept with your actual identity data
  • Measured false positive rate in your environment
  • Validated detection for your priority attack scenarios
  • Timed investigation workflow with your analysts
  • Confirmed coverage for all identity types you care about
  • Verified integration depth (not just existence) for your providers
  • Talked to at least one reference customer
  • Understood the pricing model and what triggers cost increases
  • Reviewed data handling, retention, and deletion policies
  • Confirmed compliance certifications meet your requirements
  • Understood the support model and escalation path
  • Documented the deployment timeline and resource requirements

The best ITDR deployments share a common trait: they started with visibility. Before buying detection and response capabilities, the security team got a complete inventory of their identity landscape. They learned what identities existed, what access they had, and where the gaps were. That foundation made everything else easier.

Start with visibility

Auth Sentry Monitor gives you a complete inventory of every identity in your environment - human, non-human, and third-party apps - for free. Get the visibility foundation that makes better investigations possible.

See Your Identity Inventory

About Auth Sentry

Auth Sentry, by Hummingbird Security, is an identity threat detection and response platform built by security practitioners from Duo, Censys, and the MDR world. We built the tool we couldn't find - one that delivers investigations, not just alerts. Learn more at gethumming.io.

Ready to Transform Your Identity Security?

Reduce alert fatigue. Get complete investigations. Stop attacks before they progress.

See how Auth Sentry delivers real outcomes for your SOC.

Request Free Trial