How to Choose an MDR Provider Without Getting Burned

The MDR market has over 600 providers, according to Gartner's 2025 Guide. The fragmentation is getting worse as legacy managed security providers rebrand into the MDR space. And now three fundamentally different approaches compete for your budget: legacy human-led MDR, AI SOC tools you operate yourself, and AI-native MDR services. 

The wrong choice does not just waste money. It creates blind spots that your team does not know about until something breaks.

This is a practical framework for evaluating MDR providers beyond logos, feature grids, and analyst quadrant placements.

TL;DR: 

• Three categories of MDR now compete for your budget, and they are not interchangeable. 
• Legacy MDR, AI SOC, and AI MDR have different liability models, architectural foundations, and operational realities. Conflating them is the fastest way to buy the wrong thing.
• Identity is a major coverage gap in many MDR engagements. Credential compromise, MFA bypass, and OAuth abuse require cross-domain investigation that correlates identity, cloud, and endpoint signals together.
• Transparency is the difference between a partner and a liability. If you cannot see the data sources consulted, the reasoning behind each verdict, and the confidence level of every conclusion, you are trusting a black box with your security posture. Demand full auditability before you sign.

What MDR Providers Actually Do

Before evaluating any provider, understand which category they fall into. These three models are not interchangeable, and the MDR label alone does not tell you which one you are buying.

• Legacy MDR: Human-led, shift-based investigation built for the perimeter era. Often struggles with cloud, identity, and cross-system correlation at the speed modern attacks demand.
• AI SOC: Software platforms that automate triage. These are tools you operate, not managed services. Your team maintains detection logic, and the vendor takes zero contractual liability for outcomes.
• AI MDR: Full managed investigation and response built on an AI-native architecture. The provider operates the service. Capabilities vary significantly by provider in terms of investigation depth, response authority, and how security experts are structured into the service. May include contractual liability depending on the provider and contract.

‍

These are not feature tiers of the same product. They are different operating models with different accountability structures. Knowing which category you need narrows the field from 600 providers to the ones worth evaluating.

Step 1: Clarify Your Environment and Outcomes

Start internally, not with vendor conversations. Map your environment across endpoints, cloud, SaaS applications, and identity systems, with a focus on what needs to be covered and investigated end-to-end. Include service accounts and non-human identities, as these are often unmonitored and frequently involved in real-world incidents.

Instead of focusing only on inventory or alert volume, identify where your current approach breaks down, which alerts get escalated back to your team, where investigations stall or lack sufficient context and which parts of your environment are not fully covered?

If your current provider escalates alerts that turn out not to be real incidents, that is a signal that they lack the context or capability to resolve them. Those are the gaps you need to evaluate.

Then define outcomes, not just metrics. For example:

• Reduce escalations to the internal team
• Ensure full investigation coverage across identity, cloud, and SaaS
• Eliminate unresolved alerts rather than just reducing alert volume

Build this into your evaluation criteria and measure every provider against it.

Step 2: Evaluate Coverage, Integration Depth, and Identity

Coverage breadth and integration depth are where the gap between marketing claims and operational reality is widest.

Check Coverage Across Your Actual Attack Surface

Confirm how the MDR uses the data from across your environment to investigate and resolve alerts. The question is not “which tools does the MDR support,” but whether the provider can correlate data across identity, cloud, SaaS, and endpoints to reach a verdict without escalating to your team.

Evaluate Identity as a First-Class Investigation Domain

Valid account abuse is behind many cloud incidents today. Credential compromise, MFA bypass, and OAuth abuse often involve no malware at all, just valid credentials moving laterally from identity to SaaS to endpoint. A provider investigating these domains in silos will often miss the chain.

The question to ask: when you confirm an account compromise, do you audit and revoke OAuth tokens, or just reset the password? A password reset alone typically leaves persistent access channels intact. Look for providers whose identity threat detection and response correlate identity, cloud, and endpoint signals in a single investigation timeline.

Assess Integration Directionality

A read-only integration ingests alerts. On the other hand, a bi-directional integration ingests alerts and writes status changes, closures, and response actions back to your tools. Read-only integrations leave resolved alerts open in your SIEM and ticketing dashboards after the MDR platform has already closed them, defeating the operational efficiency case entirely. 

For each "supported" integration, ask how many alert types the provider actually initiates an investigation for. A provider that covers only a small subset of alert types from a tool gives you a logo on an integrations page, not investigation coverage.

Step 3: Assess People and Process

The quality of the people investigating your alerts is critical in MDR outcomes, and it can be hard to evaluate before signing. Detailed information on security expert coverage is rarely published. 

Ask whether the provider has processes to preserve institutional knowledge when staffing changes happen. Also, ask whether overnight coverage uses the same level of experience as daytime or a different, often offshore, team.

Request sample investigation reports from real incidents. Definitive conclusions with specific remediation guidance signal deeper investigative work. Alert documentation with an escalation recommendation can indicate playbook execution dressed as an investigation.

Evaluate whether you can speak directly with the security expert investigating your alert or are routed through a service desk.

Step 4: Look for Transparency and Measurable Outcomes

If you cannot see how your provider reached a verdict, you do not have a partner. You have a black box.

Demand access to the data sources consulted, the queries run, the intermediate conclusions, and how they were combined into the final verdict. Not a summary. Not a PDF. The actual reasoning chain. If getting that requires a formal request, the provider is not built for transparency.

Break your SLA commitments into separate stages: investigation, containment, and remediation. A single aggregate response time masks where the provider is actually slow. And include false positive accountability. 

A provider hitting response-time targets while flooding your team with noise has met the letter of the contract while failing its purpose.

Step 5: Ask About Adjacent Services

Most MDR contracts are narrower than buyers expect. Three services frequently sit outside the base engagement. Clarify the scope and pricing for each before you sign.

• Threat hunting: A separate discipline from MDR, not driven by alert telemetry. Most MDRs do offer IOC sweeps when there’s a known active threat, and you should ensure your MDR can cover it. However, hypothesis based threat hunting is out of scope in most cases, but you should ensure the provider can offer this service 
• Phishing investigation & response: Investigating phishing alerts is not very complicated, but volume tends to be very high and therefore requires resources. Due to the high volume of alerts, most vendors price it separately, so make sure to properly define the scope ahead of time. In addition, most providers do offer phishing investigation, but they cover automated email security alerts only. User-reported phishing submissions often flow into a separate queue. Ask whether the contract covers both. User-reported emails carry practical context but often lack the technical indicators that automated tools rely on.
• DLP investigation & response: Not many MDR providers offer this, due to the complicated nature of investigating DLP (Data Loss Prevention) alerts, but most vendors ensure to remove it from the scope. Make sure you understand the scope offered to you and the level of integration with your data protection security tools. 
• Incident response: The IR retainer is frequently separate from the base MDR contract. The MDR-to-IR handoff is the most fragile moment in breach response. Address legal engagement structure and privilege questions before a breach, not after.

If any of these are missing from the base contract, get the pricing and scope in writing during evaluation. Discovering the gaps after signing gives you no leverage.

Questions to Ask in MDR RFPs and Demos

These ten questions are designed to surface the gaps that demos and feature grids hide. Each one maps to a specific evaluation step above. Use them in RFPs, vendor calls, and POC scoping.

1. When investigating an account compromise, what specific identity telemetry sources do you ingest and correlate? Good answer: specifies raw IdP/SSO logs (Entra, Okta), on-prem AD activity (Kerberos, NTLM), and SaaS audit trails correlated with EDR process telemetry. Bad answer: "We integrate with your SIEM"  or "We monitor all your logs".
2. If you confirm an account compromise in progress, what identity-specific response actions can you take without waiting for my approval? Good answer: confirms native integration with Identity APIs (Graph, Okta) to perform session revocation, token invalidation, and account suspension in seconds. Bad answer: "We can isolate the host" or "We will alert your team to disable the user."
3. For each supported integration, is it read-only or bi-directional? Provide the specific response actions available. Good answer: provides a bi-directional matrix showing specific write-actions (e.g., password resets, clearing WebAuthn sessions) vs. read-only ingestion for each vendor. Bad answer: Claims "full integration" without distinguishing between log collection and active response capabilities.
4. Can I see the detection logic, data sources, security expert reasoning, and disposition decision behind any alert you send me, in real time? Good answer: offers a portal showing the full details of each investigation query, raw telemetry sources, and the analyst’s step-by-step reasoning for every disposition. Bad answer: "We provide a summary report" or "Our logic is proprietary and cannot be shared."
5. Which alert categories do you resolve directly, which do you escalate for expert review, and how do you validate those decisions? Good answer: defines a clear escalation matrix that separates automated tuning from human-vetted alerts. Bad answer: "Our AI resolves everything" or "We investigate every alert manually" (which is mathematically impossible at scale).
6. Describe your threat hunting methodology. If it is a separate service, how is it scoped, and when is it invoked? Provide a documented hypothesis based hunting from the past 90 days, including the falsification condition. If they cannot produce one, ask what they mean by "threat hunting."
7. Walk me through hour four of a confirmed ransomware incident. At what point does the engagement become a separate billable event? Explicitly defines the handoff point between MDR containment and Digital Forensics/Incident Response (DFIR), including precise billing triggers for out-of-scope remediation.
8. Which category does your service fall into: legacy MDR, AI SOC, or AI MDR? Who owns detection engineering, and does your contract include breach liability? Evasive answers here signal the provider has not clarified its own operating model. The answer should be short and clear.
9. What is the minimum experience level of the security experts investigating my alerts at 2 AM? Is overnight coverage staffed at the same level as daytime? Good answer: confirms a consistent Tier 2/3 skill floor across all shifts (24/7/365) and details how global handoffs maintain investigation quality during overnight hours. Bad answer: "We have 24/7 coverage" (often masking a transition to junior offshore staff or "pager-only" support after hours).
10. Does your base contract ingest and investigate phishing investigations, including user-reported phishing submissions? Confirms the base contract includes the analysis of phishing alerts and if the vendor is also able to support user-reported alerts. If user-reported phishing is a separate add-on, price it and scope it before signing.

Validate claims with POCs using your data. Metrics from other environments do not transfer. When you talk to customer references, ask: "What would you tell me if you were trying to convince me NOT to choose this provider?"

The Evaluation Points to AI MDR, but Daylight Takes It Further

Every step in this framework surfaces the same structural requirement: full telemetry, organizational, and historic context, cross-system correlation across identity, cloud, and endpoint in a single timeline, and bi-directional response actions that close alerts in origin tools. 

Legacy MDR cannot maintain the speed or correlation depth that modern identity-driven attacks demand. AI SOC tools automate pieces of it but leave accountability and response with your team, meaning you still need skilled operators around the clock.

AI MDR closes part of that gap, but capabilities vary significantly across providers. Investigation depth, response authority, and transparency are not uniform across the category. The evaluation work still matters even after you've narrowed to AI MDR.

Daylight Security is a Managed Agentic Security Services (MASS) provider, and its architecture addresses each dimension this framework surfaces. AI agents investigate every alert with full context assembled in real time across three types: telemetry, organizational, and historic. 

In this model, security experts are not just reviewing AI outputs. Their roles cut across context building, assembling and continuously deepening the organizational and historic knowledge that makes automated investigations reliable, low-confidence verdict review, and IR leadership.  Rather than treating MDR as the ceiling, the same architecture extends across identity response, cloud workload protection, and managed phishing, including user-reported submissions. MDR is the entry point, not the boundary.

For deeper reading on MDR evaluation, identity investigation, and how AI-native architectures change security operations, visit the Daylight blog.

Frequently Asked Questions About MDR Providers

What Should I Look For in MDR Provider Transparency?

You should be able to see the data sources consulted, queries executed, and reasoning chain behind any investigation in real time. If accessing investigation details requires a formal request, a summary PDF, or a scheduled review call, that is a black box regardless of what the marketing says. Transparency means your security team can audit any verdict on demand.

How Do I Tell if an MDR Provider's Integrations Are Actually Bi-directional?

Ask for the specific response actions available per integration. A provider with bi-directional integrations can read alerts from your tools AND write back to close them at source, such as revoking sessions through Entra ID Graph API or invalidating tokens through Okta Management API. 

If the answer is "we integrate with your SIEM" without specifying write-back actions, the integration is likely read-only.

How Do I Evaluate the People Behind an MDR Service?

Focus on what the security experts actually do, not headcount or certifications. Key questions: Are they building and maintaining context, or validating tickets? Do they review low-confidence verdicts? Do they lead incident response for confirmed threats? A provider whose experts primarily triage alerts is a staffing agency, not a managed service.