SIEM, EDR, XDR and MDR: what the difference is in practice
None of these buys you detection. They buy telemetry, correlation and, in one case, people, and the outcome still depends on decisions your organisation has to make: what is worth alerting on, who may disconnect a production host at 3am, and who is accountable when something is missed. The category names are also unstable, particularly XDR, which in practice means whatever a given vendor has integrated. Buy on data coverage and defined responsibility, not on the acronym.
What does each category actually do?
They divide along two axes: what telemetry they see, and whether a human is included. The confusion in the market comes from treating them as an upgrade path, when in reality most estates end up with an endpoint product, some form of log platform, and a decision about who watches both.
| Category | What it sees | What it does | What it does not give you | Who operates it |
|---|---|---|---|---|
| SIEM | Anything you send it, including identity, cloud, network and application logs | Stores, normalises, correlates across sources and alerts on rules you configure | Endpoint depth, and any response action on its own | You, and it is a continuing engineering job |
| EDR | Process, file, registry and network activity on managed endpoints and servers | Detects behaviour and can isolate a host, kill a process, collect artefacts | Anything happening in identity, mail or cloud where no endpoint is involved | You, though most vendors offer a managed tier |
| NDR | Network flows and, where decrypted, traffic content | Detects lateral movement and egress patterns, including on unmanaged devices | User and process attribution without correlation to other sources | You, and it needs tuning per network segment |
| XDR | The telemetry of one vendor's own products, correlated together | Cross-signal detections and coordinated response inside that estate | Coverage of anything the vendor does not sell you a sensor for | You, with markedly less integration work |
| MDR | Whatever sources the contract covers, commonly the provider's chosen stack | Triage and, depending on the contract, containment actions on your behalf | Ownership of the decision, the asset knowledge, and your reporting duties | The provider, within defined and negotiable limits |
Do you need a SIEM if you already have EDR?
You need somewhere to detect the attacks that never touch an endpoint, and whether that is a SIEM or something smaller depends on your estate. Business email compromise, consent phishing against a cloud identity, session token theft, stolen API keys used against a cloud control plane, and abuse of a SaaS integration all proceed without a single suspicious process on a laptop. An endpoint product cannot see them because it is not present where they happen.
That is the case for a log platform stated precisely, and it is a different case from the one usually made, which is compliance. If a log platform exists only to satisfy a retention requirement and nobody writes detections against it, it is an archive with a search bar, and it should be priced as one rather than as detection capability.
The test to apply is a scenario walkthrough. Write down your three most plausible incidents, then ask which product would have produced the first signal. If the answer for two of them is neither, the gap is telemetry rather than tooling, and buying a bigger platform without adding those sources changes nothing.
The other reason a log platform earns its place is scope reconstruction after the fact. Endpoint products hold rich telemetry for a limited period defined by the vendor, and that window is frequently shorter than the interval between an intrusion starting and someone noticing. When the question is what happened three months ago, the answer comes from logs you chose to retain, and the choice was made long before the incident.
What is XDR actually solving?
The integration cost of correlating endpoint, identity, mail and cloud signals, which in a self-built stack is genuinely expensive and continuous work. When one vendor supplies all four sensors, correlation is built rather than configured, detections can reference several signals at once, and response can act across them. That is a real benefit and it is why the category exists.
The trade is coverage. The correlation quality applies to the vendor's own telemetry, and everything outside it either arrives as a thin connector or does not arrive at all. So the buying question is arithmetic rather than architectural: what proportion of your security-relevant sources does this vendor cover natively, and what happens to the rest. In a mixed estate with several clouds, a self-hosted platform and industry-specific applications, that proportion is often lower than the demonstration suggests.
Ask specifically how third-party data is treated. Some products ingest external sources but exclude them from the cross-signal detections that were the reason to buy, which means your non-vendor systems are stored rather than analysed. That distinction rarely appears in the datasheet and always appears in the first incident that starts outside the vendor's estate.
What does MDR responsibility actually cover?
Less than the word response implies, unless the contract says otherwise. The variable that matters most is whether the provider may take containment actions unilaterally, meaning isolate a host, disable an account or revoke sessions, or whether their obligation ends at notifying you. A notify-only service at 3am is a service that hands your unstaffed hours back to you, and it is frequently sold as twenty-four hour cover.
Get the specifics in writing before signing. Which actions may they take without asking, and against which asset classes. What is the contractual time to first human triage, as distinct from time to alert. Are forensic investigation hours included or sold separately as a retainer once an incident is confirmed. Do they write custom detections for your applications, and can you see the rule logic. What is the ingestion volume cap and the overage rate. And at exit, do you get your historical data in a usable form.
Ask also what they will not do, because a provider who answers that question crisply has thought about scope, and one who says they handle everything has not. Cloud control plane response, SaaS administrative actions and anything touching your identity provider are common gaps, and they are exactly where modern intrusions live.
Where do containers fit in these categories?
Awkwardly, and it is worth checking rather than assuming. An endpoint agent installed on a node may see container processes with no idea which workload they belong to, which produces alerts that name a random container ID and cannot be triaged. Kubernetes-aware detection needs the pod, namespace, image digest and service account attached to the event, and not every product does that.
The Kubernetes control plane is a separate question again. Audit events from the API server are among the highest value telemetry in a container estate, because privilege escalation, secret access and exec into production all appear there, and they are logs rather than endpoint telemetry. In many product combinations nobody is watching them, since the endpoint tool does not receive them and the log platform was never given the feed.
So the honest questions for any vendor in this space are narrow and specific: does your detection attach workload identity to container events, do you ingest and write detections against API server audit logs, and can you detect process drift inside a running container. Those three answers tell you more about container coverage than any amount of platform positioning.
How do you choose without a bake-off you cannot run?
Start from scenarios rather than features. List the six incidents that would genuinely hurt you, and for each write the telemetry required to notice it in the first hour. That list is short, it is specific to your architecture, and it converts a category decision into a coverage comparison that any two vendors can be asked to answer directly.
Then price the operating burden alongside the licence. A log platform with no detection engineering time attached will underperform a managed endpoint product with none, because rules do not maintain themselves. If nobody in the organisation will own tuning, that is not an argument for a cheaper tool, it is an argument for buying the people alongside the technology.
Finally, test the response path, not the detections. Ask each provider to describe exactly what happens between an alert firing at 3am on a Sunday and someone in your organisation being woken, including who calls whom and what they are permitted to do first. Vendors differ far more here than in detection quality, and this is the part you cannot evaluate from a dashboard.
Common questions
- What is the difference between EDR and XDR?
- EDR sees process, file and network activity on endpoints and servers where its agent is installed, and can respond on those hosts. XDR correlates endpoint telemetry with the same vendor's identity, mail, cloud and network sensors so detections can reference several signals at once. The benefit is integration work you no longer do. The limitation is that the correlation quality applies to that vendor's telemetry, and anything outside it may be stored without being analysed.
- Do you still need a SIEM if you have EDR?
- You need somewhere to detect attacks that never touch an endpoint, and that is the real question. Business email compromise, consent phishing, session token theft and stolen cloud API keys all proceed without a suspicious process on any managed device, so an endpoint product cannot see them. Whether that place is a full SIEM or something smaller depends on your estate, but a log platform nobody writes detections against is an archive, not detection.
- What does MDR actually include?
- It varies enough that the category name tells you almost nothing. The decisive term is whether the provider may take containment actions such as isolating a host, disabling an account or revoking sessions without waiting for you, or whether their duty ends at notification. Also confirm the contractual time to first human triage, whether forensic hours are included or retained separately, ingestion volume caps, visibility of rule logic, and what data you keep on exit.
- Is XDR a replacement for a SIEM?
- Only if the vendor natively covers most of your security-relevant sources. The useful measure is what proportion of your log-producing systems that vendor sells a sensor for, and what happens to the remainder. In a mixed estate with several clouds, self-hosted platforms and industry-specific applications, that proportion is often low, and third-party data is sometimes ingested but excluded from the cross-signal detections that were the reason to buy.
- How well do these tools cover containers and Kubernetes?
- Unevenly, so ask directly. A node agent may see container processes without knowing which workload they belong to, producing alerts identified only by a container ID that cannot be triaged. Kubernetes-aware detection attaches pod, namespace, image digest and service account to each event. Separately, API server audit logs are high-value telemetry that endpoint tools never receive, and in many product combinations nobody is watching them at all.
- How should you compare detection vendors?
- Write down the six incidents that would genuinely hurt you and, for each, the telemetry needed to notice it within an hour. Ask every vendor to answer against that list. Then ask each to describe exactly what happens between an alert firing at 3am on a Sunday and someone in your organisation being woken, including who acts first and what they may do. Vendors differ far more on that path than on detection quality.
