XDR, or Extended Detection and Response, is a security approach that collects telemetry from across an estate — endpoints, identities, email, cloud workloads and network — and correlates it centrally, so that related events arrive as one incident rather than as separate alerts in separate consoles.
The definition is easy. The reason the category exists is more useful, because it explains what XDR is actually for and where it stops being enough.
Why the category exists
XDR is a response to two things that did not work.
The first was endpoint detection on its own. EDR is good at what happens on a device, and blind to everything that does not. An attacker who phishes a credential, signs in legitimately, and reads a mailbox never touches an endpoint sensor in a way that looks wrong. The detection is sound and the attack is invisible to it.
The second was the SIEM as the only place signals met. A SIEM can see everything, in principle, but someone has to send it the data, write the correlation, and pay for the ingestion. In practice the data that got connected was the data somebody had time to connect, which meant the correlation reflected the team's capacity rather than the attack surface.
XDR sits between the two. It takes the native integration a single vendor can build across its own products and makes correlation a property of the platform rather than a project.
What XDR actually does
Three mechanisms do most of the work.
It normalises telemetry across domains
Signals from endpoints, identity providers, mail flow, cloud workloads and SaaS applications arrive in different shapes. XDR resolves them against a shared model — the same user, the same device, the same session — so that activity in one domain can be matched to activity in another without a human writing the join.
It groups alerts into incidents
This is the change analysts notice. Rather than forty alerts across five consoles, XDR produces one incident with a timeline: the sign-in that started it, the device it reached, the mailbox rule that followed, the data that moved. The alerts still exist underneath. What changes is that the relationship between them is asserted by the platform rather than reconstructed by a person at two in the morning.
It carries response across the same boundaries
Because the platform already understands that an identity and an endpoint belong to the same incident, it can act on both — isolate the device, disable the account, quarantine the message, block the indicator — from one place, with one audit trail.
XDR, EDR, SIEM and MDR
These get used interchangeably and they are not interchangeable. Two are technologies and two describe who operates them.
- EDR is a technology scoped to endpoints. It is a component of XDR, not a competitor to it.
- SIEM is a technology for collecting and querying log data from anything, including sources no XDR will ever natively support. It is broader than XDR and less opinionated, which is both its strength and its cost.
- XDR is a technology that correlates across a defined set of domains, with the integration already built.
- MDR describes a service: somebody else runs detection and response for you. What they run it on varies.
The common mistake is reading XDR and SIEM as alternatives. Most mature operations run both, because they answer different questions. XDR answers "what is happening across my estate right now, and are these things related". A SIEM answers "what happened across everything I have ever logged, including the systems that will never have a connector".
Native and open XDR
There is a real architectural split worth understanding before buying.
Native XDR correlates products from a single vendor. The integration is deep because the vendor controls both ends, the data models already agree, and there is nothing to maintain. The constraint is obvious: it sees what that vendor's products see.
Open XDR correlates across vendors through connectors and APIs. It covers more of a mixed estate, and the integration is now something somebody owns, tests and repairs when a schema changes.
Neither is better in the abstract. The question is how much of your security-relevant activity already happens inside one vendor's products. For an organisation running Microsoft 365, Entra ID and Defender, the native path covers most of the attack surface that matters and the open path is solving a problem that estate does not have. For a genuinely mixed environment, the reverse.
What XDR does not solve
This is the part most introductions leave out, and it is the part that determines whether a deployment works.
XDR produces better incidents, not fewer decisions. Correlation reduces alert count. It does not reduce the number of judgements a person has to make, and the judgements that remain are harder, because the easy alerts were the ones that got absorbed.
Detection content is not finished when the licence is bought. Default rules are written for everybody. Tuning them for one estate — what is normal here, which service account legitimately does that, which admin behaviour is expected on a Tuesday — is continuous work, not a deployment task. An untuned XDR produces confident correlation of irrelevant things.
It still needs somebody at three in the morning. XDR shortens the distance between signal and understanding. It does not answer the question of who is awake when the understanding arrives, which is the real constraint for most organisations and the reason the managed model exists at all.
Who XDR suits
XDR earns its place where attacks cross boundaries that separate tools cannot see across — which is most organisations with cloud identity, remote devices and email as a delivery route. It earns it fastest where a single vendor already covers the bulk of the estate, because the integration is free rather than built.
It earns it least where the security problem is not correlation. An organisation with one unpatched perimeter system and no asset inventory does not have a correlation problem, and XDR will correlate its way to the same answer a vulnerability scan would have given sooner.
The operating question
The decision XDR forces is not really which platform. It is who runs it.
The technology is now good enough that the differentiator between two organisations with the same licence is how well the detection content fits the estate, how quickly an incident reaches a person who can act, and whether that person is available when it arrives. All three are operating questions, and none of them is answered by procurement.
That is the problem managed XDR exists to solve, and it is a separate decision from choosing the platform itself.