Glossary · Cybersecurity architecture XDR (Extended Detection and Response)
A security architecture that unifies telemetry across endpoints, networks, cloud workloads, identities, mobile devices, and email into a single detection and response platform. Extends EDR (endpoint-only) into a broader threat-graph view. XDR vendors hold the most sensitive operational telemetry any software category collects — making corporate jurisdiction structurally important.
## Where XDR fits
Extended Detection and Response (XDR) evolved out of Endpoint Detection and Response (EDR). Where EDR gave defenders deep visibility into individual endpoints — every process launch, file access, credential prompt, network connection — XDR extends that visibility across the entire attack surface and correlates signals across domains:
- **Endpoints** — Windows, Linux, macOS workstations, servers
- **Mobile devices** — iOS/Android threat defence (MTD)
- **Network traffic** — north-south and east-west traffic analysis (NTA)
- **Cloud workloads** — VMs, containers, Kubernetes, serverless
- **Identity signals** — Active Directory, Entra ID, Okta authentication events
- **Email** — phishing, business email compromise, malicious attachments
- **SaaS applications** — audit logs, permission changes, data-exfiltration signals
The value of XDR over separate best-of-breed products in each layer is correlation: a phishing email opened on a Windows endpoint that then executes PowerShell that then makes an anomalous DNS query is a coherent attack chain — visible to XDR, invisible to any single-layer tool.
## The unified single-agent architecture
Modern XDR platforms typically ship a single agent that carries all endpoint capabilities (EDR + MTD + host-based network sensing), coupled to cloud-side collectors for the non-endpoint layers (identity, email, network appliances, cloud workloads). This is meaningfully different from the historic SIEM model where a Security Information and Event Management system consolidated logs *after* other tools had already collected and processed them.
Leading vendors in the XDR category as of 2026:
- **CrowdStrike Falcon** — Delaware Nasdaq-listed (CRWD), Austin HQ. The most-deployed XDR globally.
- **Microsoft Defender XDR** — part of the broader Microsoft security stack; Delaware.
- **SentinelOne Singularity** — Delaware, Nasdaq (S).
- **Palo Alto Cortex XDR** — Delaware, Nasdaq (PANW).
- **Trend Micro Vision One** — Tokyo-listed, Japanese parent.
- **Sophos Intercept X** — private, UK-founded but US private equity-owned (Thoma Bravo).
- **Tehtris XDR** — France, private, EU-controlled. Self-described first European XDR.
## Why XDR is a sovereignty-critical category
XDR agents run with the highest privilege level any software category is granted. To detect kernel-mode rootkits, credential-theft techniques, and living-off-the-land attacks, the agent needs to see:
- Every process creation with full command-line arguments
- Every file access with content-hash correlation
- Every network connection with destination and payload metadata
- Every user authentication event
- Every credential access
- Every registry modification (Windows)
- Every syscall on Linux/macOS
- Every DNS resolution
The telemetry stream flowing from the agent to the XDR vendor's cloud is, effectively, a real-time audit trail of everything happening inside your organisation. It is the single most sensitive continuous data stream any vendor holds — richer even than what a SIEM has historically had access to.
## The jurisdictional consequence
Under CLOUD Act and FISA Section 702, US authorities can compel a US-incorporated XDR vendor to disclose that telemetry stream — without notifying the customer and without European court approval. For European organisations, this is materially different from other software categories:
- For a productivity SaaS, CLOUD Act reach exposes documents and messages.
- For an XDR platform, CLOUD Act reach exposes the full operational internals of the organisation itself.
The rise of **NIS2** essential-and-important-entity designations and **DORA** operational-resilience requirements for financial services in 2025-2026 has pushed European compliance officers to treat the XDR vendor jurisdiction question explicitly rather than implicitly. For NIS2 essential entities and DORA-covered financial institutions, "our XDR vendor is US-parent" is now a documented risk-register item — often with a required mitigation, timeline, and roadmap.
## European XDR options
Structurally EU-jurisdiction XDR vendors are a small set. **Tehtris** (France, Pessac SAS) is the largest and most-visible European XDR — unified EDR + MTD + NTA + SIEM + SOAR + honeypots + CTI + AI-driven detection, deployed across 100+ countries. Other emerging European players include **Nozomi Networks** (US-Swiss OT-focused), **HarfangLab** (France, EDR-focused), and **Sekoia.io** (France, XDR + SOC platform).
None yet match CrowdStrike's global scale or Falcon's ecosystem depth. But for European organisations where the sovereignty question is now non-optional, the incumbent-quality-vs-sovereignty trade-off is precisely the trade-off the procurement memo has to make explicit.
## Practical guidance for European buyers
1. Classify the sensitivity of what your XDR agents will see. A public-facing marketing site's endpoints look different from a defence contractor's engineering workstations.
2. Under NIS2/DORA/national CRITICAL-INFRASTRUCTURE directives, document the vendor jurisdiction question explicitly in your risk register — treating it as a known and accepted risk is legally different from ignoring it.
3. Pilot EU-headquartered XDR (Tehtris or similar) on a subset of estate before assuming migration is impossible. Vendor-lock-in on Falcon Complete or Microsoft Defender is real but not absolute.
4. Where migration is prohibitively expensive, at least segment: keep US-parent XDR on lower-sensitivity endpoints, use EU-parent XDR on the highest-sensitivity segments (defence, regulated data, executives, R&D).
Was this helpful?
Thanks for your feedback!