M365 Security · Zero Trust
Conditional Access
Policy Framework
A complete, real-world Conditional Access policy stack built for SMBs on Microsoft 365. Zero Trust principles, Intune compliance enforcement, MFA for every user. Fully documented and deployable.
// overview
What this project covers
Conditional Access is the centrepiece of any Zero Trust deployment on Microsoft 365. Without it, a stolen password is a full breach. With it, an attacker would also need to pass device compliance checks, satisfy MFA, come from an expected location, and have a risk score low enough to proceed.
This writeup covers a full nine-policy CA framework I designed for SMBs. Businesses with 10 to 200 users, mostly on M365 Business Premium, that need enterprise-grade security without the enterprise-grade complexity.
Why SMBs specifically? Larger organisations have dedicated security teams and can handle complex exceptions. SMBs need something that works without heavy ongoing management. These policies are designed to be set once and need very little maintenance after that.
// policy stack
The 9-policy framework
Each policy has a specific job. Together they create layered defence so that no single failure exposes the tenant.
CA-001 · Require MFA for All Users
MFA
Baseline policy. All users, all cloud apps, MFA required. Excludes break-glass accounts. No conditions, so this applies everywhere, always.
CA-002 · Require Compliant Device
COMPLIANT
Blocks access from devices not enrolled in Intune and marked compliant. Works in conjunction with Intune compliance policies. Grace period set to 8 hours to avoid lockouts.
CA-003 · Block Legacy Authentication
BLOCK
Blocks all legacy authentication protocols (IMAP, POP3, SMTP AUTH, basic auth). These protocols cannot perform MFA and are the primary vector for password spray attacks.
CA-004 · Admin MFA (Always On)
MFA
Privileged roles (Global Admin, Exchange Admin, SharePoint Admin etc.) must always perform MFA regardless of device state, location, or session token. No persistent sessions for admins.
CA-005 · Block High-Risk Sign-ins
BLOCK
Sign-ins flagged as high-risk by Entra ID Protection are blocked outright. Requires Entra ID P2 or M365 BP. Mid-risk sign-ins are allowed with MFA + password change.
CA-006 · Block High-Risk Users
BLOCK
Accounts flagged as high-risk users (e.g. credentials detected in breach data) are blocked and require admin remediation before access is restored.
CA-007 · Restrict Unmanaged Devices
GRANT (LIMITED)
Personal and unmanaged devices can access M365 web apps only. No download, no sync, no desktop app access. This keeps remote access usable without opening the door to data being pulled off to personal devices.
CA-008 · Require MFA for Azure Management
MFA
Any access to Azure Portal, Azure CLI, or Azure PowerShell requires MFA regardless of device state. Protects against infrastructure-level access from a compromised session.
CA-009 · Terms of Use (First Sign-in)
GRANT
New users must accept an Acceptable Use Policy on first sign-in. Satisfies compliance and cyber insurance requirements. Can be paired with B2B guest access scenarios.
// how it works
Sign-in decision flow
Every sign-in passes through these checks in order. The first block condition that matches ends the session.
1
User initiates sign-in
Credentials entered. Entra ID evaluates identity risk score before the first CA policy fires.
2
Legacy auth check (CA-003)
If the client uses IMAP, POP3 or basic auth → blocked immediately. Modern auth clients continue.
3
Risk evaluation (CA-005 / CA-006)
High-risk sign-in or high-risk user → blocked. Requires admin remediation. Medium risk → MFA + password change.
4
MFA challenge (CA-001 / CA-004)
MFA required for all users. Admins always re-authenticate with MFA regardless of session state.
5
Device compliance check (CA-002)
Device must be Intune-enrolled and compliant. Unmanaged devices fall through to CA-007 (browser-only access).
6
Access granted
All checks passed. Session token issued. Token lifetime policies manage re-authentication frequency.
// configuration
Key deployment decisions
A few specific configuration choices that differ from default Microsoft recommendations and why.
Always deploy in Report-Only first. All policies should run in Report-Only mode for at least 7 days before enforcement. Use the Sign-in logs to identify any accounts that would break before flipping to Enabled.
| Decision | Choice | Reason |
|---|---|---|
| Break-glass accounts | Excluded from all policies | Prevents full lockout if CA misconfiguration occurs. 2 accounts, strong passwords, monitored with alerts. |
| MFA method | Microsoft Authenticator (push) | Phishing-resistant. Number matching enabled. SMS disabled as MFA method. |
| Compliant device grace | 8 hours | Gives newly enrolled devices time to reach compliance state without blocking access. |
| Token lifetime | Default (1 hour access, 90 day refresh) | Microsoft-managed adaptive policies handle this better than fixed overrides. |
| Named locations | Office IP ranges marked as trusted | Reduces MFA fatigue for office users. Still requires compliant device. |
| Guest/B2B users | Separate policy set | Guests excluded from compliant-device policies but still require MFA via their home tenant. |
// outcomes
What this achieves
100%
Users covered by MFA on every sign-in
0
Legacy auth protocols permitted
9
Policies covering every access scenario
✓
Cyber Essentials Plus compatible
Cyber Essentials compatible. This framework satisfies the access control requirements for Cyber Essentials and Cyber Essentials Plus certification, which many UK businesses need for public sector contracts and cyber insurance.