BUYER BRIEF  ·  VENDOR-NEUTRAL  ·  UPDATED 2026-04-27
DefinitionLast verified April 2026

What is XDR? Extended detection and response, defined neutrally.

XDR is a unified detection-and-response platform that ingests telemetry from multiple security layers, correlates alerts into incidents, and supports analyst-led or automated response. Here is what that means in plain terms, and why each design choice has a pricing consequence.

Extended detection and response, abbreviated XDR, is a security category that emerged as the response to two problems that modern security operations teams could not solve with the previous generation of tooling. The first problem was tool sprawl. A mid-size security team commonly operated a dedicated endpoint detection and response product for devices, a separate email security gateway, a separate identity threat detection tool, a separate cloud workload protection platform, a separate network detection and response sensor, and often a separate security information and event management platform tying some portion of them loosely together. Each tool generated alerts in its own console with its own analyst workflow. Context-switching dominated the analyst day.

The second problem was correlation. Sophisticated attacks cross layers by design. A phishing email delivers a payload, the payload compromises a workstation, the workstation steals credentials, the credentials are used to pivot to a cloud workload. Each individual step may look benign in isolation. Only the chain across email, endpoint, identity, and cloud tells the story. Single-source tools could not see the chain because they did not share a telemetry substrate.

XDR is the category that solves both problems by unifying telemetry from multiple security layers into one substrate, correlating events across layers in a single detection engine, and exposing response actions from the same console regardless of which layer the action targets.

The six telemetry sources

An XDR platform ingests from six telemetry sources. Not every platform covers all six natively; coverage is what distinguishes a mature XDR from an EDR vendor that has relabelled its product.

  1. 01
    Endpoint

    Process execution, file writes, registry changes, network connections, memory behaviour, and user actions on workstations, servers, and mobile devices. This is what EDR has always collected. Every XDR platform covers this natively because endpoint telemetry is the common denominator.

  2. 02
    Network

    Flow records, packet captures, proxy logs, DNS queries, and east-west traffic between cloud workloads. Network telemetry catches lateral movement that endpoint tools miss on unmanaged devices and is the only reliable source for threats that execute entirely in memory.

  3. 03
    Email

    Message metadata, attachments, URLs, authentication headers, and recipient behaviour. Email is still the most common initial access vector. Platforms that cover email telemetry can correlate a phishing campaign to a subsequent endpoint compromise as a single incident.

  4. 04
    Identity

    Authentication events, token issuance, session management, multi-factor prompts, group membership changes, and privilege escalation. Identity is the control plane for cloud environments; identity telemetry is the difference between seeing a compromised credential reused and missing it entirely.

  5. 05
    Cloud workload

    Virtual machine, container, serverless function, and managed-database activity. Cloud workloads often generate high-cardinality audit logs that explode data volumes. The pricing consequence is that cloud-heavy environments push XDR into per-workload or per-GB territory quickly.

  6. 06
    Application

    SaaS application logs, API gateway logs, and application-layer audit trails. Coverage here is uneven across XDR platforms and is commonly where open XDR architectures earn their premium. Native platforms usually cover a limited set of SaaS sources; open platforms ingest whatever your environment already runs.

How XDR differs from the adjacent categories

EDR

Endpoint detection and response is the endpoint-only predecessor category. Every modern XDR platform contains EDR functionality as its endpoint telemetry source. EDR pricing is typically per endpoint per month in the three to fifteen dollar range. XDR pricing layers cross-layer telemetry on top and commonly runs six to eighteen dollars per endpoint per month for the base licence. See edrcost.com for the dedicated EDR pricing framework.

SIEM

Security information and event management is the log-aggregation category. SIEM collects logs from every source in the environment, stores them for compliance-driven retention, and runs custom correlation rules. SIEM is priced primarily on data volume; many mid-market organisations pay more for SIEM than for any other security tool. XDR overlaps with SIEM on detection and response but generally does not cover the compliance retention workload without significant overage. See XDR vs SIEM for the full comparison.

MDR

Managed detection and response is a service, not a platform. An MDR provider monitors your telemetry on your behalf, investigates incidents, and often takes response actions directly. MDR is commonly delivered on top of an XDR platform, either the customer’s or the provider’s. MDR is priced as a per-endpoint or per-user service fee of typically fifteen to thirty-five dollars per endpoint per month, on top of the platform licence if the platform is customer-owned. See mdrcost.com and XDR vs MDR.

SOAR

Security orchestration, automation, and response is the playbook-execution category. SOAR automates repetitive analyst workflows across multiple tools. Modern XDR platforms embed SOAR-style automation natively; standalone SOAR tools persist in large enterprises with custom workflow requirements that exceed XDR automation capabilities.

Native XDR vs open XDR

Native XDR is a single vendor’s end-to-end stack. The endpoint agent, email gateway, identity protection product, and cloud workload protection come from one company and share a telemetry substrate out of the box. Native architectures integrate faster but carry a vendor-lock premium on renewal and rarely accommodate third- party tools on equal footing.

Open XDR is a platform designed to ingest telemetry from whatever tools the customer already operates. The platform owns detection and response; third parties own the sensors. Open architectures preserve procurement leverage and avoid rip-and-replace, but they cost more to stand up because each integration requires configuration and ongoing maintenance.

Most platforms now sit on a spectrum rather than a binary. A native vendor may accept third-party telemetry at a per-GB rate; an open platform may ship with recommended sensor bundles. The open vs native comparison page works through the cost implications of each architecture in full.

Why XDR exists as a category

The commercial reason XDR exists is that the industry could not sustain the alert volume that independent point tools generated. Published analyst-day studies consistently report that security operations teams dismissed the majority of incoming alerts as noise and that genuine incidents were missed in the volume. The business case for XDR is that cross-layer correlation reduces alert volume to genuine incidents by one to two orders of magnitude.

The technical reason is that attacker tooling crossed layers faster than defender tooling. Adversaries routinely combined a phishing payload, a living-off-the-land endpoint technique, a credential theft, and a cloud pivot in a single campaign. Defenders needed a substrate that saw the whole sequence. XDR is that substrate.

The pricing consequence of each design choice

The definition matters for cost because each telemetry source adds a pricing axis. A platform that covers endpoints charges per endpoint. A platform that covers email and identity charges per user, because users are the unit of email and identity licensing. A platform that covers cloud workloads charges per workload or per GB of cloud-audit telemetry. A platform that ingests third-party logs at volume charges per GB of ingest.

A buyer evaluating three XDR platforms often finds that one leads with per-endpoint, another leads with per- user, and a third leads with a bundled per-GB model. The quotes look different on the page but price out the same environment at radically different totals. Normalising the quotes onto a common axis is the core buyer skill; the pricing-models page walks through the normalisation worked example in detail.

This is the bridge from definition to framework. Understanding what XDR is means understanding why there is never a simple list price. The platform covers multiple axes; the quote reflects multiple axes; the total you pay depends on which axes dominate your environment. The rest of this site is built on that bridge.

// Q&A appendix

Frequently asked questions

01.What does XDR stand for?+
XDR stands for extended detection and response. The name signals that the platform extends the endpoint detection and response category beyond endpoints, ingesting telemetry from email, identity, cloud workloads, network, and applications. The detection and response verbs are deliberate: the platform correlates telemetry into detections and supports response actions natively, rather than stopping at an alert that needs a separate tool to act on.
02.How does XDR actually work?+
An XDR platform collects security telemetry from multiple layers, normalises it into a common schema, runs detection logic across layers to correlate related events into a single incident, and offers response actions directly from the incident view. The correlation step is the core technical differentiator. Single-source tools see individual events; XDR sees the attack chain across endpoints, email, and identity as one incident. Response actions range from isolating an endpoint to revoking a session to blocking a sender, depending on which telemetry sources the platform owns.
03.Is XDR a product or a category?+
XDR is a product category containing two subcategories that behave differently commercially. Native XDR is a single vendor's stack with first-party telemetry from their endpoint, email, identity, and cloud-workload products. Open XDR is a platform that ingests telemetry from third-party tools via APIs. Native is faster to stand up and more integrated; open preserves procurement leverage and avoids full vendor lock-in. The distinction matters for pricing: native is usually per-endpoint and per-user; open is often per-data-volume or per-integration.
04.Does XDR replace EDR, MDR, or SIEM?+
XDR replaces endpoint detection and response because it includes EDR as one of its telemetry sources. XDR does not replace MDR because MDR is a managed service layered on top of a platform; many MDR providers operate on an XDR platform on the customer's behalf. XDR can replace a SIEM for detection and response workloads but typically cannot replace a SIEM for compliance-driven long-term log retention without material ingest and retention overage. The relationships depend on your regulatory environment and your existing tooling.