Zero Trust is not a product you deploy or a project you finish. It is a continuous improvement program built across six architectural pillars: identity, devices, applications, data, infrastructure, and network. The challenge for most Canadian organizations is not understanding the concept — it is knowing where to start, what to prioritize, and how to sequence changes without breaking existing workflows or exhausting internal capacity.
This roadmap provides a practical 12-month sequence for Microsoft 365 environments, structured around what is realistically achievable per quarter, what licensing is required at each stage, and what "done" looks like before you move to the next phase.
Why Sequencing Matters
The six pillars of Zero Trust are interdependent, but they are not equal in implementation complexity or risk reduction value. Some controls — like blocking legacy authentication — take hours to implement and close critical attack vectors immediately. Others — like mature data classification with auto-labeling — require months of user adoption work before they deliver meaningful protection.
Getting the sequence wrong is expensive. Organizations that deploy DLP policies before identity controls are in place find that data protection is inconsistently enforced because Conditional Access is not gating access correctly. Organizations that deploy Microsoft Sentinel before Defender for Endpoint is properly onboarded have a SIEM receiving incomplete signals and generating unreliable detections.
The sequence in this roadmap follows the dependency chain: identity first, because everything else enforces through identity. Devices second, because device compliance feeds back into identity-based access decisions. Data third, because data protection is most effective once access to it is properly governed. Monitoring last, because detection and response is most valuable when the controls it monitors are correctly configured and generating meaningful signals.
Phase 1 — Months 0–3: Baseline and Critical Risk Reduction
Objective: Understand your current state and close the highest-severity gaps that require no significant architecture changes or user disruption.
What to Do
Establish a verified baseline
Before making changes, document what you have. This means a structured review of your Entra ID Conditional Access policy inventory, including every exclusion, MFA registration and enforcement rates, admin role assignments, legacy authentication protocol status, and Microsoft 365 sharing settings. A Zero Trust Assessment at this stage gives you a CISA ZTMM maturity rating per pillar and a prioritized finding list — so decisions in months 1–3 are based on evidence, not guesswork.
Block legacy authentication protocols
SMTP AUTH, Basic Auth, and POP3/IMAP with Basic Auth bypass MFA entirely. Any attacker with a stolen credential can use them to authenticate without triggering a Conditional Access policy. A single Conditional Access policy blocking legacy authentication for all users takes under an hour to implement and closes one of the most consistently exploited attack vectors in Microsoft 365. This should be one of the first actions of the roadmap.
Enforce MFA for all users
If Security Defaults are in place, replace them with Conditional Access policies — Security Defaults cannot be tuned or scoped, and they have no integration with device compliance or risk signals. If Conditional Access policies exist, audit the exclusions. Exclusions are where MFA enforcement breaks down in practice.
Remove standing Global Administrator assignments
Audit privileged role assignments. Any account with Global Administrator as a permanent standing assignment that is not used for routine administration should be scoped down to a less privileged role or converted to a PIM-eligible assignment if Entra ID P2 is available. At minimum, Global Admin accounts should use dedicated credentials separate from day-to-day user accounts.
Tighten external sharing defaults
SharePoint and OneDrive anonymous sharing links — where anyone with the link can access a file without authentication — should be disabled at the tenant level unless there is a specific, documented business requirement. This is a single tenant setting that immediately reduces the risk of unintended data exposure.
Phase 1 Exit Criteria
- Legacy authentication blocked for all users
- MFA enforced via Conditional Access with documented exclusion list
- Privileged role audit complete with remediation actions assigned
- Anonymous sharing links disabled at tenant level
- Baseline assessment documented
Licensing Required
Microsoft 365 E3 (CAD $53.34/user/month) or Microsoft 365 Business Premium (CAD $31.29/user/month, 300-user cap — always confirm your user count before selecting Business Premium) — all Phase 1 actions are achievable with existing licensing in most environments.
Phase 2 — Months 3–6: Identity and Device Controls
Objective: Build the identity and device enforcement layer that all subsequent controls depend on. By the end of this phase, the core rule of Zero Trust should be operational: only verified users on compliant devices can access sensitive resources.
What to Do
Design and implement a complete Conditional Access policy architecture
Phase 1 closes the most obvious gaps. Phase 2 replaces ad hoc policies with a deliberate policy set. This includes policies for all user populations, including guests and service accounts, sign-in risk and user risk policies, Named Locations for trusted networks, and application-specific policies that apply stricter requirements for high-sensitivity workloads. An Entra ID Deployment engagement produces a documented, tested policy architecture — not a collection of one-off rules.
Deploy Privileged Identity Management
If Entra ID P2 is available, replace all standing privileged role assignments with PIM-eligible assignments. Administrators request elevation just in time, with defined approval workflows, time limits typically 1–4 hours, and full audit logging. This is one of the highest-impact controls available in the Microsoft stack for reducing the blast radius of admin account compromise.
Enroll devices and enforce compliance
Device enrollment in Microsoft Intune should cover all corporate-owned devices across Windows, macOS, iOS, and Android. Compliance policies should enforce minimum OS versions, BitLocker/FileVault encryption, screen lock requirements, and Defender for Endpoint health status. Critically — compliance status must be enforced in Conditional Access as an access condition, not just tracked in a dashboard. An Intune Suite Deployment typically runs as a phased rollout: pilot group first, then department by department, with compliance enforcement in Conditional Access enabled after each wave is validated.
Deploy Microsoft Defender for Endpoint
MDE provides the device health signals that Intune compliance policies evaluate. ASR rules should be validated in audit mode during this phase and moved to enforce mode for rules with low false positive rates — particularly rules that block Office application spawning child processes, credential theft from LSASS, and abuse of Windows Management Instrumentation.
Configure Defender for Identity if on-premises AD exists
MDI sensors should be deployed on all Active Directory Domain Controllers. This gives the XDR platform visibility into on-premises identity activity — lateral movement, pass-the-hash, DCSync attempts, and Kerberoasting — that Entra ID Protection alone cannot detect.
Phase 2 Exit Criteria
- Conditional Access policy set documented with no unintended exclusions
- PIM configured for all privileged roles if Entra ID P2 is licensed
- Device compliance enforced in Conditional Access — non-compliant devices cannot access Microsoft 365
- Defender for Endpoint onboarded on 90% or more of corporate devices
- MDI sensors deployed on all Domain Controllers if applicable
Licensing Required
- Conditional Access: Entra ID P1 — included in M365 E3, Business Premium, EMS E3 (CAD $8.51/user/month standalone)
- PIM and Identity Protection risk policies: Entra ID P2 — M365 E5 or EMS E5 (CAD $12.81/user/month standalone)
- Intune compliance and MDM: Intune Plan 1 — included in M365 E3, Business Premium, EMS (CAD $11.45/user/month standalone)
- Endpoint Privilege Management: Intune Suite — CAD $14.28/user/month
- Defender for Endpoint Plan 2: Microsoft 365 E5 (CAD $81.17/user/month) or Microsoft Defender for Endpoint standalone
Phase 3 — Months 6–9: Data Protection and Application Governance
Objective: Extend Zero Trust controls to data and applications. By the end of this phase, sensitive information should be classified, labeled, and protected by enforced policies — not just guidelines.
What to Do
Deploy sensitivity labels and auto-labeling
A sensitivity label taxonomy — typically 3–5 levels: Public, Internal, Confidential, Highly Confidential, and optionally a regulated data sub-label — should be published in Microsoft Purview and deployed to email, documents, Teams messages, and meetings. Auto-labeling policies should classify content containing regulated data types (SINs, financial data, health information) that users do not label manually. Label adoption below 30% of documents is a signal that manual labeling alone is insufficient and auto-labeling must be expanded.
Move DLP policies from simulation to enforcement
If DLP policies are already in audit mode from earlier work, Phase 3 is when they transition to active enforcement. New policies should be configured for all critical data types across Exchange Online, SharePoint, OneDrive, and Teams — with user-facing policy tips, block-with-override for medium-risk actions, and hard blocks for the highest-risk sharing scenarios (SINs sent externally, payment card data emailed to free domains). A Microsoft Purview DLP Configuration engagement typically spans 4–8 weeks to account for audit mode validation before enforcement is enabled.
Review and govern OAuth application consent
Audit all OAuth app consent grants in your tenant. Third-party applications with broad delegated permissions — read all mail, access all files — granted by individual users without admin review should be revoked and replaced with admin-granted, scoped consents where the application is legitimate. Configure app consent policies so future grants above a defined permission threshold require admin approval.
Configure Defender for Cloud Apps session control
For high-sensitivity applications accessed from unmanaged devices, MDCA session control policies allow you to permit access while restricting download, print, and copy actions. This is the practical solution for BYOD scenarios where you cannot block access entirely but need to limit what users can do with sensitive data.
Phase 3 Exit Criteria
- Sensitivity labels deployed with measurable adoption — target: 60% or more of new documents labeled
- DLP policies in active enforcement across Exchange, SharePoint, OneDrive, Teams
- OAuth consent grant audit complete with high-risk grants revoked
- External sharing restricted to governed, approved domains
Licensing Required
- Sensitivity labels and basic DLP: Microsoft 365 E3 (CAD $53.34/user/month) or Business Premium (CAD $31.29/user/month, 300-user cap) — Purview basics included
- Trainable classifiers, Endpoint DLP, Insider Risk: Microsoft 365 E5 (CAD $81.17/user/month) or Microsoft Purview Suite add-on (CAD $18.13/user/month)
- Defender for Cloud Apps session control: Microsoft 365 E5 or MDCA standalone
Phase 4 — Months 9–12: Detection, Response, and Operational Maturity
Objective: Build the monitoring and response layer that makes the entire architecture operational. By the end of this phase, your security team should have centralized visibility across all pillars and documented processes for responding to the alerts that matter.
What to Do
Deploy Microsoft Defender XDR
With Defender for Endpoint, Defender for Identity, and Entra ID Protection already deployed from Phase 2, Microsoft Defender XDR Setup in Phase 4 focuses on the unification layer: configuring cross-product incident correlation, enabling Automatic Attack Disruption for in-progress attack containment, deploying Defender for Office 365 Safe Links and Safe Attachments at full scope, connecting Defender for Cloud Apps, and building the Advanced Hunting query library for common investigation scenarios.
Deploy Microsoft Sentinel
Microsoft Sentinel SIEM Deployment centralizes log ingestion and detection across all Microsoft 365 and Azure workloads, adds ML-based Fusion detection for multi-stage attack scenarios that individual product alerts miss, and provides the investigation and incident management workflow for your security operations function. Analytics rules should be tuned during the first 4–6 weeks of operation to reduce false positive rates before alert fatigue sets in.
Important licensing note: Microsoft Sentinel is an Azure consumption-based service billed separately from your Microsoft 365 subscription — it is not included in Microsoft 365 E5. Budget planning for Sentinel should begin in Phase 3.
Build operational runbooks
Detection without response is noise. Phase 4 should produce documented runbooks for the alert types your environment generates most frequently: credential compromise response, ransomware containment, data exfiltration investigation, and privileged account misuse. Each runbook should define who owns the response, what the first 30 minutes look like, and what evidence is preserved for insurance or regulatory purposes.
Conduct a second Zero Trust Assessment
A follow-up Zero Trust Assessment at month 12 against the CISA ZTMM provides a documented maturity improvement across all six pillars compared to the Phase 1 baseline. This is not just a milestone — it is the evidence that supports cyber insurance renewal, board reporting, and regulatory compliance documentation.
Phase 4 Exit Criteria
- Defender XDR unified incident queue operational with cross-product correlation validated
- Microsoft Sentinel deployed with data connectors, analytics rules, and alert tuning complete
- Incident response runbooks documented and tested
- 12-month Zero Trust maturity assessment complete with documented improvement versus baseline
Licensing Required
- Defender XDR unified experience: Available at M365 E3 level; full capability at M365 E5 (CAD $81.17/user/month)
- Microsoft Sentinel: Azure consumption-based pricing, separate from M365 licensing — see Sentinel Deployment for cost planning guidance
- Defender for Office 365 Plan 2 (Attack Simulation, Priority Account Protection): M365 E5 or MDO P2 add-on
Licensing Across the 12-Month Roadmap
A common mistake is treating licensing as an all-or-nothing decision — either upgrade everyone to E5 immediately or stay on E3 indefinitely. The practical approach is to align licensing to the roadmap phase and user risk profile.
Phase 1–2 (Months 0–6)
Most actions are achievable with Microsoft 365 E3 (CAD $53.34/user/month) or Microsoft 365 Business Premium (CAD $31.29/user/month, 300-user cap — always confirm your user count before selecting Business Premium). The critical Entra ID P2 upgrade for PIM and Identity Protection risk policies is typically justified in Phase 2 when privileged access governance becomes the focus. For organizations on Business Premium, the included Defender for Endpoint Plan 1 and Defender for Office 365 Plan 1 are sufficient for Phase 2 — with documented gaps for Phase 3 and 4 capabilities.
Phase 3 (Months 6–9)
Endpoint DLP and trainable classifiers require Microsoft 365 E5 (CAD $81.17/user/month) or the Purview Suite add-on (CAD $18.13/user/month). Organizations that need Endpoint DLP to protect data on Windows devices should plan this licensing decision at the start of Phase 3, not during it.
Phase 4 (Months 9–12)
Microsoft Sentinel is an Azure consumption service billed separately from M365 licensing — budget planning should begin in Phase 3. Defender XDR at full capability requires M365 E5 or M365 E3 + E5 Security add-on. The right licensing path depends on your current tier, user count, and which capabilities your roadmap actually requires. A licensing review at the start of Phase 1 prevents overspending on features that are 9 months away from deployment and underspending on capabilities that are needed immediately.
After Month 12
A completed 12-month Zero Trust roadmap is not the end — it is the point at which the continuous improvement model becomes sustainable. The second year typically focuses on:
- Expanding Conditional Access coverage to remaining edge cases and service accounts
- Maturing sensitivity label adoption through policy enforcement and user training
- Extending Endpoint DLP to cover additional data types and application scenarios
- Building a formal vulnerability management program using Defender Vulnerability Management data
- Aligning the Zero Trust program to Canadian regulatory obligations — PIPEDA, OSFI B-10, provincial privacy laws — with documented evidence of controls
Organizations that want ongoing strategic oversight of this program alongside the technical execution use CIO as a Service to keep Zero Trust efforts aligned with broader IT investment decisions rather than treating security as a standalone workstream.
