2026-07-15 · Team Fenrir

MDR vs EDR: the real differences, from the operator's seat

EDR and MDR don’t compete: one is a tool, the other is a service. The EDR is the agent that records and blocks on the endpoint; the MDR is whoever watches that agent, queries it and responds — including at 2 a.m. Buying an EDR gets you telemetry and buttons. Buying an MDR means someone actually presses those buttons. Let’s look at what each one really does, and where the line runs.

What is an EDR, in practice?

The category has a precise birthday: 26 July 2013, when Gartner analyst Anton Chuvakin named “Endpoint Threat Detection & Response” the tools “primarily focused on detecting and investigating suspicious activities (and traces of such)” on hosts and endpoints. The “T” got lost along the way; the job stayed the same. A modern EDR does four things:

1. Records — processes launched, network connections, file and registry changes, commands executed. Continuously, on every endpoint.
2. Detects — rules and behavioural analytics over that telemetry: the hidden PowerShell, the process touching hundreds of files in a minute.
3. Enables investigation — the timeline of what happened before and after the alert, on which machine, under which user.
4. Exposes response actions — isolate the host from the network, kill a process, quarantine a file.

Note the verb: exposes. An EDR hands you an alert queue and a button panel. It doesn’t decide who watches the queue, with what priority, within what time — and it doesn’t press the buttons by itself, except in the most clear-cut cases.

What is an MDR, in practice?

Managed Detection & Response is the other half of the job, delivered as a service: someone — outside your company — mounts detection on top of your endpoints and operates it. Continuous monitoring, alert triage, investigation, containment, proactive threat hunting, rule tuning. An MDR is usually built precisely on top of an EDR (yours or the provider’s): same sensor, but with a work shift attached.

That people, not technology, are the critical point is confirmed by the ones who evaluate these services: when MITRE Engenuity launched its ATT&CK Evaluations for managed services in 2021, it cited a preliminary survey in which 58% of organisations relied on managed services for their SOC — and roughly half were not confident in their provider’s people or technology. Hence the “closed book” format: the provider doesn’t know which adversary will be emulated, exactly like in real life.

The fundamental difference is the deliverable. An EDR delivers software and telemetry. An MDR delivers an outcome: the incident triaged, contained, explained.

I already have an EDR — what am I missing?

Three things, and none of them is a module you can add at checkout.

Someone watching the queue. An EDR on a few dozen endpoints produces alerts every day: true ones, false ones, and the grey zone in between that eats time. Without an owner for triage — with defined response times — the queue becomes background noise, and the real alert drowns among false positives.

Someone there off-hours. Attackers pick their moment: in the ransomware cases Mandiant analysed between 2017 and 2019, 76% of executions happened outside business hours — weekends, before 8 a.m., after 6 p.m. That’s no accident: it’s when nobody is watching the EDR queue.

Someone to put out the fire, and how. Response isn’t a button but a process: NIST dedicated SP 800-61r3 (2025) to it, treating incident response as a continuous cycle — preparation, detection, response, recovery — inside risk management, not as an isolated gesture. Isolating the right host at the right moment, deciding whether a reimage is needed, reconstructing the entry vector: that takes playbooks and trained hands.

And there’s a fourth point, the most unpleasant one: the EDR is a target. MITRE ATT&CK catalogues as T1685 (Disable or Modify Tools, formerly T1562.001) the attacker practice of disabling, degrading or tampering with security tools — EDR included — to blind the defence. A sensor that stops talking sends no alert: it’s a silence, and silence is only noticed by someone who is listening.

How much does time matter, with actual numbers?

Dwell time — how long an attacker stays in the network before being discovered — is the metric that separates a nuisance from a disaster. M-Trends 2025 (2024 data, over 450,000 hours of Mandiant investigations) draws this picture:

• global median dwell time: 11 days;
• when the organisation finds out by itself: 10 days;
• when it finds out because someone outside notifies it: 26 days;
• when it’s the attacker itself announcing (typically the ransom note): 5 days.

Read that last line for what it is: in the worst cases, “detection” is the ransomware introducing itself. The difference between 10 and 26 days is the difference between having operated detection — by an internal team or an MDR — and waiting for someone else to notice.

MDR, SOC, XDR: how do the acronyms fit together?

An operator’s glossary, no marketing:

• EDR — tool. Sensor and actuator on the endpoint.
• XDR — tool. Like EDR, but extends collection and correlation to network, identity, cloud, email.
• SOC — function. The people, processes and technology that monitor and respond, in-house.
• MDR — service. The operational functions of a SOC bought from outside, normally on the provider’s predefined stack.

The question “EDR or XDR?” is about what you collect. The question “in-house SOC or MDR?” is about who responds. They are two different axes, and mixing them up is the fastest way to buy the wrong thing.

How do I choose between EDR alone and MDR?

Three honest questions to ask yourself before looking at any price list:

1. Who triages a critical alert within 30 minutes, today? A first and last name, not “the IT department”.
2. Who does it on Saturday at 3 a.m.? (Re-read that 76% above.)
3. Who tunes the rules and hunts for threats every week? An EDR that’s never tuned screams, and whoever screams constantly stops being heard.

If any answer is “nobody”, your EDR is a black box: it will record perfectly the incident nobody stopped. At that point you have two options — build the coverage (people, shifts, playbooks) or buy it as a service.

And if you’re evaluating an MDR, turn the table around with operator questions: which response actions is it authorised to take on its own (isolation? process kill?) and which require your approval? What containment times does it declare, measured how? Does the telemetry stay yours if the contract ends? And how does it prove detection quality — has it ever accepted an independent blind-scenario evaluation, like MITRE Engenuity’s ATT&CK Evaluations?

And where does AI fit in?

It’s the third way to cover the night shift. The bottleneck of classic MDR is people — finding them, training them, keeping them awake — which is why our approach in Fenrir MDR flips the scheme: the AI does detection, triage and containment in graduated autonomy (above a confidence threshold it acts alone, with reversible actions; below, it asks), and the human supervises high-impact decisions. Endpoints and servers land in the same SOC console, correlated. The principle doesn’t change though, and it’s the point of this whole article: a tool without someone — or something — operating it is just well-archived telemetry.