MDR Providers: How to Choose Without Getting Burned

Well above 600 vendors now sell some form of MDR, and the fragmentation is getting worse as managed security providers rebrand into the space. The label now stretches across service models that have little in common beyond the acronym, and all of them are competing for the same budget line.

The wrong choice does not just waste money. It leaves gaps in coverage that your team will not find out about until something breaks, and the usual shortcuts of logos, feature grids and analyst recognition lists will not tell you which providers leave them.

TL;DR:

• The MDR label spans managed human-led services, customer-operated tooling, and managed services built on AI. Each carries different liability, and conflating them is the fastest way to buy the wrong thing.
• Who actually carries the work after you sign matters more than any feature grid you compare beforehand.
• Identity is where many MDR engagements leave gaps. Attacks that run on valid credentials cross several systems at once, and a provider investigating each domain separately will miss the chain.
• A provider that will not show you its reasoning is asking you to take its verdicts on trust. Settle auditability while you still have a choice of provider.

What MDR Providers Actually Do

The MDR label covers three approaches that differ by operating model and accountability, and the label alone does not tell you which one you are buying.

• Traditional MDR: human-led, shift-based investigation built for the perimeter era. These providers investigate alerts and take agreed response actions. Where they part company with newer models is escalation volume, and cases that cross more than one system at once.
• AI SOC: customer-operated software that automates triage and investigation. Your team maintains the detection logic and keeps ownership of response, and the vendor takes no contractual liability for outcomes.
• AI-native MDR: full managed investigation and response built on an AI-native architecture, with the provider operating the service. Capabilities vary considerably from one provider to the next in investigation depth, response authority, and how the provider structures human reviewers into the service. Contractual liability depends on the provider and the contract.

The differences are easiest to read side by side.

‍

These are not three grades of the same product. They are different operating models with different accountability structures, and knowing which one you need narrows the field before you speak to anyone.

Who Owns the Investigation When an Alert Fires

The key evaluation is not feature coverage, but where the investigation burden sits: with your team, shared, or fully owned by the provider. Feature grids cannot answer that question, because identical tool support can still leave your team carrying most of the work.

Providers rarely name their position directly, so you have to infer it. Some forward enriched alerts and expect your team to reach the verdict. Some investigate within a single domain and hand off anything that crosses into another. Some investigate end to end and close the alert in the tool it came from.

These questions separate them:

• Can the provider use data across endpoints, cloud, identity, and SaaS to investigate alerts end-to-end and reach a clear verdict without escalating to your team?
• How are alerts actually resolved, and what share are fully investigated and closed without customer involvement?

An honest answer to the second question is a proportion with a definition attached. An evasive answer is a response-time figure.

Step 1: Clarify Your Environment and Outcomes

The useful work here happens before you talk to vendors at all. 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, which often go unmonitored and turn up in real incidents.

Look past inventory and 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 it lacks the context or the capability to resolve them. Those are the gaps to evaluate against.

Then define the outcomes you want, in writing:

• 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 these into your evaluation criteria and measure every provider against them. Escalation patterns and coverage gaps will tell you more about fit than any alert-volume or endpoint-count comparison.

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.

Coverage Across Your Actual Attack Surface

A supported-tools list tells you what a provider can read. It says nothing about what the provider does with what it reads. Ask for a worked example: a real investigation in an environment that looks like yours, showing which systems it queried, in what order, and what closed the case. A provider that can only describe the process in the abstract has not run it often.

Identity as a First-Class Investigation Domain

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: once you know an account is compromised, 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 correlates identity, cloud, and endpoint signals in a single investigation timeline.

Integration Directionality

A read-only integration ingests alerts. 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, which defeats the operational efficiency case entirely.

Go tool by tool and ask how many alert types the provider actually initiates an investigation for. A provider that covers only a small subset of a tool's alert types gives you a logo on an integrations page, not investigation coverage.

Step 3: Assess People and Process

The people investigating your alerts shape the outcome more than any platform feature, and they are the hardest part of the service to assess before signing. Providers rarely publish detailed staffing information, so you have to ask.

Start with what those people spend their time on. Validating machine output and writing up tickets means the work has moved desks and not disappeared. Building context, tuning detections and leading live incidents means it has actually left your team.

Institutional knowledge is the next question. Providers lose people, and contracts rarely say what happens to the accumulated understanding of your environment when they do. Ask what the retention process looks like, and how long onboarding runs before the service operates at full depth. A provider promising full effectiveness in week one has not built much context.

Overnight coverage deserves its own question. Find out whether the small hours are staffed at the same level of experience as the working day, or handed to a different, often offshore, team.

Request sample investigation reports from real incidents. Definitive conclusions with specific remediation guidance signal deeper investigative work. Alert documentation that ends in an escalation recommendation usually means a playbook ran and an investigation did not.

Finally, can you speak directly with the analyst investigating your alert, or does everything route 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.

Ask for access to the data sources consulted, the queries run, the intermediate conclusions, and how they 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 SLA commitments into separate stages: investigation, containment, and remediation. A single aggregate response time masks where the provider is actually slow.

Then add false positive accountability, which most contracts leave out. A provider hitting response-time targets while flooding your team with noise has met the letter of the contract while failing its purpose. Ask what happens after your team flags a false positive: whether a documented tuning path exists, who owns it, and how you would know the same alert will not resurface next month.

Step 5: Ask About Adjacent Services

Most MDR contracts are narrower than buyers expect. Clarify the scope and pricing of each of these before you sign.

• Threat hunting: a separate discipline from MDR. It starts with a hypothesis about your environment, and the alert queue plays no part in it. Most MDRs do offer IOC sweeps when a known active threat is circulating, and you should confirm that yours can cover them. Hypothesis-based hunting sits outside the base contract in most cases, so ask whether the provider offers it at all.
• Phishing investigation and response: the work itself is not complicated, but volume tends to run high, so it consumes resources. Most vendors price it separately for that reason, which makes scope worth defining ahead of time. Coverage usually stops at automated email security alerts, with user-reported submissions flowing into a separate queue. Ask whether the contract covers both. User-reported emails carry practical context and often lack the technical indicators automated tools rely on.
• DLP investigation and response: few MDR providers offer this, because data loss prevention alerts are complicated to investigate, and most vendors keep it out of scope. Make sure you understand what the provider actually offers and how deeply it integrates with your data protection 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. Settle legal engagement structure and privilege questions before a breach.

If any of these are missing from the base contract, get pricing and scope in writing during the evaluation. Discovering the gaps after signing leaves you nothing to negotiate with.

Questions to Ask in MDR RFPs and Demos

Demos and feature grids tend to hide the same problems. These questions expose them, and each one maps to an evaluation step above.

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 such as Graph and 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, such as password resets and clearing WebAuthn sessions, against read-only ingestion for each vendor. Bad answer: claims "full integration" without distinguishing log collection from active response.
4. Can I see the detection logic, data sources, analyst reasoning, and disposition decision behind any alert you send me, in real time? Good answer: offers a dashboard 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? Good answer: produces a documented hypothesis-based hunt 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? Good answer: explicitly defines the handoff point between MDR containment and digital forensics and incident response, including precise billing triggers for out-of-scope remediation.
8. Which model does your service fall into: traditional MDR, AI SOC, or AI-native MDR? Who owns detection engineering, and does your contract include breach liability? Good answer: short and clear. Evasive answers here signal the provider has not clarified its own operating model.
9. What is the minimum experience level of the analysts 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 overnight. Bad answer: "We have 24/7 coverage," which often masks a transition to junior offshore staff or pager-only support after hours.
10. Does your base contract cover the investigation of phishing alerts, including user-reported submissions? Good answer: confirms the base contract includes analysis of phishing alerts and says whether the vendor also supports user-reported ones. If user-reported phishing is a separate add-on, price it and scope it before signing.

Validate the claims that matter in a proof of concept run on your own data. Metrics from other environments do not transfer. And when you talk to customer references, ask one more question: what would you tell me if you were trying to convince me not to choose this provider?

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

Each step in this framework lands on the same structural requirement: context deep enough to reach a verdict, correlation that keeps evidence from separate domains in one timeline, and bi-directional response actions that close alerts in the tools they came from.

Traditional MDR struggles to hold that correlation depth at the speed identity-driven attacks move. AI SOC tools automate pieces of the work and leave accountability and response with your team, so you still need skilled operators around the clock.

AI-native MDR closes part of the gap, but the category holds providers at markedly different levels of maturity, so the evaluation work still matters even after you have narrowed the field to it.

Daylight Security is a managed agentic security services (MASS) provider, meaning it delivers security operations as a managed service run by AI agents working alongside security experts. Its AI agents investigate alerts with context assembled in real time across telemetry, organizational, and historic sources.

In this model, security experts do more than review AI outputs. They build context, assembling and continuously deepening the organizational and historic knowledge that makes automated investigations reliable, and they also handle low-confidence verdict review and lead incident response. The same architecture carries Daylight's threat hunting service and its Agentic Security Data Lake. It also handles managed phishing, including the user-reported submissions that often sit in a separate queue elsewhere. MDR is the entry point, not the ceiling.

Frequently Asked Questions About MDR Providers

What Should I Look for in MDR Provider Transparency?

Transparency has two halves and providers usually deliver only the first. The evidence half is what got checked. The access half is whether your own people can pull that up unprompted, for any case, while it is still open. Ask how many of your team get that access, whether it reaches cases closed six months ago, and whether anything is held back as proprietary. Vague answers on the second half mean the service produces reports where you wanted an audit trail.

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

Do not take the answer on faith. Watch it happen. During a proof of concept, pick an alert sitting in your own console, let the provider resolve it, and see whether the status changes there without anyone on your side touching it. A genuine write lands through something like Microsoft Graph or the Okta Management API, and you can see the timestamp. If your console still shows the alert open after the provider has called it closed, the integration reads and does not write.

How Do I Evaluate the People Behind an MDR Service?

Most evaluations stall on the wrong evidence. Headcount, certification lists and an org chart tell you what the provider employs, not who lands on your account. Push for specifics instead: the experience floor for anyone touching your alerts, who holds the authority to isolate a host without checking with you first, and how often that authority actually gets used. Those answers describe the service you will receive.