XDR
In detection and response, XDR is extended detection and response: a platform that correlates signals across endpoint, email, identity, network and cloud into one view, so that a sequence of individually unremarkable events can be recognised as a single intrusion. The word that carries the meaning is correlation, not collection.
How it works
Telemetry from several domains is normalised into a common schema and joined on shared entities: a user, a device, a process, a session, a file. Detection logic then runs across the joined data rather than within one source, and related alerts are grouped into a single case with a reconstructed sequence, which is what saves analyst time.
The distinction from its neighbours is worth stating precisely. EDR is deep telemetry and response on the endpoint. A SIEM ingests anything that emits a log and is as good as the content written for it. XDR is narrower and more opinionated: a fixed set of sources the vendor understands, with correlation supplied rather than written. MDR is not a technology at all, it is a service that operates one of the above.
What goes wrong
The label is a marketing category before it is a product category, and the practical question is always which sources are genuinely correlated. A platform that correlates its own endpoint agent with its own mail product, and treats a third-party identity provider as a log to store rather than an entity to join on, is providing an integrated console rather than cross-domain detection. Identity is the source that most often turns out to be second class, and it is the one that matters most against an attacker who signs in rather than breaks in.
The second effect is lock-in by telemetry. Correlation quality depends on the vendor’s own sensors, so the platform is strongest exactly where it displaces other tools, and coverage falls off outside that footprint. That is not a scandal, it is the design, but it should be measured rather than assumed: what does it see when the intrusion runs entirely through signed system binaries and a stolen session.
Where this shows up in an audit
We test the claim by walking an attack across domains on purpose: a phishing-derived session in the identity platform, an action in the mail platform, then activity on an endpoint, and we check whether the platform joined them into one case or raised three unrelated low-priority alerts. The finding is the join that did not happen, with the timestamps that show it, which is a far more useful deliverable than a coverage percentage from a datasheet.