Zero Trust with Microsoft 365 - A Practical Implementation Guide

In our Zero Trust architecture guide we described the seven principles of NIST SP 800-207, the CISA ZTMM v2.0 maturity model, and the five pillars: identity, devices, networks, applications, and data. The question every CISO asks next is: “How do I do this with what I already have?”

For most organizations the answer is Microsoft 365. Not because it is the only solution - but because the M365 ecosystem covers all five ZTA pillars natively, without the need to purchase ten separate tools from different vendors. Policy Engine (Entra ID Conditional Access), Policy Administrator (Entra ID + Intune), Policy Enforcement Points (Defender for Endpoint, Global Secure Access, Purview DLP) - all three NIST logical components are built into the platform.

This article is a practical guide: what to configure, in what order, and at which licensing level. It is not Microsoft documentation - it is a decision map for a CISO and security architect planning a deployment.

M365 as a Zero Trust Platform - Mapping to NIST 800-207

The NIST 800-207 architecture relies on three components: Policy Engine (PE), Policy Administrator (PA), and Policy Enforcement Point (PEP). In the M365 ecosystem they map as follows:

NIST Component	M365 Implementation	Function
Policy Engine	Entra ID Conditional Access + Identity Protection	Session risk assessment, trust algorithm, grant/deny/step-up decision
Policy Administrator	Entra ID + Intune + Defender for Cloud Apps	Policy configuration, distribution to PEPs, session management
PEP - Identity	Entra ID MFA + Passwordless	Authentication enforcement
PEP - Devices	Intune Compliance + Defender for Endpoint	Device posture checks, isolation of compromised devices
PEP - Network	Global Secure Access (Entra Private Access + Internet Access)	ZTNA replacing VPN, SWG, traffic filtering
PEP - Applications	Defender for Cloud Apps (CASB)	SaaS access control, shadow IT discovery
PEP - Data	Purview Information Protection + DLP	Classification, encryption, exfiltration blocking
Telemetry	Defender XDR + Sentinel	Signal collection feeding the trust algorithm

What You Get at Each Licensing Level

Not every organization needs M365 E5. The table below shows which ZTA capabilities you gain at each tier:

ZTA Pillar	Business Standard	Business Premium	M365 E3	M365 E5
Identity	Entra ID Free: MFA (security defaults), no Conditional Access	Entra ID P1: Conditional Access, MFA, SSO	Same as BP	Entra ID P2: risk-based CA, Identity Protection, PIM, access reviews
Devices	No MDM, no EDR	Intune MDM/MAM, Defender for Endpoint P1	Intune, no Defender for Endpoint	Intune + Defender for Endpoint P2 (full EDR, AIR)
Network	None	No native ZTNA	No native ZTNA	Global Secure Access (ZTNA, SSE) - add-on
Applications	None	No CASB	No CASB	Defender for Cloud Apps (CASB)
Data	No sensitivity labels, no DLP	Basic sensitivity labels, DLP	Sensitivity labels, DLP	Auto-labeling, trainable classifiers, advanced DLP
Detection	Exchange Online Protection (basic)	Defender for Office 365 P1	No Defender for Office 365	Defender XDR (Endpoint + Office + Identity + Cloud Apps)
SIEM	None	None	None	Microsoft Sentinel (add-on, consumption-based)
ZTA readiness	No foundations	Solid baseline	Gaps in EDR and email	Full stack

SEQRED Recommendation

Organization Profile	Recommended License	Rationale
Startup / micro-company	Business Standard + Entra ID P1 add-on	Minimum for Conditional Access and MFA. No EDR - acceptable for <10 users with low risk
SMB (<300 users)	Business Premium	Best security-to-cost ratio - Defender for Endpoint P1, Intune, Conditional Access P1
Mid-size company (300-2000)	E3 + E5 Security add-on	E3 for productivity, E5 Security for full security stack on key accounts
Large / regulated organization	E5	Full stack: Defender XDR, CASB, Identity Protection P2, PIM, auto-labeling
Privileged accounts (IT, admin)	E5 regardless of the rest	Highest-risk accounts require full protection - mixed licensing

Step-by-Step Implementation - Mapping to CISA ZTMM Pillars

Pillar 1: Identity - The Foundation

Identity is the starting point for Zero Trust. Without centralized identity management no other control makes sense.

Step 1.1: Enable MFA for everyone

Since 2025 Microsoft requires MFA for all administrative accounts in Entra ID. But that is the minimum - MFA should cover every user.

Configuration in Entra ID -> Conditional Access -> New policy:

• Assignment: All users (excluding break-glass accounts)
• Cloud apps: All cloud apps
• Conditions: Any location (no exclusions)
• Grant: Require multifactor authentication
• Session: Sign-in frequency = 12 hours

Step 1.2: Configure Conditional Access policies

Baseline policy starter set:

Policy	Purpose	Configuration
Require MFA for admins	Global Admin, Security Admin, Exchange Admin accounts	Grant: Require MFA + Require compliant device
Block legacy authentication	Disable POP, IMAP, SMTP Basic Auth	Conditions: Client apps = Other clients -> Block
Require compliant device	SharePoint/OneDrive/Teams access only from managed devices	Grant: Require device to be marked as compliant
Risk-based sign-in (E5)	Step-up MFA on elevated session risk	Conditions: Sign-in risk = Medium/High -> Grant: Require MFA
Risk-based user (E5)	Force password reset on compromised account	Conditions: User risk = High -> Grant: Require password change + MFA
Block by country	Block sign-ins from countries where the organization does not operate	Conditions: Location = All except named locations -> Block

Step 1.3: Deploy phishing-resistant MFA

For privileged accounts and sensitive data - FIDO2 security keys or passkeys:

• Entra ID -> Authentication methods -> FIDO2 security key -> Enable
• Conditional Access policy: accounts in Global Admin/Security Admin role -> Grant: Require authentication strength = Phishing-resistant MFA

Step 1.4: Privileged Identity Management (E5)

PIM eliminates permanently active administrative accounts:

• Global Admin role -> Eligible (not Active). Administrator activates the role for 1-8 hours with justification
• Require approval by a second person for Tier 0 roles
• Access reviews every 90 days - automatic deactivation of unconfirmed roles

Pillar 2: Devices - The Endpoint as Perimeter

Step 2.1: Intune enrollment

All devices accessing corporate data must be managed:

• Windows Autopilot for new devices (zero-touch deployment)
• Manual enrollment for existing devices (Settings -> Accounts -> Access work or school)
• BYOD: Intune App Protection Policies (MAM) without full device enrollment

Step 2.2: Compliance policies

Compliance policies define the minimum a device must meet to gain access:

Control	Windows	macOS	iOS/Android
Disk encryption	BitLocker required	FileVault required	Native encryption
Firewall	Windows Firewall enabled	macOS Firewall	N/A
Antivirus	Defender up to date	Defender/XProtect	N/A
OS version	Min. Windows 11 23H2	Min. macOS 14	Min. iOS 17 / Android 14
Jailbreak/root	N/A	N/A	Blocked
PIN/biometrics	Windows Hello	Touch/Face ID	Required

Conditional Access policy: Grant -> Require device to be marked as compliant. A non-compliant device is denied access to M365.

Step 2.3: Defender for Endpoint

EDR on every endpoint - the foundation of visibility:

• Automated Investigation and Remediation (AIR) - automatic analysis and response to alerts
• Attack Surface Reduction (ASR) rules - blocking Office macros, credential dumping, lateral movement
• Device isolation - remote isolation of a compromised device with one click
• Threat and Vulnerability Management (TVM) - patching prioritization based on exploitability

Pillar 3: Network - From VPN to ZTNA

Step 3.1: Global Secure Access (ZTNA)

Microsoft Entra Private Access is the native ZTNA replacing VPN:

• No network exposure - the user gains access to a specific application, not the entire network
• Per-app Conditional Access - each internal application has its own access policy
• Private DNS - private name resolution without VPN
• Connector agent - lightweight agent on a server in the corporate network, establishing an outbound tunnel

Difference vs VPN: VPN grants access to the network (Layer 3). ZTNA grants access to the application (Layer 7) - an attacker who compromises an account cannot see the rest of the network.

Step 3.2: Entra Internet Access (SWG)

Secure Web Gateway filtering internet traffic:

• Web content filtering - blocking categories (malware, phishing, adult)
• Tenant restrictions v2 - blocking sign-ins to unapproved M365 tenants (prevents exfiltration to personal accounts)
• Source IP restoration - logs preserve the user’s original IP (not the proxy IP)

Pillar 4: Applications - Visibility and Control

Step 4.1: Defender for Cloud Apps (CASB)

Shadow IT discovery - connect proxy/firewall logs to Defender for Cloud Apps:

• Automatic discovery of SaaS applications used in the organization (typically 500-3000 unique applications)
• Risk scoring of each application (security, compliance, industry benchmarks)
• Sanction/unsanction - approve or block applications
• Session control - Conditional Access App Control for real-time session inspection (e.g., blocking downloads from SharePoint on an unmanaged device)

Step 4.2: OAuth app governance

Control of applications with OAuth permissions to M365:

• Review applications with Mail.Read, Files.ReadWrite.All permissions
• Alert on applications with high permissions from unverified publishers
• Block consent for applications requiring admin permissions

Pillar 5: Data - Classification and Protection

Step 5.1: Sensitivity labels (Purview)

Without classification DLP does not know what to protect. Recommended taxonomy:

Label	Protection	Auto-labeling trigger
Public	No restrictions	None
Internal	Block external sharing	None (default label)
Confidential	Encryption + DLP + watermark	National IDs, tax IDs, card numbers, personal data
Highly Confidential	Encryption + no print + no forward + tracking	Contracts, M&A, intellectual property

Phased deployment:

1. Week 1-2: Create labels, publish as optional (users select manually)
2. Week 3-4: Enable default label = “Internal” (every new document automatically labeled)
3. Month 2: Enable auto-labeling in simulation mode for “Confidential” (trainable classifiers + sensitive info types)
4. Month 3: Activate auto-labeling after verifying simulation results

Step 5.2: DLP policies

DLP enforces policies based on labels:

• Block sending “Confidential” files to external email addresses
• Alert on uploading “Highly Confidential” to unapproved SaaS
• Block copying corporate data from Teams to personal apps (Intune App Protection)
• Policy tip - warn the user before a document is blocked (education > blocking)

Monitoring and Detection - Closing the Loop

Zero Trust requires continuous monitoring - the trust algorithm must be fed with real-time telemetry.

Defender XDR - Signal Correlation

Defender XDR integrates signals from five sources:

Source	Defender Product	Signals
Identity	Defender for Identity	Lateral movement, Kerberoasting, DCSync
Endpoint	Defender for Endpoint	Malware, suspicious processes, ASR alerts
Email	Defender for Office 365	Phishing, BEC, malicious attachments
Cloud apps	Defender for Cloud Apps	Shadow IT, anomalous behavior, OAuth abuse
Data	Purview DLP	Data exfiltration attempts, policy violations

Automatic correlation: phishing attack (email) -> credential theft (identity) -> lateral movement (endpoint) -> data exfiltration (DLP) - Defender XDR links these events into a single incident instead of 4 separate alerts.

Microsoft Sentinel (SIEM/SOAR)

For organizations requiring advanced analytics and log retention:

• Ingestion: logs from Defender XDR + Entra ID + Intune + firewalls + OT NDR
• KQL analytics rules: detection of impossible travel, token theft, MFA fatigue
• SOAR playbooks: automatic device isolation, token revocation, SOC notification
• Workbooks: zero trust maturity dashboards per pillar

Most Common Implementation Mistakes

Mistake	Consequence	Solution
No break-glass accounts	Admin lockout after a misconfigured CA policy	2 emergency accounts with CA excluded, monitored by alert
Conditional Access in “Report-only” forever	Policies report but do not block - false sense of security	Set a deadline to move from Report-only to Enforce (max 30 days)
MFA for admins only	90%+ of attacks target regular user accounts	MFA for EVERYONE, no exceptions
No default sensitivity label	New documents are unlabeled, DLP cannot see them	Default label = “Internal” across the organization
Intune compliance without CA enforcement	Devices are evaluated but non-compliant ones still have access	Conditional Access: Require compliant device
No tenant restrictions	Users sign into personal M365 tenants, exfiltrating data	Entra Internet Access: tenant restrictions v2

Zero Trust Implementation Checklist for M365

Week 1-2: Foundation

• Break-glass accounts (2) with sign-in monitoring
• MFA for all users (Conditional Access policy)
• Block legacy authentication (POP, IMAP, Basic Auth)
• Block sign-ins from countries outside the allowed list

Month 1: Devices

• Enroll devices in Intune (Autopilot or manual)
• Compliance policies (encryption, firewall, OS version)
• Conditional Access: Require compliant device
• Defender for Endpoint deployment (Windows, macOS)

Month 2: Data and Applications

• Sensitivity labels (4 tiers) with default label “Internal”
• Auto-labeling in simulation mode (2-4 weeks)
• DLP policies with policy tips (warnings, not blocks)
• Defender for Cloud Apps - shadow IT discovery

Month 3: Advanced

• PIM for privileged accounts (E5)
• Risk-based Conditional Access (Sign-in risk + User risk) (E5)
• FIDO2 / passkeys for admin accounts
• Global Secure Access pilot (ZTNA replacing VPN)
• Auto-labeling enforcement (after simulation verification)

Ongoing

• Access reviews every 90 days
• Conditional Access policy review quarterly
• Phishing simulations every 2 months
• Red team / penetration testing annually
• OAuth app permissions review quarterly

Where to Start

Zero Trust in M365 does not require purchasing full E5 from day one. Business Premium provides Conditional Access, MFA, Intune, Defender for Endpoint P1, and basic sensitivity labels - enough to move from Traditional to Initial level in CISA ZTMM.

The key is to start with identity (MFA + Conditional Access) and devices (Intune compliance) - these two changes eliminate most attack vectors responsible for 80%+ of breaches (Verizon DBIR 2025: 22% credential theft + 8x increase in VPN attacks).

SEQRED helps organizations implement Zero Trust across the Microsoft 365 ecosystem - from assessing the current configuration, through designing Conditional Access policies, to penetration testing that verifies the effectiveness of the deployment. If you want to assess your current ZTA maturity level - schedule a free consultation.

Related articles:

• Zero Trust Architecture - From Concept to Implementation - theory and NIST/CISA pillars
• Remote and Hybrid Work Security - broader remote work security context
• Password Security - why MFA and passkeys are essential

Sources

• Microsoft - Zero Trust deployment plan with M365
• Microsoft - Zero Trust deployment for technology pillars
• Microsoft - Conditional Access overview
• Microsoft - Zero Trust Workshop and Assessment
• Microsoft - Replace your VPN with Global Secure Access
• Microsoft - Create and configure sensitivity labels
• Microsoft - Intune Zero Trust deployment approach
• NIST SP 800-207 - Zero Trust Architecture
• CISA Zero Trust Maturity Model v2.0