What happens when the security service you hired to watch your network around the clock still can’t see the attack unfolding in front of it?
That question drives much of the managed detection and response (MDR) conversation. MDR has grown into one of the fastest-growing segments in cybersecurity, with vendors offering 24/7 monitoring, threat hunting by analysts and rapid response without the cost of building an in-house security operations center. For organizations short on staff, that offer carries weight.
But MDR is not a silver bullet. It has real, structural limitations that buyers often discover only after signing a multi-year contract. Understanding those limits before you buy is the difference between a service that genuinely reduces risk and one that generates a steady stream of alerts nobody acts on. This article breaks down the most significant MDR limitations, how they show up in practice, and what buyers can do about them.
MDR only sees what you feed it
The single biggest limitation of MDR is visibility. A provider can only detect and respond to threats it can observe, and what it can observe is bounded by the telemetry you forward. If your endpoints, identity systems, cloud workloads, and network devices aren’t properly instrumented, the provider is working with a partial picture.
This is where the gap between marketing and reality gets wide. Vendors often advertise broad coverage across endpoint, network, cloud, and identity. In practice, coverage depends on:
- Which endpoint detection and response (EDR) agent you run, and whether it’s healthy on every asset
- Whether logs from identity providers, SaaS apps, and cloud infrastructure are actually flowing
- Whether operational technology (OT) and industrial control systems are instrumented at all
- How many unmanaged or shadow IT assets exist outside the official inventory
Uninstrumented assets are a chronic blind spot. Many organizations discover during onboarding that a meaningful share of their estate was never sending logs. The provider can’t hunt across data it never received. Before signing, ask for a written telemetry inventory and a coverage map. Then verify it against your own asset list rather than trusting the sales deck.
Alert fatigue doesn’t disappear, it moves
One of MDR’s selling points is relief from alert overload. The reality is more complicated. Detection engines generate high volumes of alerts, and analysts must triage them. When detection rules are tuned loosely, false positives climb. When they’re tuned tightly, genuine threats slip through. Either way, someone absorbs the cost.
Alert fatigue is a well-documented problem across security operations, and outsourcing detection doesn’t eliminate it. It shifts the burden to the provider’s analysts, whose capacity is finite. A provider juggling hundreds of customers may apply generic triage logic that fits your environment poorly. The result: alerts that matter get buried, and alerts that don’t matter still consume attention.
What actually works in practice is a tuning loop. Insist on a documented process for reviewing false positives, adjusting detection rules, and reporting on alert quality over time. If a provider can’t show you how tuning happens after onboarding, assume it doesn’t happen at all.
Response authority is often narrower than buyers expect
The “response” in MDR is where expectations diverge most sharply from contracts. Many agreements stop at notification or guided response: the provider tells you what’s happening and recommends action, but your team executes it. Full remote containment, where the provider isolates a host or disables an account on your behalf, is often a premium tier or excluded entirely.
That gap matters because dwell time is measured in minutes. If an alert fires at 2 a.m. and your on-call engineer doesn’t act until 8 a.m., the provider’s fast detection bought you very little. Before signing, clarify in writing:
- Which response actions the provider can take unilaterally
- Which actions require your approval, and how approval is obtained
- The contractual timeframes for escalation and containment
- Who holds liability if a response action causes an outage
Organizations that skip this step often assume they bought automated containment when they actually bought a very expensive alerting service.
Tooling dependence makes MDR hard to compare
MDR is not a standardized product. Two providers offering “MDR” may deliver radically different services depending on the customer’s existing stack. Some providers require you to run their preferred EDR. Others are tool-agnostic and work with what you have. Effectiveness varies with the quality of your logs, the health of your agents, and the maturity of your SIEM.
This variability creates a measurement problem. There’s no universal benchmark for detection efficacy, and published mean-time-to-detect (MTTD) or mean-time-to-respond (MTTR) figures are rarely backed by auditable methodology. Buyers end up comparing marketing claims rather than outcomes.
A practical workaround is to demand reference customers in your industry and size band, then ask those references specific questions: How many true positives per month? How often did the provider catch something your team missed? How fast was containment in a real incident? Vague answers are a warning sign.
Detection struggles with living-off-the-land tradecraft
Modern attackers increasingly avoid malware in favor of living-off-the-land techniques: abusing legitimate tools like PowerShell, command-line utilities, and built-in administrative functions. These techniques generate activity that looks similar to normal administration, which makes signature-based and even behavioral detection harder.
MDR providers lean heavily on threat intelligence feeds and detection content from third parties. That content is valuable, but it’s inherently reactive: it detects what’s already known. Novel tradecraft, custom tooling, and targeted intrusions can evade rule-based detection for extended periods.
This is not a reason to skip MDR. It is a reason to ask hard questions about hunting. Does the provider perform proactive threat hunting beyond automated detection? How often? Can they describe a hunting hypothesis they pursued recently and what it found? Providers that can’t answer specifically are likely running detection-as-a-service, not genuine hunting.
If you want to understand how detection gaps show up in adjacent areas, the same principle applies to content and media: knowing how to spot AI-generated content with an easy detection guide illustrates how detection always depends on the signals you can actually observe.
Data handling and regulatory constraints
Cross-border telemetry sharing creates friction. Data residency rules, privacy regulations, and sector-specific compliance requirements can limit what a provider is permitted to ingest, store, or act on. A provider with a single global SOC may be unable to process certain categories of data from regulated customers, or may need to route it through regional infrastructure that adds latency.
There’s also the question of what happens to your data after the contract ends. Telemetry contains sensitive information about your infrastructure, user behavior, and business operations. Ask about retention periods, deletion procedures, and whether your data is used to train or improve the provider’s detection models. These terms are negotiable more often than buyers assume.
The staffing and expertise gap
MDR promises access to expert analysts. The constraint is that expert analysts are scarce everywhere, including at providers. Tier-one triage is often handled by less experienced staff working from playbooks, with escalation to senior analysts for complex cases. During peak alert volumes, escalation queues back up.
The practical consequence is variance. The quality of service you receive can depend on which analyst is on shift, how well your environment is documented, and whether your account has a dedicated team or rotates through a shared pool. Ask whether you get named analysts, what their typical caseload is, and how turnover is managed. High turnover at a provider means your environment’s institutional knowledge walks out the door repeatedly.
For a sense of how tooling limitations shape outcomes more broadly, the constraints described in this breakdown of AI article generator features and limitations mirror the MDR problem: capability claims are easy, and the real limits surface in edge cases. (Cybersecurity Best Practices)
Cost and contract rigidity
MDR pricing models vary widely: per endpoint, per user, per gigabyte of logs ingested, or flat fee. Log-based pricing creates a perverse incentive to reduce telemetry to control costs, which directly undermines detection. Per-endpoint pricing can balloon as your estate grows.
Contracts also tend to be sticky. Multi-year terms with auto-renewal, limited termination rights, and onboarding fees make switching expensive. That reduces provider accountability after year one. Negotiate shorter initial terms, clear performance metrics with remedies, and an exit clause tied to service levels.
What actually works in practice
None of these limitations means MDR is a bad investment. It means MDR works best when buyers treat it as one layer of a defense-in-depth strategy rather than a replacement for internal capability. Practical steps that consistently pay off:
- Map your telemetry before you buy. Build the coverage inventory yourself and compare it to what the provider claims.
- Write response authority into the contract. Specify exactly which actions the provider can take without approval.
- Test the service. Run a tabletop exercise or a controlled simulation and observe how the provider detects and escalates.
- Review alert quality quarterly. Track false positive rates and tuning changes as well as ticket counts.
- Keep internal skills alive. An organization that can’t investigate an alert independently is fully dependent on its provider.
The same discipline applies to adjacent security tooling. If you’re evaluating detection capabilities for phishing or insider threats, the practical guidance in this guide on how to detect AI-generated images reinforces a universal rule: verification requires independent checks, not trust in a single vendor’s output.
Conclusion
MDR delivers real value, particularly for organizations without the resources to run 24/7 security operations internally. But its limitations are structural, not incidental. Visibility is bounded by telemetry. Response authority is bounded by contract. Detection is bounded by the known. Efficacy is bounded by analyst capacity and tooling quality.
Buyers who understand these constraints negotiate better contracts, instrument their environments more thoroughly, and keep enough internal capability to verify what their provider tells them. Buyers who don’t often learn the limits the hard way, during an incident. The difference between those two outcomes is preparation, not luck.
Frequently Asked Questions
Does MDR replace an in-house security team?
No. MDR augments internal capability rather than replacing it. Most providers handle monitoring, triage, and escalation, but organizations still need someone who can make business decisions during an incident, approve containment actions, and maintain the underlying infrastructure. Organizations that eliminate internal security expertise often find themselves unable to act on what their provider reports.
What is the biggest limitation of MDR?
Visibility. A provider can only detect threats in telemetry it receives. Uninstrumented endpoints, missing cloud logs, and unmanaged assets create blind spots that no amount of analyst expertise can compensate for. Buyers should verify coverage against their own asset inventory rather than relying on vendor claims.
Can MDR providers automatically contain threats?
Some can, but many contracts limit response to notification or guided remediation. Full remote containment is often a premium tier or requires customer approval. The scope of response authority should be specified explicitly in the contract, including escalation timeframes and liability for actions that cause outages.
How do I measure whether my MDR provider is effective?
Insist on metrics with defined methodology: true positive volume, false positive rate, detection and escalation times, and examples of threats caught. Ask reference customers in your industry specific questions about real incidents. Avoid providers that only report ticket counts or vague satisfaction scores.
Is MDR worth it for small organizations?
Often yes, because building 24/7 coverage internally is prohibitively expensive for most small teams. But small organizations should prioritize providers offering transparent pricing, clear response authority, and onboarding support for telemetry gaps. The risk is buying monitoring that generates alerts your team can’t act on.
How often should MDR detection rules be tuned?
Continuous tuning is ideal, with a formal review at least quarterly. Environments change constantly, and detection rules that fit six months ago may generate noise or miss new assets today. Ask providers to document tuning changes and their impact on alert quality, and treat tuning as an ongoing process rather than a one-time setup task.
