EDR vs MDR: Buying a Tool vs Buying Someone to Respond at 3am

Buying endpoint detection and response gives you sensors and alerts, but it does not give you anyone to read those alerts at 3am or the authority to isolate a laptop before ransomware spreads. EDR is a product: an agent, a console and a detection engine. Managed detection and response (MDR) is a service: people, process and usually technology that triage, investigate and act on what the tools see. This guide compares the two as a buying decision: who triages and contains, what response authority and service levels look like, the staffing arithmetic behind 24x7 cover, how each option fails, the identity and cloud gaps both can leave, and how the answer changes with team size. It is written for security leaders, SOC managers and buyers. Product mechanics are covered in the EDR Guide and service contracting in the MDR Guide; this page is about choosing between them, or combining them.

Key takeaways

• They are not alternatives at the same layer: EDR is the sensor and response tooling; MDR is the team that operates detection and response, often on top of an EDR you already own.
• The real question is who acts, and how fast: an EDR alert that nobody triages for 14 hours over a weekend is functionally the same as no alert.
• 24x7 cover is a staffing problem before it is a tooling problem: one seat staffed around the clock is 168 hours a week, which takes roughly five or more people once leave, training and sickness are allowed for.
• MDR without containment rights is expensive notification: the contract must pre-approve specific actions on specific asset classes, or the provider can only email you.
• Both leave gaps outside the endpoint: identity providers, SaaS and cloud control planes need their own telemetry and response actions, whoever operates them.

The short answer

If you have, or can fund, a team that covers alerts around the clock and has authority to act, buy EDR and run it yourself. If you cannot staff nights and weekends, or your team is two to five generalists, buy MDR, and preferably one that can operate the EDR you already licence so you keep the telemetry and the agent if you change provider. Many mid-sized organisations land in between: in-house analysts in business hours, MDR out of hours, with a written handover. Antivirus versus EDR is a separate decision, covered in EDR vs Antivirus; MDR versus a traditional managed security service is covered in MDR vs MSSP.

EDR in-house: threat model, architecture and limits

Threat model. EDR is built for attacks that execute on managed hosts: malware, hands-on-keyboard intrusion, credential theft from memory, lateral movement and ransomware staging. It records process creation, command lines, file and registry changes, network connections and module loads, and applies behavioural detections to that stream. Its value depends on someone acting on what it raises within the attacker's timeline.

Architecture in words. An agent on each workstation and server sends telemetry to a vendor cloud or on-premises backend. Detections fire there and on the agent. Analysts work alerts in a console, pivot through process trees and run response actions: isolate the host from the network while keeping its connection to the console, kill a process, quarantine a file, collect an investigation package, or open a remote shell. Most platforms also offer automated responses for high-confidence detections. The EDR Telemetry Guide covers what is collected and how to use it.

Failure modes.

• Unworked alerts: a high-severity alert at 02:10 on Saturday waits until Monday because nobody is on call.
• Tuning debt: noisy rules train analysts to close alerts unread; broad exclusions create blind spots. See the EDR Tuning and Exclusions Management Guide.
• Coverage drift: new servers, rebuilt images and acquired estates never get the agent, and nobody reconciles agent counts against the asset inventory.
• Tampering: attackers disable or modify security tools (ATT&CK T1685 Disable or Modify Tools) and an in-house team without alerting on sensor health does not notice the silence. See the EDR Tampering and BYOVD Response Playbook.

Controls that make it work. A named on-call rota with paging for critical alerts, automated isolation for a short list of high-confidence detections, sensor health alerts, weekly coverage reconciliation and a quarterly tuning review.

MDR: threat model, architecture and limits

Threat model. MDR addresses the same attacks, plus the organisational threat that you cannot staff detection and response yourself. The provider brings analysts, threat hunting and incident handling across many customers, so a technique seen at one client can become a detection for all.

Architecture in words. Either the provider supplies its own EDR agent, or it connects to the EDR you already licence through the vendor's management APIs and partner access. Telemetry and alerts flow to the provider's analysts, who triage, investigate, and either act within agreed limits or escalate to your contacts. Better services also ingest identity, email and cloud logs. The provider's staff hold privileged access to your security tooling, which makes the provider a high-value third party: an attacker who compromises the provider can reach its customers through that trust (ATT&CK T1199 Trusted Relationship). The CISA risk considerations for MSP customers make the point plainly: outsourcing does not transfer the customer's risk, and it can reduce visibility of your own environment.

Failure modes.

• Notification without action: the provider sees ransomware staging at 03:00, has no right to isolate servers, emails a shared mailbox and waits.
• Escalation dead ends: named contacts are on leave, phone numbers are out of date, or the escalation route reaches someone without authority to approve containment.
• Thin context: the provider closes a genuine intrusion as "admin activity" because nobody told it which accounts run scheduled tasks or which change windows exist.
• Scope assumptions: you believe identity and cloud are covered; the order form covers endpoints only.
• Locked-in telemetry: at renewal you discover detections, history and the agent itself belong to the provider.

Controls that make it work. A responsibilities matrix, a pre-approved action list, tested escalation contacts, direct customer access to raw telemetry, and exit terms. The Canadian Centre for Cyber Security's recommended SOC contract clauses (ITSM.00.500) include placeholders for an agreed notification timeframe after detection, a timeframe to begin remediation, continuous 24/7 monitoring and audit trails of all SOC service activity.

Response authority and service levels

The single most important difference between a useful MDR service and an expensive alert feed is what the provider may do without asking. Write it down by action and asset class, and test it.

This is an example starting point, not a standard; your matrix should reflect business impact. Service accounts are singled out because disabling one can stop a production process, which is why the owner must approve. Service levels to agree, each measured from detection rather than from ticket creation:

• Time to notify by severity, with the channel (phone for critical, ticket for low).
• Time to begin containment for pre-approved actions.
• Customer response obligation: how fast you must answer an escalation, and what the provider does if you do not.
• Reporting: actionable notifications and daily summary reports, both listed in ITSM.00.500, plus a regular service review.

The NCSC guidance on choosing a managed service provider advises agreeing notification timeframes by severity in the contract and asking what happens if the provider itself suffers an incident. Response authority in depth is covered in the MDR Guide.

Staffing maths for 24x7 cover

The arithmetic is simple and is the reason most small and mid-sized organisations buy MDR. A week has 168 hours. A full-time analyst on a 37.5 to 40 hour contract covers about a quarter of that before any absence.

These figures are straightforward division plus an allowance for absence; adjust for your contracted hours and leave entitlement. Add a lead or manager, detection engineering time, and the cost of attrition. The ASD's ACSC executive guidance on SIEM and SOAR notes that this work needs highly skilled people, that retaining them in-house is difficult because the skills are in high demand, and that it can involve long periods of stressful activity. A single overnight analyst also has no one to check their decisions during a major incident. If the realistic headcount is beyond your budget, an in-house 24x7 model is not a real option, and the choice is between MDR and accepting unworked out-of-hours alerts.

On-call as a middle path: business-hours analysts plus paged on-call for critical alerts can work for low alert volumes, but it fails when pages are frequent: tired engineers acknowledge and defer. Track pages per night; if on-call staff are woken regularly, the model is not sustainable. The Alert Fatigue Reduction Guide covers reducing volume first.

Where identity and cloud fall through the gap

EDR sees processes on hosts. Many modern intrusions never run a suspicious process: a phished session token is replayed against the identity provider, a mailbox rule forwards invoices, an OAuth app gains consent, or a cloud access key is used from a new location (ATT&CK T1078.004 Cloud Accounts). Neither an in-house EDR team nor an endpoint-only MDR service will see these unless identity provider sign-in logs, SaaS audit logs and cloud control plane logs are in scope with response actions to match: revoke sessions, reset credentials, remove consent grants, disable keys.

• Ask the provider which identity and cloud sources it ingests and which response actions it can take in each, by name. "Cloud coverage" on a datasheet is not a scope statement.
• Machine identities need owner approval: service accounts, API keys and workload identities often run critical processes. Pre-approve monitoring, but keep disablement with the owner, and give the provider an inventory of which accounts are non-human and who owns them.
• Treat the provider's own access as privileged third-party access: named accounts, MFA, least privilege, separate logging the provider cannot alter. CISA recommends keeping MSP accounts out of administrator groups and feeding MSP activity logs into your own monitoring. See the Third-Party Access Guide.

The ITDR vs EDR comparison and the Cloud Detection and Response Guide cover the tooling for these planes.

Worked scenarios

Scenario 1: 400-person firm, two IT generalists, EDR already licensed. Alerts are reviewed in business hours. A ransomware affiliate gains access on Friday evening through a stolen VPN credential and begins staging on Saturday. EDR raises high-severity alerts that sit in the console until Monday. Fix: MDR that operates the existing EDR, with pre-approved isolation of workstations and servers for ransomware indicators, and identity provider logs in scope so the VPN credential misuse is visible. Cost comparison: a service fee against five or more new hires.

Scenario 2: 3,000-person organisation with a six-analyst SOC working 07:00 to 19:00. Day cover is strong, nights are on-call. Pages run at several per night and the team is tiring. Fix: MDR for 19:00 to 07:00 and weekends, operating on the same EDR and SIEM, with a written shift handover, shared case notes and the in-house team owning detection engineering. The Co-Managed SOC and SOC-as-a-Service Guide covers this model.

Scenario 3: regulated enterprise with a 24x7 in-house SOC. MDR adds little for triage. The better buy may be targeted threat hunting or an incident response retainer for surge capacity. See the Incident Response Retainer Buyer's Guide.

Decision guidance by team size

Choose MDR on your existing EDR when you already have a mature agent deployment, want to keep telemetry ownership and may switch provider later. Choose bundled MDR when you have no EDR or a poorly deployed one and want one party accountable for agent, detection and response. Stay in-house when sensitive data or critical services make outsourced access hard to justify; the ACSC guidance suggests in-house operation may be necessary in those cases. The MDR Buyer's Guide and EDR and XDR Buyer's Guide cover evaluation criteria.

Implementing the choice

1. Measure today's reality: alert volume by severity and hour of day, median time from alert to first human action, out-of-hours alerts left unworked, and agent coverage against the asset inventory.
2. Decide the coverage model using the staffing table, and document who acts out of hours.
3. Write the responsibilities matrix and action list before talking to providers, so you buy against your requirements rather than their datasheet.
4. Onboard context: asset criticality, service account inventory, admin tooling, change windows, VIP users and escalation contacts.
5. Pilot: run the provider in notify-only mode on a subset for two to four weeks, compare its triage with yours, then switch on pre-approved actions for workstations first, servers second.
6. Test response: run a tabletop and an announced purple-team test that should trigger isolation, and time every step. See the Tabletop Exercise Guide.
7. Plan rollback and exit: keep console access, a copy of custom detections and a documented route to remove or re-home agents. For bundled agents, agree the uninstall process and timeline in advance.

Detection and measurement

Whoever operates the tooling, measure outcomes, not activity:

• Time to first human action on high and critical alerts, split business hours versus out of hours.
• Time from detection to containment for pre-approved actions.
• Customer escalation response time: how long your own staff take to answer the provider. This is often the slowest link.
• Agent coverage: percentage of inventoried endpoints with a healthy, reporting agent.
• Unworked alert count older than 24 hours.
• Test pass rate: share of planned detection tests that were detected and contained within the agreed time.

Also log and review the provider's own actions in your environment, from your systems, not from its reports.

Framework mapping

Common failure patterns

• Buying EDR as if it were a service: the console is full of alerts nobody owns outside business hours.
• Signing MDR with no action list: the provider watches the incident unfold and opens tickets.
• Stale escalation contacts: the first real incident reveals the on-call number belongs to someone who left.
• Endpoint-only scope in an identity-driven attack: token theft, mailbox rules and cloud key misuse go unseen.
• Unmonitored provider access: broad, standing admin rights for provider staff, logged only in the provider's systems.
• No exit plan: history, detections and agents are tied to the provider and switching means rebuilding from scratch.

Practitioner checklist

• Measure out-of-hours alert handling and time to first action before deciding.
• Work out realistic headcount for the coverage you need, including absence.
• Write a pre-approved action matrix by action and asset class, with service accounts kept for owner approval.
• Agree notification and containment times measured from detection, plus your own response obligation.
• Put identity provider, SaaS and cloud logs and actions in scope, by name.
• Give the provider named, MFA-protected, least-privilege access and log it in your own systems.
• Keep console access, raw telemetry and copies of custom detections.
• Pilot in notify-only mode, then enable actions in stages.
• Test containment at least twice a year with a timed exercise.
• Review coverage, unworked alerts and test results monthly.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• Canadian Centre for Cyber Security: Recommended contract clauses for security operations centre procurement (ITSM.00.500)
• CISA: Risk Considerations for Managed Service Provider Customers
• NCSC: Choosing a managed service provider (MSP)
• ASD's ACSC: Implementing SIEM and SOAR Platforms, Executive Guidance
• NCSC: Building a Security Operations Centre
• ASD's ACSC and partners: Best Practices for Event Logging and Threat Detection
• MITRE ATT&CK: T1199 Trusted Relationship

Related NHI Mgmt Group resources: MDR Guide, EDR Guide, EDR vs Antivirus, MDR vs MSSP, MDR Service RFP Template.