How to evaluate ITDR vendors

ITDR vendor evaluation is the process of assessing identity threat detection and response providers against technical, operational, and business criteria before purchase. ITDR platforms vary significantly in the identity sources they monitor, the detection methods they use, and the response capabilities they offer. Evaluating them against a structured framework prevents capability gaps that marketing claims often obscure.

Key takeaways

• ITDR vendors differ significantly in which identity sources they monitor—cloud IAM, SaaS, and on-premises coverage aren’t uniform across the market
• Detection approach matters as much as detection coverage: ask specifically whether the vendor uses behavioral analytics or rule-based correlation, and ask for evidence
• SIEM and SOAR integration capabilities determine whether ITDR reduces or adds to analyst workload
• Human expertise and 24×7 availability are differentiators—automated-only ITDR platforms leave confirmed threats without analyst review
• Response capability—automated containment plus human-led investigation—is the difference between detection and resolution

The ITDR market has expanded rapidly, and vendor marketing has kept pace—making it genuinely difficult to compare solutions on capabilities that matter versus capabilities that sound good in a demo. Identity threat detection and response (ITDR) platforms differ significantly in which identity sources they monitor, how they detect threats (behavioral analytics versus rule-based correlation), and whether a human analyst is in the loop when a confirmed threat is identified. This framework provides eight concrete evaluation criteria designed to surface those differences—and a set of specific questions to ask vendors that marketing materials rarely answer clearly.

 

What to look for in an ITDR solution: the eight criteria

The eight criteria below form a structured evaluation framework applicable to any ITDR platform or MDR provider with identity detection capability. 

 

Criterion 1: Identity telemetry coverage

What to assess: Which identity sources does the vendor actually ingest and analyze? Coverage varies enormously across the ITDR market.

A capable ITDR platform should monitor, at minimum:

• Cloud IAM: AWS CloudTrail (IAM and authentication events), Azure Entra ID sign-in and audit logs, Google Cloud Audit Logs
• Identity providers: Okta, Ping Identity, Microsoft Entra ID, Google Workspace
• SaaS platforms: Microsoft 365 (Exchange, SharePoint, Teams activity logs), Google Workspace, Salesforce, and other high-risk SaaS applications in your environment
• On-premises directories: Active Directory authentication and change events, particularly for hybrid environments
• Privileged access management (PAM): CyberArk, BeyondTrust, and similar platforms for privileged account activity

Questions to ask:

• Which specific identity sources are natively integrated (agent-free) versus requiring custom log forwarding?
• What’s the coverage gap for SaaS applications not on your standard integration list?
• How is coverage maintained as new cloud services are added to the environment?

Criterion 2: Detection approach

What to assess: Does the vendor use behavioral analytics, rule-based correlation, or a combination? The answer has major implications for detection fidelity and alert quality.

Rule-based detection fires alerts when known patterns are matched—a specific failure count, a known bad IP, a defined threshold crossed. It’s predictable and auditable, but it can’t detect novel attacks or behavioral anomalies that don’t match a predefined signature.

Behavioral analytics establishes a baseline for each identity—what it normally does, when, from where, at what volume—and flags deviations. It can detect MFA bypass where the auth log shows success, gradual privilege escalation that stays under rule thresholds, and first-time access to sensitive resources. It requires more data and more computation, but produces significantly higher-fidelity identity threat detection.

Questions to ask:

• What is the baseline period for behavioral models? How are baselines maintained when behavior legitimately changes?
• Can you provide specific examples of threats your platform detected that rule-based SIEM correlation missed?
• What is your false positive rate on identity alerts? How is that measured?

For context on why detection approach matters for specific attack types, see how to detect MFA bypass attacks.

Criterion 3: SIEM and SOAR integration 

What to assess: How does the ITDR platform integrate with your existing SIEM and SOAR, and does that integration reduce or add to analyst workload?

ITDR should reduce SIEM alert volume by delivering pre-investigated, enriched identity alerts—not add another alert source for analysts to monitor. Evaluate:

• Alert format—does the ITDR platform send raw events or pre-investigated alerts with behavioral context attached?
• Bidirectional communication—can SOAR playbooks trigger containment actions in the ITDR platform (account suspension, session revocation)?
• SOAR playbook support—are pre-built playbooks available for common identity threat scenarios, or does integration require custom development?

Questions to ask:

• What does an ITDR alert look like when it arrives in our SIEM? Does it include the behavioral context that triggered it?
• How many additional alerts per day should we expect ITDR to add to our SIEM queue?
• Which SOAR platforms does your response integration support natively?

For more on the ITDR-SIEM relationship, see ITDR vs. SIEM.

Criterion 4: IAM integration

What to assess: How deeply does the ITDR platform integrate with your core IAM and identity provider systems, and what actions can it take within those systems for response?

Native integration with your identity providers—Okta, Azure Entra ID, AWS IAM, Google Workspace—is required for meaningful detection and response. Assess:

• Authentication event ingestion—are auth events pulled natively via API, or forwarded through log agents?
• Identity context enrichment—can the platform pull account attributes, group membership, and privilege level from the IAM system to enrich detections?
• Response actions within IAM—can the platform suspend accounts, revoke sessions, or reset MFA directly in Okta, Entra ID, or AWS IAM as a response action?

Questions to ask:

• Which IAM platforms do you integrate with natively, versus via syslog forwarding?
• What response actions can your platform take directly in our identity provider?
• How does your platform handle federated identity scenarios where the originating IdP is separate from the resource-side IAM?

Criterion 5: Response capabilities

What to assess: What happens when a confirmed identity threat is detected? The range across the ITDR market runs from alert-only to automated containment with human-led investigation.

The minimum viable response capability for enterprise environments:

• Automated containment—account suspension, session revocation, and privilege rollback should be available as automated response actions for high-confidence detections
• Human analyst review—confirmed identity threats should be reviewed by a human analyst before major containment actions are taken, particularly for accounts where false positive risk is high (executive accounts, service accounts with production dependencies)
• MTTR commitment—what is the vendor’s mean time to respond SLA for confirmed identity threats?
• Escalation process—how does the vendor communicate with the customer SOC when a confirmed threat requires customer action?

Questions to ask:

• What is your average MTTR for confirmed identity threats? How is that measured?
• What automated containment actions are available, and what is the confidence threshold for triggering them automatically versus requiring analyst approval?
• Do you provide 24×7 analyst coverage, or only business-hours support?

Criterion 6: Compliance support

What to assess: Does the ITDR platform provide the audit trails, reporting, and control documentation required for your regulatory compliance obligations?

Identity-related compliance requirements are extensive across major frameworks:

• SOX Section 404: Privileged access monitoring, access change audit trails, separation of duties controls
• PCI-DSS Requirement 8: Unique user identification, multi-factor authentication for all access to cardholder data environments, audit log retention
• HIPAA: Access monitoring for systems containing ePHI, audit controls, and workforce identity management
• FFIEC: Authentication controls, privileged access management, and anomalous activity monitoring for financial institutions

Questions to ask:

• Which compliance frameworks does your platform have pre-built reporting for?
• How long is identity audit log data retained, and in what format?
• Can your platform produce audit-ready evidence of privileged access activity for SOX or PCI-DSS requirements?

Criterion 7: Human expertise 

What to assess: What level of identity security expertise is behind the platform, and is it available 24×7?

Automated ITDR platforms detect; humans investigate and respond. The quality of identity threat investigation depends on analyst expertise in identity attack techniques, cloud IAM systems, and the customer’s specific environment. Evaluate:

• SOC analyst identity specialization—are analysts specifically trained in identity attack patterns, cloud IAM, and ITDR response techniques?
• 24×7 availability—identity attacks don’t respect business hours; push bombing campaigns and AiTM phishing frequently occur at off-hours specifically to exploit reduced SOC coverage
• Customer environment context—does the vendor invest time in understanding the customer’s identity architecture, business context, and risk profile, or is the service purely platform-driven?

Questions to ask:

• How are your SOC analysts trained specifically on identity threats?
• What is your after-hours escalation process for confirmed high-severity identity threats?
• How many identity-specific incidents did your team investigate in the past 12 months?

Criterion 8: Deployment model

What to assess: What are the deployment requirements, and do they align with your data residency, architecture, and procurement constraints?

Deployment model	Characteristics	Considerations
Cloud-native SaaS	No on-premises infrastructure; API-based identity telemetry ingestion	Data leaves on-premises environment; may have data residency implications
On-premises	Identity telemetry stays within the customer environment	Infrastructure burden; may have coverage limitations for cloud IAM
Hybrid	On-premises sensor for an on-prem telemetry; cloud processing for analytics	Balances data residency with cloud IAM coverage
MDR with integrated ITDR	Managed service combines identity detection with broader MDR capability	Reduces vendor sprawl; may require evaluating MDR platform holistically

Questions to ask:

• Where is identity telemetry processed and stored? What data residency options are available?
• What is the onboarding timeline and what identity sources are available at day one versus later in deployment?
• Are there infrastructure requirements for on-premises Active Directory or PAM integration?

 

Expel’s take

Most ITDR evaluations spend disproportionate time on the demo—watching detection scenarios in a controlled environment—and not enough time on the question that separates security outcomes from security theater: what happens after a confirmed threat is identified? Human analyst review and 24×7 availability are the criteria buyers most commonly underweight, and the ones that most directly determine whether a detected identity attack gets contained or just gets logged. Expel’s mean time to respond for high and critical incidents with automated remediation is 13 minutes—and the question worth asking every vendor in this evaluation is what number they’re willing to put in writing.

 

Frequently asked questions

What should I look for in an ITDR solution? 

Evaluate ITDR vendors across eight criteria: identity telemetry coverage (which cloud IAM, SaaS, and on-premises sources are monitored), detection approach (behavioral analytics versus rule-based), SIEM and SOAR integration quality, IAM platform integration depth, response capabilities and MTTR SLA, compliance reporting support, human analyst expertise and 24×7 availability, and deployment model and data residency options.

How do I compare ITDR vendors? 

Start with coverage: which identity sources does each vendor actually ingest? Then challenge detection claims: ask for specific examples of behavioral-analytics-based detections that rule-based tools missed. Assess integration quality by asking what an alert looks like when it arrives in your SIEM. Evaluate response by asking for MTTR data and the escalation process for confirmed high-severity threats.

What features should I look for in an ITDR tool? 

At minimum: cloud IAM coverage (AWS, Azure, Google Cloud), SaaS and IdP integration (Okta, Entra ID), behavioral analytics (not rule-based-only detection), SIEM alert enrichment (pre-investigated alerts, not raw events), 24×7 human analyst availability, automated containment capabilities (account suspension, session revocation), and compliance reporting for your relevant regulatory frameworks.

Do I need ITDR if I already have a SIEM and EDR? 

Yes, for most organizations with cloud workloads. SIEM has structural limits on per-identity behavioral detection; EDR has no visibility into cloud-only attacks. ITDR fills the identity-layer detection gap that both tools leave open. The right question isn’t whether to add ITDR, but which ITDR capability—standalone platform or integrated MDR with identity detection—fits your environment.

Q5: What is the difference between ITDR platforms and MDR with identity detection? 

Standalone ITDR platforms focus specifically on identity telemetry and threat detection. MDR providers with integrated ITDR combine identity detection with broader endpoint, network, and cloud detection—reducing vendor sprawl and providing full-kill-chain visibility across attack surfaces. The trade-off: MDR with integrated ITDR requires evaluating the MDR platform holistically, not just the identity detection component.