XDR, extended detection and response, maturity runs from collecting telemetry from a few sources, through correlating it, to automating response across endpoints, identity, email, cloud and network. Most teams sit at level one or two. The useful question is which single capability you add next.
What does "maturity" mean here?
There is no standard XDR maturity scale. NIST's glossary lists XDR only by pointing to its source publication, which tells you the term is used loosely. The model below is our own working scale, built from how detection and response programs usually grow. Treat it as a planning aid, not an audit framework.
Borrowing the idea from CISA's Zero Trust Maturity Model helps. That model describes traditional, initial, advanced and optimal stages for each pillar, so a team can be at different stages in different areas. Do the same here: score each source and each function separately.
Level 1: Collected
Telemetry flows from endpoints and perhaps one other source into a console. Alerts come from vendor rules. Analysts triage one console at a time.
Signs you are here: alerts are read, but cross source questions ("did this login lead to that file change?") take a manual hunt across tools.
Measure: the share of your critical systems sending telemetry, and the time an analyst spends pivoting between consoles on a typical alert.
Level 2: Correlated
Two or more sources, usually endpoint plus identity or email, are joined into one incident. A single story replaces five alerts.
Signs: analysts open incidents, not alerts. Duplicate alerts collapse. Each incident lists affected users and hosts.
Measure: alerts per incident, and the proportion of incidents that span more than one source. If everything is still single source, you have a bundle, not a correlated view.
Level 3: Contextual
Detections use context you own: asset criticality, user role, known change windows and, for software teams, what is deployed where. MITRE ATT&CK, a knowledge base of adversary tactics and techniques based on real world observations, becomes the map for coverage. You know which techniques you can see and which you cannot.
Signs: you can name coverage gaps by technique, and tuning decisions are written down, not tribal.
Measure: coverage against the techniques you care about, false positive rate per rule, and the number of rules retired or tuned this quarter.
Level 4: Orchestrated
Response actions run across sources with guardrails: isolate a host, disable a session, revoke a token, open a ticket. Low risk actions run automatically. High impact ones need an approver. Every action leaves a record.
Signs: playbooks exist, are tested on a schedule and have an owner. A person can undo an automated action.
Measure: share of incidents closed by an approved playbook, time from detection to containment for those, and the count of automated actions that were later reversed. A reversal rate near zero can mean good tuning or that nobody checks.
Where do teams get stuck?
Three places come up repeatedly.
Telemetry before questions. Teams switch on every source and drown. Pick the three incident types you fear most and connect only what you need to detect them.
Automation before trust. A playbook that isolates a laptop is fine. A playbook that disables an executive's account on a weak signal is a self inflicted outage. Earn the right to automate by running in recommend mode first.
Ownership gaps. Endpoint, identity and cloud teams each own a slice. Correlation needs a single owner for the incident, even if the data is shared.
What about the software you build?
XDR sees runtime behaviour. It does not tell you that a library in your release carries a known flaw, or that a build pipeline holds a broad token. Those live earlier, in the software supply chain, and need their own controls. A mature program joins both: runtime detection tells you what is happening, supply chain data tells you what is in the thing that is running.
What to do
- Score each data source and each response action on the four levels, not the whole program at once.
- Choose three incident types and list the telemetry needed to detect them.
- Move one source up one level per quarter, instead of adding five sources at level one.
- Map current detections to ATT&CK techniques and list the gaps.
- Run every new automation in recommend mode, then approve, then automate.
- Review reversal and false positive numbers monthly.
Safeguard focuses on the application and software supply chain side and does not replace an XDR platform.
Quick check
Is there an official XDR maturity model?
Not that we could confirm. The levels here are a planning scale based on common practice. Check any vendor claim of a standard scale against its source.
Should we automate response early?
Only for low risk, reversible actions, and only after a period in recommend mode. Keep an approver for anything that can interrupt the business.
Sources
Last reviewed: 18 October 2026.
