Why the three terms get confused
EDR, XDR and MDR sound like three versions of the same product. They are not. Two of them describe technology and one describes people. Vendors add to the confusion by selling all three under a single brand. As a result, a company can believe it has bought detection and response when it has bought software that detects and nobody who responds.
The difference matters most to companies that have to prove their security works. An auditor checking ISO 27001 or the ENS does not ask which acronym you bought. The auditor asks whether suspicious activity is detected, whether someone looks at it, and what happened next. A tool can answer the first question. Only a process with people behind it answers the other two.
It also helps to separate all three from traditional antivirus. Antivirus compares files against known malicious signatures and blocks the matches. It is still useful, but attackers increasingly avoid dropping recognisable malware at all. They use legitimate administration tools, stolen credentials and scripts that run in memory. Catching that requires watching behaviour, which is where EDR starts.
What EDR does, and what it cannot see
EDR stands for endpoint detection and response. It is an agent installed on laptops, desktops and servers that records what happens on each device and reacts when that activity looks malicious.
Telemetry, behavioural detection and response actions
An EDR agent collects telemetry continuously: processes started and their parent processes, command lines, file changes, network connections, registry changes, logons. Detection rules and behavioural models look for patterns that signature matching misses. Examples are an office document launching a command shell, a tool that reads credentials from memory, or a process encrypting hundreds of files in a few seconds.
When it detects something, the agent can act. Typical response actions are:
- killing a process;
- quarantining a file;
- isolating the device from the network while keeping a channel open to the security console;
- on some products, rolling back changes made by ransomware.
The telemetry also lets an analyst reconstruct what happened before and after the alert, which turns a single warning into an investigation.
The blind spots
EDR sees what happens on the devices where its agent runs, and only there. Several common attack paths sit outside that view. An attacker who logs into Microsoft 365 or Google Workspace with stolen credentials never touches an endpoint you manage. A phishing email that harvests a password through a fake login page leaves nothing on the laptop. Personal phones, unmanaged contractor devices, network equipment and many SaaS applications carry no agent at all.
There is also a coverage problem that has nothing to do with attackers. Agents get uninstalled, fail to update, or never get deployed on the server someone built last month. An EDR console that shows 180 healthy devices tells you nothing about the twenty that should be there and are not. Comparing agent coverage against the asset inventory is one of the first things worth checking, and one of the first things an auditor asks about.
What XDR adds
XDR stands for extended detection and response. It takes the EDR model and applies it across more sources: email, identity, network, cloud workloads and SaaS applications, alongside endpoints.
Correlation across sources
The value of XDR is correlation. Each source on its own produces alerts that look minor. A user logs in from an unusual country. The same account creates a mail forwarding rule. An hour later, a laptop belonging to a colleague opens an attachment from that mailbox and launches a script. Separately, each event might be ignored. Joined into one incident, they describe an account takeover spreading inside the company.
XDR platforms also extend response actions beyond the device: disabling a user account, revoking active sessions, deleting a malicious email from every mailbox that received it, or blocking a domain. That breadth is what lets a responder contain an attack that crosses from identity to email to endpoint.
Native and open XDR
Products fall broadly into two families. Native XDR comes from a single vendor and correlates that vendor's own endpoint, email, identity and cloud sensors, which makes integration easier but ties you to one ecosystem. Open XDR ingests data from tools made by different vendors, which suits companies that already run a mixed stack but needs more work to tune.
Neither is better in the abstract. The right choice depends on what you already run, and on who will maintain the integrations and detection rules over time.
Where a SIEM fits
A SIEM (security information and event management) collects and stores logs from almost any source, normalises them, runs correlation rules and keeps the records for investigation and compliance. XDR and SIEM overlap, which is why vendors increasingly blur them, but their centre of gravity differs.
XDR is built around detection and fast response on the sources it integrates deeply. A SIEM is built around breadth and retention: firewall logs, application logs, database access, cloud audit trails, custom systems, kept for months and searchable. Many organisations run both. XDR handles detection and response on endpoints, email and identity, and the SIEM holds the wider record that audits, investigations and incident notifications depend on.
What MDR is
MDR stands for managed detection and response. It is not a product category in the same sense as EDR or XDR. It is a service: a team of analysts that operates detection technology on your behalf, watches the alerts, investigates them and acts.
Triage, investigation, containment and reporting
An MDR provider receives the alerts your tools generate, a volume that grows quickly once identity, email and cloud sources are connected as well as endpoints. Analysts triage them to separate false positives from real activity, and investigate the ones that matter using the telemetry. They then take the agreed response actions: isolating a device, disabling an account, blocking an address. Afterwards they report what happened, what they did and what you still need to fix.
Some providers bring their own technology stack; others operate the tools you already own. Both models work. What changes is who controls the configuration and who you depend on if you change provider.
What to ask a provider
The contract defines what MDR means in practice, so read it closely. The questions that separate one offer from another are concrete:
- Coverage hours. Is the service staffed around the clock, during business hours, or with an on call engineer outside them?
- Response authority. Which response actions can analysts take without asking you first, and which need your approval?
- Escalation. How quickly will a confirmed incident reach a named person in your company, and through which channel?
- Reporting. What do you receive monthly, and can it be used as audit evidence?
- Sources. Which data sources are included in the price, and which cost extra?
Two offers can both be sold as MDR and still be very different services. One monitors endpoints only, during office hours, with no authority to isolate a device. The other covers identity and email around the clock and contains an incident at three in the morning.
The alert nobody reads
The most common failure in small and medium companies is not a missing tool. It is a tool that works, generates the right alert, and sends it somewhere nobody is watching.
A typical sequence looks like this:
- On a Friday evening, the EDR flags a credential dumping tool on a finance laptop. It isolates nothing, because automatic isolation was switched off after it once disconnected the managing director during a meeting.
- The alert goes to a shared mailbox.
- Over the weekend, the attacker uses the stolen credentials to log into email, creates a forwarding rule and sends invoices with altered bank details to three customers.
- On Monday morning, someone opens the shared mailbox, finds forty alerts and starts at the newest.
Every component in that story was present. The EDR detected correctly. The logs existed. What was missing was a person whose job was to read the alert within minutes, connect it to the identity activity and disable the account. That is the gap MDR exists to close, and it is the gap an auditor probes when asking who reviews alerts and how quickly.
The illustration is not an argument for any specific product. It is an argument for deciding explicitly who responds, on which hours, with what authority, and for writing that decision down. If the answer is an internal person, the plan has to cover holidays, sick leave and nights. If the answer is a provider, the contract has to say so. The SOC and monitoring topic page collects our other articles on running detection and response.
What ISO 27001 and the ENS expect
Neither framework names EDR, XDR or MDR. Both describe outcomes that these tools and services help you meet, and both expect evidence that the outcome is achieved in operation, not only on paper.
ISO 27001
ISO 27001 Annex A includes several controls that monitoring addresses directly:
- Control 8.7 requires protection against malware.
- Control 8.15 requires logs that record activities, exceptions, faults and other relevant events to be produced, stored, protected and analysed.
- Control 8.16 requires networks, systems and applications to be monitored for anomalous behaviour, with appropriate action taken to evaluate potential incidents.
- Controls 5.25 and 5.26 require security events to be assessed and incidents to be responded to according to documented procedures.
An EDR on its own covers much of 8.7 and part of 8.16. The rest depends on what happens after an alert: who assesses it, how the decision is recorded and how the response is carried out. That is where many certified companies are weakest, because the procedure exists as a document while the alerts pile up unread.
The ENS
The ENS, regulated by Real Decreto 311/2022, is more specific. Article 10 makes continuous vigilance a basic principle, to detect anomalous activity and respond in time. Annex II then sets the measures:
- op.exp.6 requires protection against malicious code on all equipment (user workstations, servers and perimeter devices), and adds regular scanning of the whole system from MEDIA category.
- op.mon.1 requires intrusion detection or prevention tools at every category, with reinforcements for MEDIA and HIGH.
Measure op.mon.3, vigilance, is where the categories diverge most:
- At every category, it requires an automatic system that collects security events.
- At MEDIA, it adds event correlation and solutions to determine the exposure surface to vulnerabilities and configuration weaknesses.
- At HIGH, it adds, among other reinforcements, systems to detect advanced threats and anomalous behaviour.
In practice, a MEDIA system needs something that correlates events from several sources, which is the job of a SIEM or an XDR platform, not of an endpoint agent alone. The CCN publishes a mapping between ISO 27001 and the ENS that links control 8.7 to op.exp.6.
The evidence an auditor asks to see
Auditors in both frameworks ask for similar things:
- a list of devices with the agent installed, reconciled against the asset inventory;
- the configuration of detection and automatic response;
- a sample of alerts with the time each was reviewed and the decision taken;
- the incident register linking alerts to incidents and actions;
- log retention settings and proof that logs are protected from tampering;
- reports from the MDR provider, if there is one.
The question underneath all of these is whether the monitoring described in the policies actually happens. Our article on what a certification audit actually tests explains why a documented control and an operated control are judged differently. For the ENS in particular, these measures have to keep running between audits; keeping ENS certification valid covers what the auditor reviews from the two years in between.
Choosing the right layer for your size
There is no correct combination for every company. Four questions usually settle it.
How many endpoints, and what kind? A company with forty laptops and everything else in SaaS needs strong identity and email coverage more than a large server estate. A company running its own servers and production infrastructure needs EDR on those servers as much as on laptops. Device management matters here too, since an agent can only be deployed and kept healthy on devices you manage. Our article on what MDM lets a company see covers that layer.
How much of the business runs in the cloud and in SaaS? The more critical activity happens in Microsoft 365, Google Workspace, AWS, Azure or business applications, the more an endpoint only approach leaves uncovered. It is also where correlation across identity, email and cloud adds the most value.
Who will triage the alerts? This is usually the deciding question. A company with no security team, or with one person who also runs IT, cannot read alerts around the clock. Buying a more capable XDR platform without someone to operate it increases the number of alerts nobody reads.
What do your frameworks require? An ENS system at MEDIA category needs event correlation, which points to a SIEM or XDR layer. ISO 27001 leaves the method open but expects monitoring for anomalous behaviour and documented response. Customer security questionnaires can also ask directly whether endpoints have EDR and whether alerts are monitored continuously, and the honest answer needs to match what the contract or the team actually provides.
How Qalea combines them
Qalea treats monitoring as one layer that sits under the whole security programme rather than as a separate purchase. EDR runs on employee devices, a SIEM collects and correlates security events, and a SOC reviews the alerts and responds.
Because monitoring and compliance run together in Qalea, the output of that layer is the evidence the related controls need: agent coverage against the device inventory, reviewed alerts, the incident register and monitoring records for controls such as ISO 27001 8.16 and ENS op.mon.3. The point is the one this article started with. Detection technology is necessary, but what an auditor, a customer or an attacker tests is whether someone acts on it. A compliance platform without operated security cannot answer that question.
