Microsoft 365's security capability is often adopted piecemeal — Conditional Access configured on one project, Defender licensed on another, Purview considered later "if we need it." Each individual article in this cluster covers one of those pieces in depth. This article is the reference architecture: how they fit together as one system, and where each layer's responsibility starts and ends.
The five layers
| Layer | Product | Responsibility |
|---|---|---|
| Identity | Entra ID | Who is this, and are they who they claim to be |
| Access Policy | Conditional Access + Entra ID Protection | Given identity + context (device, location, risk), should access be granted |
| Email & Collaboration Protection | Defender for Office 365 | Is this specific message/attachment/link malicious |
| Endpoint Protection | Defender for Endpoint | Is this device compromised or behaving anomalously |
| Data Protection | Microsoft Purview | Is sensitive data being handled, labeled, and shared appropriately |
Why layer order matters
Each layer assumes the ones before it are functioning. Conditional Access policy (Layer 2) is only as trustworthy as the identity verification (Layer 1) underneath it — a weak authentication method undermines every access decision built on top of it. Data protection labels (Layer 5) are only enforceable if the collaboration surface itself (Layer 3) isn't leaking data through an unfiltered channel first. This is the practical reason a piecemeal adoption approach — deploying Purview labels before Conditional Access basics are in place, for instance — tends to underperform relative to building the stack bottom-up.
This mirrors the Identity & Access Management cluster's layered model
The Identity Protection Workflow diagram from Passwordless Authentication and Passkeys makes the same layering argument at the identity level specifically — password, then MFA, then monitoring, then Conditional Access. This architecture extends that same logic across the full Microsoft 365 product surface, not just identity.
How Secure Score maps to this architecture
Microsoft Secure Score Guide's improvement actions span every layer in this architecture — some tenants over-index on identity-layer improvements (since MFA and Conditional Access actions tend to carry high point values) while leaving data protection and endpoint layers comparatively unaddressed. Reviewing Secure Score improvement actions grouped by which architectural layer they belong to is a useful way to spot an imbalanced security posture that the raw score number alone doesn't surface.
Licensing maps to architecture, not the other way around
A common planning mistake is starting from "what licensing tier should we buy" rather than "which architectural layers are currently unaddressed." Working from the architecture backward to licensing — identifying which layer has the biggest gap, then confirming which license unlocks the relevant capability — produces a more defensible investment sequence than licensing decisions driven by bundle marketing alone.
Common mistakes
- Deploying data protection (Purview) or advanced threat protection (Defender) before the identity and access layers are solid, building advanced capability on an unstable foundation.
- Treating each product as an independent purchase decision rather than evaluating gaps against the full five-layer architecture.
- Assuming Secure Score's single number reflects balanced coverage across all five layers, when it can be high due to strength in one or two layers while others remain weak.
- Not revisiting the architecture as Microsoft ships new capabilities — the specific products behind each layer evolve, and the mapping should be periodically re-verified.
FAQ
Do we need all five layers to have meaningful security? The identity and access layers (1-2) provide the highest-leverage protection and should be prioritized first for any organization. The remaining layers add meaningful, complementary protection but the marginal value of each additional layer depends on your specific risk profile and data sensitivity.
How does this architecture relate to Zero Trust? This five-layer model is Microsoft 365's specific product implementation of Zero Trust principles — see Zero Trust in Microsoft 365 for how each layer maps to a specific Zero Trust principle.
Where does Microsoft Sentinel fit into this architecture? Sentinel is a security information and event management (SIEM) layer that sits above all five layers described here, aggregating signals from each for centralized monitoring and investigation — relevant for organizations with a dedicated security operations function, distinct from the protective layers themselves.