The Architecture of a Secure M365 Tenant: Layers, Dependencies, and Decisions
- Derek Morgan
- 7 days ago
- 7 min read
A client asked us to review their Conditional Access policies before a cyber insurance renewal. One policy stood out: it required an app protection policy as a grant control, covering Outlook and Teams on unmanaged mobile devices. Correct control, in principle. Nobody had deployed a single app protection policy in Intune to satisfy it.
Conditional Access was checking a box with nothing behind it. When the grant control evaluated, it found zero deployed app protection policies assigned to those users, so it could never confirm compliance. The result: legitimate users on unmanaged phones got blocked from Outlook and Teams the day the policy went live, and the helpdesk queue filled with "I can't check my email" tickets that had nothing to do with a phishing attempt or a compromised account.
Every setting on that policy was correct in isolation. The failure was sequence: someone built the layer that reads a signal, Conditional Access, before the layer that produces the signal, Intune app protection, existed. A secure Microsoft 365 tenant is a set of layers that read from each other, and the order you build them in decides whether the tenant works or breaks on the day you turn on enforcement.
The 7 layers and what each one depends on
Microsoft's Zero Trust guidance defines 7 technology pillars for tenant security: identities, endpoints, data, apps, infrastructure, network, and SecOps. Treat those pillars as layers, and each one depends on the layer beneath it for a specific signal. That dependency chain is the actual architecture of the tenant, whether or not anyone draws it out before configuring anything.
Identity, in Entra ID, is the layer every other layer reads from. Group membership, role assignment, and Privileged Identity Management eligibility originate here, and every downstream control, Conditional Access, data access policies, app permissions, checks identity state before it checks anything else.
Endpoint, in Intune, produces two separate signals. Device compliance answers whether this is a managed, healthy device, fed by Autopilot enrollment and compliance policy. App protection state answers whether this specific app, on this specific device, is wrapped in a policy controlling copy/paste, save-as, and data at rest. Those two signals are configured and deployed separately, and app protection was exactly the piece missing from the client's tenant.
Conditional Access sits above both of those layers at once, reading identity signal and endpoint signal together to make a single access decision. That's why it's the layer where sequencing mistakes surface first: it's the first point in the stack where two independent dependencies both have to be live, and it fails the moment either one isn't.
Data, through sensitivity labels and classification in Purview, is what DLP policies and access reviews read from. A DLP policy that references a sensitivity label nobody has applied to any content behaves exactly like the client's Conditional Access policy: correctly configured and functionally inert.
Apps, infrastructure, and network fill out the middle of the stack, and each reads identity and endpoint signal in a different combination depending on the specific control. Defender for Cloud Apps session policies are a good example, and they show the dependency chain has a third link, not just two. Session control is invoked through a Conditional Access policy using Conditional Access App Control, so it inherits everything Conditional Access already depends on: identity risk signal from Entra ID Identity Protection and device compliance from Intune. Only once that's live does the session policy have anything to evaluate, deciding whether to block a download or force read-only mode. Infrastructure controls (server and service configuration) and network controls (segmentation and traffic filtering) run on a similar pattern: they enforce rules written for specific identities and workloads, so they depend on those identities being defined and that workload inventory being current before the rule means anything.
SecOps, through Defender XDR and Microsoft Sentinel, sits on top of every other layer, correlating signal from identity, endpoint, data, and network at the same time to catch an attack path that spans more than one layer. A gap in any layer beneath it propagates upward: it weakens that layer directly, and it creates a blind spot in the layer meant to catch what everything else missed.
Why sequencing is a CISO problem
This is where the architecture question stops being an engineering detail and becomes something a CISO has to own. The 2026 Verizon Data Breach Investigations Report found that vulnerability exploitation overtook stolen credentials as the leading initial access vector for the first time in the report's 19-year history, and that only 23% of third-party organizations fully remediate MFA gaps on their cloud accounts. Credential-based access hasn't gone away. It's still the dominant path once an attacker is inside, largely through the infostealer pipeline the report tracks. What's changed is how fast a misconfigured or incomplete layer gets found and used.
Mandiant's M-Trends 2026 report puts a number on what a sequencing gap costs in response time. Global median dwell time rose to 14 days in 2025, up from 11 in 2024. That number splits sharply by how the intrusion was found: organizations that detected it internally averaged 9 days, while organizations that learned about it from an external notification averaged 25 days. That gap comes down to whether SecOps has signal actually flowing to it from identity and endpoint, or whether those layers were configured independently and never wired together.
Here's the mechanism, stated plainly. A Conditional Access policy that references a control nobody deployed fails in one of two ways, and both are expensive. Either it blocks legitimate access, a helpdesk cost measured in hours and a productivity cost measured in frustrated employees, or it silently fails to enforce anything, a breach cost that stays invisible until an incident forces it into view. Both outcomes trace back to the same root cause: a layer built before its dependency was verified.
The dwell-time gap works the same way, and it compounds. Every additional day an intrusion runs undetected is another day of lateral movement, which means more systems touched, more accounts used, and more log data an incident response team has to correlate before they can say with confidence what's actually compromised. A tenant where SecOps reads live signal from identity and endpoint catches that movement inside the 9-day internal-detection window. A tenant where those layers were never wired together waits for someone outside the organization to notice, and pays for the other 16 days.
A build sequence for the 7 layers
Testing everything before turning it on helps. The sequencing fix goes further: build layers in an order where each dependency is verifiable before the layer above it goes live, and treat that verification as a specific, named step rather than an assumption.
At Cloud Harbor Consulting, our build sequence follows the dependency chain directly, and each stage has shipped as a framework in the M365-Security-Frameworks GitHub repository so the sequence is reusable rather than something that only lives in a consultant's head.
Identity foundation first. Group structure, role definitions, and PIM eligibility, built out through the Entra ID Governance Toolkit, before anything downstream references them.
Endpoint enrollment and compliance second, split into its two halves. Device compliance, verified through the Intune Compliance Baseline, confirms managed and healthy devices. App protection policies are a separate build step: confirm the policy exists, is assigned to the correct group, and shows a deployed status in Intune before anything above it references it.
Conditional Access third, built against the Conditional Access Baseline, and only after steps 1 and 2 are verified live. This is the direct fix for the client's gap: the app-protection grant control goes live after the app protection policy is confirmed deployed, not before.
Data classification and DLP fourth, so sensitivity labels exist and are applied before any policy references them.
SecOps last, through Defender XDR, wired to consume signal from every layer above it once each one is confirmed operational, using the Security Reporting Decision Rubric to define what gets escalated and to whom.
The verification step that would have caught the client's gap is specific. Before setting "require app protection policy" as a Conditional Access grant control, open Intune, confirm the app protection policy exists, confirm it's assigned to the correct user or device group, and confirm its deployment status shows active rather than pending. That's a 5-minute check against a policy that took an afternoon to build. Skipping it is what turned a sound control into a helpdesk incident.
We're formalizing this sequencing check across all 7 layers in the Zero Trust Readiness Assessment Framework, currently in development, so the verification doesn't depend on a consultant remembering to ask the right question.
The tenants that get breached, or locked out, with every license already purchased are usually the ones where the layers were configured independently instead of in dependency order. Buying Entra ID P2, Intune, and Defender XDR gets an organization 7 layers of capability, built in whatever order licensing and deployment happened to follow. Turning that capability into an architecture is a decision, made in a specific order, verified at each step, before the next layer goes live.
Is Your Tenant's Layer Order Verified, or Just Deployed?
Cloud Harbor Consulting partners with security architects and CISOs to turn a Microsoft 365 tenant that looks secure on paper into one that has been checked against the dependency chain it's actually built on: identity signal, endpoint compliance, and Conditional Access grant controls confirmed in the order they go live. Schedule a conversation to walk your tenant's build order against this dependency checklist and pinpoint where an app protection policy that was never deployed, a Conditional Access rule reading a signal that doesn't exist yet, or a SecOps layer that isn't actually wired to identity and endpoint is leaving sign-ins exposed that your license inventory says are covered.
Comments