Correlation only happens across the products you actually hold a license for. Half a suite gives you half a picture.
This is the layer that joins endpoint, identity, email and cloud application signals into a single incident, disrupts attacks on its own and repairs what it can afterwards. The documentation says plainly that it correlates signals from the products you have licensed and provisioned, which is precisely why the value you get depends on your coverage rather than on how well anybody configured it.
- Eleven productsFeed the correlation layer
- One incidentInstead of alerts in separate consoles
- Auto disruptionContainment applied without a human
- 30 daysRaw signal available for hunting
Out of the eleven signal sources, how many do you genuinely hold?
Correlation happens across the products you have licensed and provisioned access to, and no further. That makes coverage rather than configuration the variable deciding what this is worth to you.
- Four come to mind for most people: Defender for Endpoint, Defender for Office 365, Defender for Identity and Defender for Cloud Apps. Most American businesses we assess hold one or two of those and correlate across exactly that much, which yields a fraction of the cross-domain picture they believe they are getting.
- The published list continues past those four with Defender Vulnerability Management, Defender for Cloud, Microsoft Entra ID Protection, Data Loss Prevention, App Governance, Purview Insider Risk Management and Microsoft Security Exposure Management. Several of them are routinely licensed already through an enterprise subscription and have simply never been switched on.
- Which means the first genuinely useful exercise is not configuring anything. It is establishing which of the eleven you already hold, which of those are provisioned, and which are licensed but sitting switched off. That third list runs longer than the security team expects almost every time.
- Attack disruption rests on the same foundation. That published example, where a malicious file found on an endpoint gets removed from every mailbox in the organization, needs both endpoint and email protection present to work. Hold one of the two and the behavior simply never happens.
Eight things this layer does that no individual product in the family does alone.
The licensing caveat, which decides what you actually get
The documentation states directly that correlation happens across the Microsoft security products you have licensed and provisioned access to. That one sentence matters more than anything else here. A business running endpoint protection alone gets endpoint correlation and nothing more. The cross-domain story making XDR worth buying requires those domains to be covered in the first place, and most estates cover two or three out of eleven.
One incident, not alerts in four consoles
The stated purpose of the combined incidents queue is helping security professionals concentrate on what is critical, by ensuring the full scope of an attack, the assets it touched and the automated remediation actions all arrive grouped together and promptly. For a small team, receiving one incident with a timeline attached rather than four apparently unrelated alerts is the difference between responding to something and merely triaging it.
Automatic attack disruption, with a concrete example
What happens is that high-confidence signals from several workloads get correlated, and containment actions are applied automatically to halt an attack in progress and limit lateral movement. The published example is admirably precise. A malicious file detected on an endpoint causes Defender for Office 365 to scan for and remove that same file from every email message, after which the entire suite blocks it on sight.
Self-healing across devices, identities and mailboxes
AI-powered automatic actions and playbooks return the affected assets to a secure state, drawing on the automatic remediation capabilities inside each suite product so that every impacted asset connected to an incident gets remediated wherever that is possible. For a team with no spare capacity for manual cleanup, a meaningful share of the value sits right here.
Cross-product hunting, with a thirty-day window
Query-based access reaches thirty days of historic raw signals and alert data drawn from Defender for Endpoint, Defender for Office 365, Defender for Identity and Defender for Cloud Apps. Thirty days is generous for hunting and distinctly short for investigating something discovered late, which is exactly why Sentinel and longer retention exist alongside it rather than instead of it.
Eleven contributing products, not four
Past the four Defender workloads everybody expects, the published list continues with Defender Vulnerability Management, Defender for Cloud, Microsoft Entra ID Protection, Data Loss Prevention, App Governance, Purview Insider Risk Management and Microsoft Security Exposure Management. Several of those are capabilities businesses already own and have never once connected into the wider picture.
The narrative, which is what a report actually needs
The layer is described as narrating the complete story of an attack across product alerts, behaviors and context, achieved by joining data about alerts, suspicious events and impacted assets into incidents. When somebody has to explain to a board, to an insurer or to breach counsel how an attack got in, what it reached and what was done about it, that narrative is the deliverable. A list of alerts is not.
Signal sharing that makes each product better
That cross-product layer protects against attacks and coordinates the defensive response through signal sharing and automated actions, meaning a detection in one workload strengthens all the others rather than remaining local to where it happened. This compounding effect is the genuine argument for staying inside one product family, and it is equally the reason partial coverage underdelivers against what the marketing implies.
Four things that decide whether this delivers what the name promises.
We map coverage against the eleven sources first
Because correlation is documented as covering only the products you have licensed and provisioned access to. So we establish which of the eleven you hold, which of those are provisioned, and which are licensed but were never switched on. In most estates that third category is the surprise, and closing it costs nothing beyond configuration time.
We enable attack disruption deliberately, with the team briefed
Containment actions get applied automatically to halt an attack in progress and limit lateral movement, which is exactly what you want and also means the platform will act without consulting anybody first. Establishing what it is able to do, who gets told when it fires, and how an action is reviewed afterwards is a short conversation that heads off a much longer one later.
The thirty day window is treated as a design input rather than a footnote
Thirty days of raw signal is plentiful for hunting and distinctly short for investigating something discovered months afterwards, which describes the common case for a breach rather than the exception. Where your retention obligations or your realistic discovery timelines run past that, the answer is Sentinel with longer retention rather than hoping thirty days turns out to be enough.
We make sure somebody actually works the queue
One combined incident queue beats four separate consoles by a considerable margin, and it still needs a human being. We establish who triages, within what timeframe, and what happens when something arrives outside working hours. The most common failure of a genuinely good detection platform is not that it missed something. It is that nobody opened the incident it produced.
Six US situations where the correlation layer changes the outcome.
A phishing email that became an endpoint compromise
The most common shape of a real incident, and the one that separate consoles handle worst. With email and endpoint both feeding the correlation layer, that becomes a single incident with a timeline from the message to the device. With one of the two, it becomes two alerts that somebody has to connect by hand, if they notice at all.
A small team drowning in alerts
Two or three people between them covering endpoint, identity, email and cloud. The combined incident queue exists precisely to group the full attack scope, the impacted assets and the automated remediation actions together in one place. That grouping separates a team that responds to incidents from a team spending its entire day working out which alerts belong to each other.
A regulated firm that has to narrate an incident
The moment an insurer, a board, breach counsel or an examiner asks how the attack got in, what it reached and what was done about it. The layer is described as narrating the full story across alerts, behaviors and context, and that narrative is precisely the artifact those questions require. Reconstructing the same thing by hand from separate products takes days. For a firm weighing a state breach notification or an SEC materiality determination, days are exactly what it does not have.
An organization with no out-of-hours coverage
Automatic attack disruption applies containment without waiting for anybody, and self-healing then remediates the affected devices, identities and mailboxes wherever it can. For a business whose security capacity runs to office hours, that automation is doing the work nobody is awake to do, and on its own that is a meaningful argument for the product.
An organization on E5 using a fraction of it
This is the finding we make more often than any other. Several of the eleven signal sources turn out to be licensed already and never provisioned, and each one connected widens the correlation without a dollar of additional spend. Producing that list is a short exercise returning unusually well against the effort it takes.
A team ready to go hunting rather than only responding
Thirty days of query-based access to raw signals and alert data spanning endpoint, email, identity and cloud applications makes a genuinely useful hunting surface. For a team willing to go looking rather than waiting to be told, this is where that begins, and none of it requires Sentinel to get started.
How much of the attack story US organizations can actually see.
| Feature | Broad coverage | Two or three workloads | Endpoint only |
|---|---|---|---|
Endpoint detections | Yes | Yes | Yes |
Email entry point visible | Yes | Sometimes | No |
Identity movement visible | Yes | Rarely | No |
SaaS and cloud application activity visible | Yes | Rarely | No |
One incident with a full timeline | Yes | Partial | No |
Attack disruption across workloads | Yes | Limited | No |
Self-healing across devices, identities and mailboxes | Yes | Partial | Devices only |
Cross-product hunting available | Yes | Limited | No |
Attack narrative available for a report | Yes | Partial | No |
Could scope an incident for a disclosure decision | Yes | Partial | No |
Eleven products, and what each contributes to the picture.
Product
Defender for Endpoint
- What it contributes
- Detections from devices, supplying the endpoint half of almost every attack story
Product
Defender for Office 365
- What it contributes
- Email and collaboration, usually the entry point
Product
Defender for Identity
- What it contributes
- On-premises and hybrid identity, reconnaissance and lateral movement
Product
Defender for Cloud Apps
- What it contributes
- Activity across your SaaS estate, OAuth applications, and data sitting in third-party services
Product
Defender Vulnerability Management
- What it contributes
- What was exposed, and whether it was being exploited
Product
Defender for Cloud
- What it contributes
- Azure, AWS and GCP workload and posture signals
Product
Microsoft Entra ID Protection
- What it contributes
- Cloud identity risk, risky sign-ins and risky users
Product
Data Loss Prevention
- What it contributes
- Whether sensitive content moved during the incident
Product
App Governance
- What it contributes
- OAuth applications with standing permissions to your data
Product
Purview Insider Risk Management
- What it contributes
- Behavioral risk signals, where the actor may be internal
Product
Security Exposure Management
- What it contributes
- Attack paths and exposure context around the affected assets
Five steps, of which the first is an audit rather than any kind of deployment.
- 1
Map coverage against the eleven signal sources
We establish which are licensed, which are provisioned, and which are licensed while sitting switched off. Since correlation is documented as covering only what you hold and have provisioned, this list sets the ceiling on everything afterwards. It also, reliably, contains a few wins that cost nothing.
- 2
Connect what is already paid for
We begin with whichever workloads widen the picture furthest, which usually means email joining endpoint, then identity, then cloud applications. Every addition improves the correlation on every incident that follows it, and where the license already exists the only cost involved is configuration time.
- 3
Attack disruption and self-healing go on, with the team briefed first
Everybody understands which containment actions can be applied automatically, who gets notified when one fires, and how that action is reviewed afterwards. The automation is valuable specifically because it acts without asking permission, which makes briefing people part of enabling it rather than an optional extra afterwards.
- 4
Set up the response rhythm on the combined queue
Three things get settled: who triages, within what timeframe, and what happens outside working hours. A single well-correlated incident queue is a large improvement and it does not operate itself, and the most common failure of good detection remains an incident nobody ever opened.
- 5
Decide whether thirty days is enough
The window is generous for hunting and short for investigating anything found late. Where your obligations or your realistic discovery timelines run past it, that is precisely the point at which Sentinel and longer retention become the next genuine conversation rather than an upsell somebody is pushing.
What organizations ask about Defender XDR.
Fifteen questions worth answering first.
Coverage
- Which of the eleven products are licensed?Correlation only covers what you hold.
- Which are licensed but not provisioned?A common and free gap to close.
- Is email protection in place alongside endpoint?Attack disruption examples depend on both.
- Is identity covered, on-premises and cloud?Two separate products cover the two halves.
- Are cloud workloads feeding in?Defender for Cloud is on the list.
Automation
- Is automatic attack disruption enabled?It applies containment without a human.
- Is self-healing configured across the workloads?It uses each product's remediation capability.
- Do you know what containment actions can be taken?Worth knowing before one fires.
- Who is notified when disruption acts?Somebody should know it happened.
- Is there a path to reverse an action?Decide before, not during.
Response
- Who works the combined incident queue?And within what timeframe.
- Is anybody hunting, or only responding?Thirty days of raw signal is available.
- Do you need retention beyond thirty days?That is a Sentinel conversation.
- Are incidents reaching a SIEM?Or is the portal the only place they exist.
- Is out of hours covered?Attacks correlate at three in the morning too.
The pages around this one.
Defender for Endpoint
The device workload, and normally the first of these signal sources any business acquires.
Sentinel in the Defender portal
Where longer retention and non-Microsoft sources come in, and what the portal convergence means for your operation.
Microsoft Defender
An overview of the product family, covering what each individual Defender workload does by itself.
Work out how many of those eleven signal sources you already own.
Since correlation reaches only what is licensed and provisioned, that number is the ceiling on everything this can do for you. In most estates a few of them are already paid for and switched off, which makes closing that gap the cheapest improvement on the table.
Related Services
Explore more solutions that work great with this service
Microsoft Defender for Endpoint Services
EDR plan selection, onboarding and zero-gap AV migration
Learn moreMicrosoft Defender for Identity Services
Identity threat detection for Active Directory and Entra
Learn moreMicrosoft Defender for Office 365 Services
Anti-phishing, Safe Links and Safe Attachments done right
Learn moreMicrosoft Sentinel Transition to the Defender Portal
Sentinel transition planning and delivery for US organizations ahead
Learn moreMicrosoft Defender
Advanced endpoint and email threat protection
Learn moreSOC-as-a-Service
24/7 security operations delivered as a service
Learn more