What Is XDR? Extended Detection and Response Explained

The endpoint domain is the anchor and the one every platform has. An agent records behavior on workstations and servers and supports response actions taken remotely: isolate the host from the network, terminate a process, quarantine a file, collect a forensic package. Identity is usually the second domain, ingesting authentication events, privilege changes, token issuance and conditional-access decisions from the directory or identity provider — the source that turns a suspicious endpoint event into a question about whose account was used.

Email is the third common domain, because mail remains the ordinary delivery mechanism for the first stage of an intrusion, and because a platform that can see both the message and the endpoint that opened it can trace one to the other without an analyst exporting headers by hand. Cloud and SaaS telemetry covers control-plane activity, workload behavior and application audit logs; network telemetry covers flow records, DNS resolution and, where a sensor is deployed, traffic inspection. Some platforms add data-loss and mobile signals.

Two distinctions are worth insisting on during an evaluation. Ingesting a domain is not the same as detecting across it — a platform can accept identity logs and still run only endpoint-derived detections, in which case the identity data is context on a case rather than a source of one. And responding in a domain is not the same as seeing it: a platform may correlate mail evidence into a case yet be unable to pull the message from other mailboxes, which is precisely the action the case exists to justify. Ask for the list of automated response actions per domain, not the list of supported log sources.

Without correlation, an analyst works a queue of alerts, each carrying the perspective of the tool that raised it, and reconstructs the sequence manually by pivoting between consoles on shared indicators — a username, a hostname, a hash, an address, a timestamp range. That reconstruction is the expensive part of triage, it depends on the analyst's familiarity with every console involved, and it is where investigations quietly stop when the queue is long. Correlation moves that work into the platform: related signals are grouped into one case, ordered on a timeline, and scored once rather than five times.

The measurable effect is usually on volume rather than on detection. Ten alerts that were ten triage decisions become one case that is one decision with more evidence behind it, which is why organizations that adopt XDR often report the queue shrinking faster than the detection count rises. The risk that comes with that is a grouping error: a case that merges two unrelated events reads as one story, and a case that splits one incident into three loses the connection the platform existed to draw. Both happen, both are tunable, and neither is visible unless someone reviews closed cases periodically.

Detection engineering does not disappear either. Vendor-supplied correlation covers common patterns well and environment-specific ones not at all, so mature teams still write and tune their own logic, map coverage against a framework such as MITRE ATT&CK to see which techniques have no detection behind them, and retest that the rules still fire after platform updates. CISA's Zero Trust Maturity Model treats visibility and analytics as a capability that cuts across every pillar rather than as a product feature, which is a fair description of the work involved.

Native XDR is a single vendor's platform correlating that vendor's own sensors. The integrations are built and maintained by the party that owns both ends, so they tend to work well and stay working through updates, and the detection logic can rely on telemetry it knows the shape of. The cost is coupling: the value case assumes you run that vendor's endpoint, identity or mail products, and changing one of them later reduces the correlation you paid for.

Open XDR — sometimes called hybrid XDR — ingests third-party telemetry and correlates across products you already own. It preserves choice and makes the platform useful in mixed estates, which is most estates. The cost is integration effort and fragility: each connector is a mapping between one vendor's event schema and another's, and schema changes upstream are a maintenance obligation somebody has to hold. Neither model is better in the abstract; the question is whether your estate is already consolidated or deliberately is not.

The connector list is where evaluations should slow down. For each domain, establish three things in writing: whether the connector is included in the quoted tier or costs extra, whether the source product's own license tier exposes the API the connector needs — a frequent and expensive surprise on identity and mail platforms — and what happens to correlation quality when a connector is unavailable. A platform that degrades to endpoint-only detection when the identity connector breaks is behaving reasonably, but you want to know that before it happens rather than during an incident.

A SIEM aggregates and retains log data from anything that produces it, correlates against rules the team writes, and serves as the audit record. Its defining property is breadth and retention — it will take the application logs, the infrastructure logs and the systems no security platform has a connector for, and hold them for as long as an audit or records obligation requires. XDR curates instead: it keeps a narrower set of high-value telemetry for as long as its detection logic needs it, and it arrives with detections already written. Overlap in the detection layer is real; overlap in the retention and reporting layer largely is not.

SOAR is the automation tier that sits downstream of detection, executing response playbooks across the tools an organization runs. Most XDR platforms include a subset of that automation inside their own domains — isolate this host, revoke these sessions, pull that message — and a dedicated SOAR earns its place when playbooks need to reach systems the XDR has no authority over, such as ticketing, network access control or infrastructure. CISA and international partners published joint SIEM and SOAR implementation guidance in 2025 that is worth reading before assuming one product replaces the other.

MDR is not a product tier at all. Managed detection and response is a service: people who operate detection tooling on your behalf, triage what it produces, and either respond within an agreed authority or escalate to you. It is orthogonal to the XDR question — a provider will usually run some platform underneath, sometimes yours — and the thing that decides whether you need it is staffing rather than technology. Correlation reduces the number of decisions a queue produces; it does not produce anyone to make them at three in the morning.

The endpoint agent is the part with a hardware bill attached. It consumes CPU, memory and disk on every machine it runs on, and the cost is felt most on older workstations near the end of their refresh cycle and on servers already sized to their limits. A rollout across a fleet at the bottom of its lifecycle reliably turns into a performance complaint, which is why the agent's stated requirements belong in the refresh plan rather than in the security project alone. Where a machine is too constrained to carry an agent, that machine is outside the platform's coverage and should be recorded as such.

Network telemetry, where it is in scope, needs a clean feed rather than a software install — a network TAP or a mirror port into a sensor, sized so the sensor is not silently dropping frames. Cloud and identity telemetry needs API access at the right license tier and, frequently, a service principal with permissions somebody has to approve. Telemetry retention consumes storage on the platform side, your side or both depending on the model, and the retention period that satisfies the detection logic is usually far shorter than the one that satisfies an audit obligation, which is the practical argument for keeping a log platform alongside.

The requirement most often left out of the plan is the one that determines whether any of it works: somebody has to operate it. Cases have to be worked, detections tuned, connectors monitored, and coverage gaps reviewed. An unread case queue is not an improvement over an unread alert queue, and the honest options when no rota exists are a managed service or a narrower scope — not a broader platform.

The evaluation that works is a paper exercise you can run before any demonstration. List the telemetry domains you actually have — endpoint, identity, mail, each cloud account, each SaaS platform of consequence, network sensors — and mark the ones a given platform will ingest under the tier being quoted, with the extra licensing each one requires noted next to it. That marked list is the value case. If most domains are marked, the correlation will visibly shorten investigations; if two are, you are buying endpoint detection and response with a broader label, which may still be the right purchase but should be described accurately in the evaluation.

Then test three properties that separate platforms more reliably than feature grids do. Coverage: map the supplied detections against a public technique framework and look at what is missing rather than at what is present. Authority: list the automated response actions available per domain, because a case you cannot act on is a report. Exportability: establish how you get your telemetry and case history out — in what format, at what cost, over what period — because that is the constraint that decides whether a future change of platform is a project or a hostage negotiation.

For regulated buyers, the framing that survives contact with an auditor is control language rather than product language. NIST SP 800-53's System and Information Integrity controls cover system monitoring, and its Incident Response family covers handling and reporting; a requirement written against those controls describes the capability the organization must have and leaves the market free to answer it. Writing an acronym into a requirement instead tends to produce a compliant purchase and an uncovered gap. Uniqcli quotes endpoint hardware, servers, network sensors and the security software licensing that runs on them through authorized US distribution — send the domain list and the endpoint count with the request and the quote will reflect the deployment rather than a guess at it.