The suite is sold as one word and licensed as six products, and the distance between those two facts is where most Defender projects start on the wrong foot. Before you configure a single policy, the question that decides everything is not how Defender works. It is which of its parts your license actually turned on, and which console now owns them. Get that wrong and you either pay twice for coverage you already had, or you build a security posture on a capability you were never entitled to.
Six workloads wearing one name
Defender XDR is an umbrella over six things. Defender for Endpoint watches the device. Defender for Identity reads the identity fabric, the domain controllers plus the federation, certificate, and directory-sync servers around them, and now Entra ID and third-party providers like Okta as detection surfaces in their own right, for the credential theft and lateral movement that identity attacks run on. Defender for Office 365 guards mail and collaboration. Defender for Cloud Apps sees and governs the SaaS estate, the apps your users adopted, the tokens they consented to, and what leaves through a browser session. Vulnerability and exposure management scores the weaknesses underneath all of it, and increasingly maps the attack paths through them. And the sixth thing is not a product at all: it is the correlation fabric that takes those separate alerts and resolves them into single incidents.
That fabric is the X in XDR, and it is worth being precise about what it is, because it is not a SKU you buy. It is what emerges when enough of those workloads report into one portal and one incident graph. It earns its keep in two specific places: cross-domain incident correlation, where an endpoint alert and an identity alert become one story instead of two tickets, and automatic attack disruption, where the platform contains an attack in progress without waiting for an analyst to wake up. That surface reaches wider than endpoint and identity: it spans containing and isolating a device, disabling an account on premises or in the cloud, revoking Entra sessions and suspending the account outright, and cutting off compromised OAuth applications through Defender for Cloud Apps, with Okta and AWS actions available in preview through Microsoft Sentinel connectors. Both are real, and both exist only to the degree you actually hold the workloads and the plan levels that produce the signal. XDR with a single workload lit is just that workload with a nicer portal. The correlation is a function of coverage, not of the logo on the login page.
One portal now
The consolidation people kept waiting for is done. What used to be the Microsoft 365 Defender portal is now Microsoft Defender XDR, living at security.microsoft.com, and it has absorbed the standalone Defender Security Center and much of the old Security and Compliance experience along the way. It is a single pane with role-scoped views, and that last part matters more than it sounds. The same portal that shows an analyst an incident also hosts the endpoint security policies an administrator manages, and the two roles see different slices of it through the same access model. I will come back to that authority question when we reach the endpoint, because who owns a setting causes more confusion on this platform than any feature does.
What E5 actually gave you
Here is the part worth slowing down for, because “we have E5” is one of the most misleading sentences in this business. There is more than one E5, and they contain different Defenders.
Microsoft 365 E5 is the full bundle, and it is the one that includes Defender for Endpoint Plan 2, Defender for Office 365 Plan 2, Defender for Identity, Defender for Cloud Apps, and the core of vulnerability management. That is the license this series assumes you are working toward. Microsoft 365 E3 gives you Defender for Endpoint Plan 1, which is the prevention layer and nothing of the detection-and-response layer that sits above it. Those two facts alone resolve most of the “why can’t I see EDR” tickets before they are filed.
Then the trap. Enterprise Mobility and Security E5, the license everyone abbreviates to EMS E5, is not Microsoft 365 E5, and the resemblance in the name does real damage. EMS E5 carries the identity and management layer, Entra ID P2 and Intune, but it does not include Defender for Endpoint at all. Every few months someone points at their EMS E5 and assumes their endpoints are covered by Plan 2. They are not. The rule to carry out of this article is simple: Plan 2 arrives through Microsoft 365 E5, through Windows Enterprise E5, through the security add-on Microsoft has lately renamed from Microsoft 365 E5 Security to the Microsoft Defender Suite, or as a standalone Plan 2 license in its own right. If your entitlement does not trace to one of those, you do not have Plan 2, no matter what else the tenant lights up.
Two smaller edges catch people just as often. Servers are never included in the user plans. A server needs its own Defender for Servers coverage or a standalone server license regardless of how rich your per-user licensing looks, and assuming otherwise leaves production machines dark. And the premium tier of vulnerability management is a paid add-on, not something Plan 2 quietly contains; Plan 2 gives you the core, which is generous, but the baselines assessment and the block-vulnerable-app controls sit behind the add-on.
One addition postdates most of what people remember about E5. Since November 2025, Microsoft 365 E5 and E7 include a Security Copilot allocation of four hundred security compute units a month per thousand paid user licenses, capped at ten thousand, scaling proportionally below a thousand seats and resetting monthly without rolling over. Usage beyond the allocation will be throttled at a future date, with pay-as-you-go capacity offered at that time and thirty days of notice promised before it begins, so for now the allocation is a ceiling on capability rather than a bill.
The suite degrades by license, on purpose
It helps to read the plan levels as a gradient rather than a switch. Plan 1 is prevention: next-generation antivirus, the entire attack-surface-reduction family, the firewall, web and device control, and manual response actions. It is a genuinely capable hardening layer, and it is where an E3 tenant lives. Plan 2 adds the part that makes the word XDR honest: endpoint detection and response, automated investigation, and the continuous telemetry that feeds correlation and attack disruption. With Plan 1 you have strong silos. With Plan 2 across the workloads you have a fabric that reasons about an attack as one event.
This is why the licensing question is not an accounting footnote but the first architectural decision. Almost every capability worth designing around lives in that second tier, and almost every expensive mistake comes from assuming you are in it when you are not. Decide where you actually stand before you design anything on top of it.
Where we start
This series treats the endpoint as the spine and works outward from it, because that is where this audience already operates and because the endpoint is the workload whose signal everything else correlates against. It sits alongside the endpoint security work already in the Intune Deployment Guide rather than repeating it. The next article maps Defender for Endpoint itself, and it deliberately does not start with features. It starts with the three verbs people run together, onboarding, configuration, and enrollment, and the question of which console actually owns your settings once a device is in. Get the map right and the rest is build.
Defender XDR
Next: [D 2] Defender for Endpoint: The Endpoint Control Plane ›
