What is the difference between MDR and EDR?

EDR is software: an agent on endpoints that detects suspicious behaviour and offers response actions, operated by your own team. MDR is a service: a provider's analysts operate an EDR or XDR platform for you 24/7, investigate alerts, hunt for threats and contain confirmed incidents under an agreed mandate. EDR gives you alerts; MDR gives you handled incidents.

What is the difference between MDR and XDR?

XDR is a platform that correlates telemetry from endpoints, identity, email, cloud and network into unified incidents; you still need analysts to run it. MDR is the service layer in which a provider runs that platform around the clock. Many MDR services are built on XDR, so the real comparison is tool alone versus tool plus people.

Do I need MDR if I already have EDR or XDR?

You need MDR if nobody on your side can investigate and contain an alert within minutes at any hour. If you have a staffed 24/7 security operation you may not need it for core coverage, but it can still add out-of-hours depth, threat hunting or coverage for a domain your team does not know well. The test is operational, not technical.

Can MDR and EDR be used together?

Yes, and that is the normal arrangement. MDR requires an EDR or XDR platform to see and act on; the provider either supplies one or manages yours. Owning the platform yourself keeps your data and your exit path in your hands and is usually the better choice for organizations with any security staff of their own.

Does MDR replace an internal security team?

No. MDR replaces the need to staff a console 24/7, but someone inside the organization must own decisions, approve exceptions to the containment mandate, drive remediation and hold the provider to account. In practice MDR lets a small internal team spend its time on architecture, vulnerability management and governance instead of alert triage.

Is XDR just a bigger EDR?

In many products XDR grew out of EDR, so the endpoint agent is the strongest part of the platform. The distinguishing value of XDR is correlation across identity, email and cloud telemetry, where modern intrusions begin. If a product sold as XDR has only thin connectors to those sources, treat it as EDR with log collection when you compare it.

Which option satisfies HIPAA, PCI DSS or NYDFS monitoring requirements?

None of these frameworks names a product category. They require continuous monitoring, incident detection, documented response and, under NYDFS 500.17 and SEC Item 1.05, reporting on a clock. Any of the three can meet that if it is operated and documented; MDR produces the operating record by default, which is why regulated organizations without a 24/7 SOC usually land there.

2 November 2026 · 10 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

MDR vs EDR vs XDR: two tools and one service, and how to decide which your organization actually needs

EDR and XDR are software you buy and run. MDR is a service in which people run that software for you around the clock. Most confusion in this market comes from vendors selling all three with the same vocabulary. This guide separates them by telemetry, by who operates them and by what happens when an alert fires at night.

Talk to us about MDR

The short answer: EDR and XDR are tools, MDR is a service

Endpoint detection and response (EDR) is an agent on laptops, servers and virtual machines that records process, file, memory and network behaviour, detects suspicious patterns and offers response actions such as isolating a host or killing a process. Extended detection and response (XDR) widens that model beyond the endpoint: it ingests and correlates telemetry from identity providers, email, cloud workloads, SaaS applications and network sensors, so one investigation can follow an attacker from a phishing email to a compromised account to a server. Both are technology. Both produce alerts a human has to read.

Managed detection and response (MDR) is not a third product category. It is a service in which a provider's analysts operate an EDR or XDR platform (theirs or yours) 24 hours a day, triage what it produces, hunt for what it misses, and take or direct containment action under an agreed mandate. The deliverable of MDR is an investigated incident with actions already taken, not a notification. The difference between EDR, XDR and MDR is the difference between a smoke detector, a building-wide alarm system, and a fire brigade on retainer.

The question that matters in MDR vs EDR, or MDR vs XDR, is therefore not which is better. It is who in your organization will read the alert at 03:00, decide whether it is real, and isolate the machine. If the honest answer is nobody, you are comparing a tool against a service, and the tool loses regardless of how good its detection engine is.

EDR, XDR and MDR defined, one at a time

What each is, what telemetry it sees, and who has to operate it. The third point is where organizations misjudge their readiness.

EDR: detection and response on the endpoint

An agent on every endpoint that records behaviour, compares it against behavioural rules and indicators, and exposes response actions (isolate, quarantine, kill, collect forensic artefacts). Telemetry: the host only. Operated by: your team, during their working hours, unless someone is paid to watch overnight. Blind spot: an attacker who never touches an agent-covered host, for example one who signs into your cloud console with stolen credentials.

XDR: detection and response across domains

A platform that combines endpoint telemetry with identity logs (sign-ins, token grants, privilege changes), email events, cloud audit logs, SaaS activity and network data, and correlates them into one incident timeline. Telemetry: as wide as the sources you connect and license. Operated by: still your team. XDR reduces alert volume by correlating; it does not remove the need for someone to investigate what remains.

MDR: people operating EDR or XDR for you, 24/7

A service in which analysts monitor the platform continuously, write and tune detections, triage alerts, investigate incidents, hunt for undetected activity, and contain threats within a mandate you define (for example: isolate any host, disable any non-executive account, revoke sessions). Telemetry: whatever the underlying platform sees. Operated by: the provider, with your team deciding on escalations. Caveat: a provider that only notifies is a monitoring service wearing the MDR label.

MDR vs EDR vs XDR side by side

Generalised from how the three are sold to US mid-market and enterprise buyers in 2026. Contracts vary; read yours against this table.

Dimension	EDR	XDR	MDR
What it is	Software agent and console	Software platform with multi-source ingestion	Service that operates EDR or XDR with analysts
Scope of telemetry	Endpoints and servers	Endpoint, identity, email, cloud, SaaS, network	Inherits the platform's scope; good providers insist on identity and cloud sources
Who operates it	Your analysts	Your analysts	Provider's analysts, 24/7, your team on escalation
Response capability	Actions available; a human must trigger them	Broader actions (disable account, block sender, revoke token); a human still decides	Provider executes containment under a pre-agreed mandate, then reports
Threat hunting and detection content	Vendor rules; hunting only if you staff it	Vendor correlation; hunting only if you staff it	Detections engineered and tuned for your environment; hunting with a defined cadence
Coverage window	Your working hours unless you run shifts	Your working hours unless you run shifts	Continuous
Cost logic	License per endpoint; hidden cost is analyst time	License plus data ingestion; hidden cost is integration and analyst time	Subscription per endpoint or user that includes the people, usually the platform too
Best for	Teams with analysts who can staff a console	Teams with analysts and a multi-domain, identity-heavy estate	Organizations without a 24/7 security operation, or with one that needs depth

The tool-versus-service trap

The most common failure we see on offensive engagements is not a missing control but an unattended one. The organization bought a well-regarded EDR, deployed it to most endpoints and configured alerts. During an internal penetration test the agent duly flags credential dumping and lateral movement. Nobody reads the alert for 36 hours, because the two-person security team was in meetings, then asleep, then in meetings again. On paper the company had detection and response. In practice it had detection and a queue.

The trap works in both directions. MDR on top of an EDR deployed to 60 percent of endpoints, with no identity or cloud telemetry connected, buys 24/7 attention to a partial picture: the provider is blind to the attacker who signs into your SaaS tenant with a valid session token. MDR is only as good as the telemetry beneath it, which is why serious providers run a coverage assessment before go-live and report gaps monthly afterwards. A third version is semantic: MDR that only notifies, XDR that is an EDR with a few log connectors. Read the contract for the list of telemetry sources the provider will own and for the written containment mandate. If either is vague, you are not buying what the label says.

Decision tree by team size and maturity

Five starting positions cover most US organizations. Find yours before you compare vendors.

1. No dedicated security staff; IT generalists carry security

Choose MDR that includes the platform. You do not have people to operate EDR or XDR, and buying either without an operator produces alerts nobody reads. Insist on identity and email telemetry from day one and a containment mandate that lets the provider act at night. Name one accountable person on your side for escalations.

2. One to three security staff working business hours

Own the EDR or XDR platform (your tenant, your data, your exit path) and contract MDR to operate it, often called co-managed. Your team keeps business context and detection ownership; the provider covers nights, weekends, surge and hunting. Agree who tunes detections and how changes are reviewed.

3. A staffed security operations function, but not 24/7

XDR with your own analysts by day, MDR for out-of-hours coverage and threat hunting. The shared platform makes handovers work because both teams see the same timeline. Ask whether the provider's hunting is informed by your penetration test and red team findings; that is where offensive-led providers add measurable detections.

4. A mature 24/7 SOC

You are a platform buyer. Choose EDR or XDR on telemetry breadth, API quality and response actions, and use MDR selectively: surge capacity during incidents, a domain you do not cover well (operational technology, a newly acquired subsidiary), or an independent second pair of eyes. Validate your detection coverage with purple teaming at least annually.

5. Regulated or recently breached, whatever the team size

Evidence drives the choice. Supervisors, auditors and cyber insurers ask who detected, who decided, who contained and when, with records. MDR produces that record as a by-product; a tool only does if your team documents every investigation. Under NYDFS Part 500, HIPAA, CMMC Level 2 or NIS2, start from the reporting clock and work back to the capability that meets it.

How MDR uses EDR and XDR, and where MSSP and SOC fit

Inside an MDR service the platform is the sensor and the hands; the people are the brain. The work is upstream and downstream of the alert: onboarding the right telemetry, writing detections for techniques the vendor defaults miss, suppressing noise, then investigating with the platform's query and timeline tools. Containment uses the platform's own actions: network isolation, process termination, disabling the identity, revoking tokens, blocking the sender domain. Good MDR also runs structured threat hunting, forming hypotheses from current threat intelligence and from the techniques its own offensive teams use. For the mechanics of that loop, read our explainer on what threat hunting is and how it differs from detection.

Readers often arrive here with a related question about managed security service providers (MSSPs) and SOC as a service. In one paragraph: an MSSP operates a broad set of controls (firewalls, email security, vulnerability management, SIEM) and escalates per runbook; SOC as a service is the monitoring function delivered from a provider's security operations centre, with alerting as the main output; MDR is narrower and deeper, focused on containing active threats in endpoint, identity and cloud telemetry. We compare the three models and how to combine them without paying twice in our MSSP vs MDR vs SOC as a service guide, and explain the SOC construct in what SOC as a service is.

Questions to ask before you sign an MDR, EDR or XDR contract

Seven questions, in the order a procurement conversation usually goes. The answers sort real services from relabelled ones.

Which telemetry sources will you onboard and own: endpoints only, or also identity provider sign-in and audit logs, email gateway events, cloud audit logs and SaaS activity?
What is the written containment mandate: which actions may you take without calling us, on which asset classes, and how are executive or production-critical exceptions defined?
Who owns the platform tenant and the raw data, can we export it, and what happens to detections and history when the contract ends?
Describe the escalation path at 03:00 on a Sunday: who is paged on our side, what do they receive, and what have you already done by the time they pick up?
How is detection content maintained, and are any detections informed by penetration test or red team findings from our environment? Is threat hunting a defined activity with a cadence and a report?
Which frameworks does the monthly report map to (NIST CSF 2.0, HIPAA, PCI DSS, SOC 2, NIS2, DORA), and will you tell us every month which assets or sources are not reporting?
Do you welcome an independent purple team or red team exercise against your detections, and what happened the last time a client ran one?

Compliance hooks: where detection and response become evidence

US frameworks first, then EU. None names EDR, XDR or MDR; all require the capability and the record that MDR produces by default.

NIST CSF 2.0: the Detect and Respond functions ask for continuous monitoring, adverse-event analysis and incident management; NIST SP 800-61 Rev. 3 (2025) aligns incident response to those functions and is the reference most US auditors cite.
CMMC 2.0 Level 2 and NIST SP 800-171: the incident response family requires an operational incident-handling capability covering detection, analysis, containment, recovery and reporting, with incidents tracked and documented.
HIPAA Security Rule: 45 CFR 164.308(a)(1)(ii)(D) requires regular review of information system activity, and 164.308(a)(6) requires procedures to identify, respond to, mitigate and document security incidents.
PCI DSS v4.0.1: Requirement 10 covers logging and monitoring, including prompt detection of and response to failures of critical security control systems (10.7); Requirement 12.10 requires an incident response plan that is activated immediately.
NYDFS 23 NYCRR 500: Section 500.16 requires an incident response plan and 500.17 requires notice to the Superintendent within 72 hours of determining a cybersecurity incident.
SEC cyber disclosure rules (2023): a material incident must be disclosed on Form 8-K Item 1.05 within four business days of the materiality determination, which is not possible without an investigated incident record.
EU: NIS2 Article 21(2)(b) requires incident handling and Article 23 sets a 24-hour early warning and 72-hour notification; DORA Article 17 requires an ICT incident management process with detection and classification, and Article 19 governs reporting.

What a good MDR deliverable looks like, and where HackersHub fits

Judge an MDR provider by what you receive, not by the console. Per incident: a timeline from first telemetry to closure, the evidence behind each step, the MITRE ATT&CK techniques observed, the containment actions taken and under which clause of the mandate, root cause where it can be established, and remediation with owners. Monthly: alerts received versus investigated versus escalated, detections added or tuned and why, hunting hypotheses tested, telemetry coverage gaps with the assets involved, and an evidence section mapped to your frameworks. If a provider cannot show redacted versions of all three before you sign, assume you will not get them afterwards.

HackersHub is an Amsterdam-based offensive security firm that also delivers managed security and managed detection and response to enterprise clients in the EU and the US, remotely with on-site travel where needed. Our MDR analysts work alongside the testers who spend their week breaking into environments like yours, and that shapes the service: detection engineering informed by the techniques our red team actually uses, 24/7 monitoring, SIEM and EDR management, incident response support, and reporting that maps to the frameworks above. Managed detection and response by HackersHub is scoped per organization and tested by our own offensive team.

Frequently asked questions

Related guides and services

Not sure whether you need the tool or the service?

Tell us what you run today, who watches it and when. We will tell you honestly whether MDR adds coverage you lack or whether your platform just needs operating differently. Schedule a call with an expert.

Managed detection and response Schedule a call