EI3.9 The Zero Trust Policy Framework

The recommended policy set

Microsoft publishes a recommended conditional access policy set as part of their Zero Trust identity deployment guidance. The following framework is based on that guidance, adapted with operational lessons from production deployments. Each policy is numbered for reference and includes the policy logic, the attack it mitigates, and the verification query.

Foundation policies (deploy first, apply to everyone)

These policies form the absolute minimum conditional access architecture. Without them, your identity security has critical gaps.

Policy F1: Require MFA for all users on all cloud apps

This is the single most important conditional access policy. It ensures that every user must complete multi-factor authentication for every application. Without this policy, password spray and credential stuffing succeed immediately.

Assignments: All Users. Exclude: CA-Exclude-BreakGlass. Target resources: All cloud apps. Conditions: None (applies to all sign-ins). Grant: Require multifactor authentication. Session: None. State: Enforcing.

Attack mitigated: Password spray (T1110.003), credential stuffing (T1110.004). Does not mitigate: AiTM (requires phishing-resistant strength, Policy P1).

Policy F2: Block legacy authentication

Legacy authentication protocols (IMAP, POP3, SMTP Basic Auth, Exchange ActiveSync with basic auth) do not support MFA. An attacker who knows a user's password can authenticate through a legacy protocol and bypass Policy F1 entirely. This policy closes that gap.

Assignments: All Users. Exclude: CA-Exclude-BreakGlass. Target resources: All cloud apps. Conditions: Client apps = Exchange ActiveSync clients, Other clients. Grant: Block access. State: Enforcing.

Attack mitigated: Password spray via legacy protocols, credential stuffing via legacy protocols. This policy is essential, without it, Policy F1 has a bypass path.

Policy F3: Block sign-ins from disallowed countries

Blocks sign-ins from countries where the organization has no operations.

Assignments: All Users. Exclude: CA-Exclude-BreakGlass. Target resources: All cloud apps. Conditions: Location = All locations except "Allowed Countries" named location. Grant: Block access. State: Enforcing.

Attack mitigated: Opportunistic attacks from foreign infrastructure. Does not mitigate: attacks routed through VPN exit nodes in allowed countries.

Policy F4: Require MFA registration from trusted location or compliant device

Prevents an attacker from registering MFA methods on a compromised account from an untrusted location.

Assignments: All Users. Exclude: CA-Exclude-BreakGlass. Target resources: User actions → Register security information. Conditions: Location = All locations except trusted locations. Grant: Require multifactor authentication. State: Enforcing.

Privileged access policies (deploy second, apply to admins)

These policies add stricter controls for users with directory roles.

Policy P1: Require phishing-resistant MFA for privileged roles

Assignments: Directory roles. Global Admin, Security Admin, Exchange Admin, SharePoint Admin, User Admin, Application Admin, Cloud App Admin, Privileged Role Admin, Auth Admin, Privileged Auth Admin. Exclude: CA-Exclude-BreakGlass. Target resources: All cloud apps. Grant: Require authentication strength → Phishing-resistant MFA. Session: Sign-in frequency = Every time. State: Enforcing.

Attack mitigated: AiTM credential phishing (T1557) against admin accounts. This is the policy that makes EI2's phishing-resistant deployment mandatory for administrators.

Policy P2: Require compliant device for privileged access

Assignments: Same directory roles as P1. Exclude: CA-Exclude-BreakGlass. Target resources: All cloud apps. Grant: Require device to be marked as compliant. State: Enforcing.

Attack mitigated: Administrative access from compromised, unmanaged, or unpatched devices.

Policy P3: Enable token protection for privileged sessions

Assignments: Same directory roles. Target resources: All cloud apps. Session: Token protection (enforce). State: Enforcing (for supported platforms).

Attack mitigated: Token replay of stolen administrative session tokens.

Risk-based policies (deploy third, consume Identity Protection signals)

These policies add adaptive enforcement based on real-time risk.

Policy R1: Require phishing-resistant MFA on medium sign-in risk

Assignments: All Users. Target resources: All cloud apps. Conditions: Sign-in risk = Medium and above. Grant: Require authentication strength → Phishing-resistant MFA. State: Enforcing.

Policy R2: Block sign-in on high sign-in risk

Assignments: All Users. Target resources: All cloud apps. Conditions: Sign-in risk = High. Grant: Block access. State: Enforcing.

Policy R3: Require password change on high user risk

Assignments: All Users. Target resources: All cloud apps. Conditions: User risk = High. Grant: Require password change AND require multifactor authentication. State: Enforcing.

Verification: the coverage query after deployment

After deploying the framework, run the coverage query from EI3.1 to verify that the gap percentage has dropped to near zero:

// EI3.9 — Post-deployment coverage verification
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize 
    Total = count(),
    CAApplied = countif(ConditionalAccessStatus == "success"),
    NoCA = countif(ConditionalAccessStatus == "notApplied")
| extend CoveragePercent = round(100.0 * CAApplied / Total, 1)
| extend GapPercent = round(100.0 * NoCA / Total, 1)
// Before deployment: GapPercent was likely 100% (no policies)
// After foundation policies: GapPercent should be < 5%
// Remaining gap: break-glass accounts + any uncovered apps/platforms

If the gap percentage is above 5% after deploying the foundation policies, investigate the remaining gaps:

// EI3.9 — Identify remaining CA gaps after framework deployment
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| where ConditionalAccessStatus == "notApplied"
| summarize count() by UserPrincipalName, AppDisplayName
| order by count_ desc
// Which users and apps are still uncovered?
// Expected: break-glass accounts, possibly some service accounts
// Unexpected: any regular user or any M365 application = policy scope issue

Tier deployment validation workflow

Each tier should follow the same validation sequence before proceeding to the next:

Week 1: Deploy in report-only. Create all policies for the tier in report-only mode. This evaluates every sign-in against the policies without enforcing any controls. Users experience no change.

Week 1-2: Analyze report-only results. Run the following analysis for each policy: how many sign-ins would be affected (total evaluations), how many would succeed (users who already satisfy the controls), how many would be blocked (users who would lose access), and which users and applications are in the blocked category. The EI1.5 report-only analysis queries provide this data.

Week 2: Remediate blockers. For each user who would be blocked: determine why (no MFA registered, non-compliant device, legacy client app) and remediate (register MFA, enroll device, update client). For each application that would be blocked: determine whether the block is intended (legacy auth to a legacy app should be blocked) or unintended (a modern app using a legacy protocol that needs migration).

Week 2-3: Promote to enforcing. After remediation is complete and the report-only results show acceptable impact, promote the policies to enforcing. Monitor sign-in logs for the first 48 hours after enforcement, look for unexpected blocks (ResultType 53003) from users or applications that were not identified during the report-only analysis.

Week 3-4: Validate enforcement. Run the coverage query to confirm the gap percentage has decreased. Run the per-policy verification queries to confirm each policy is evaluating and enforcing as designed. Document the deployment result: which policies are enforcing, what the coverage percentage is, and what exceptions remain (with justification).

Then proceed to the next tier. Foundation takes 2-4 weeks. Privileged takes 1-2 weeks (fewer users, stricter controls). Risk-based takes 1-2 weeks (depends on Identity Protection being active and generating risk detections for the report-only analysis).

Common deployment mistakes

Mistake: Enforcing without report-only analysis. A policy is created and immediately set to enforcing. Users are locked out. Helpdesk is overwhelmed. The policy is disabled in a panic. Trust in conditional access is damaged. Always deploy in report-only first.

Mistake: Excluding too many users to avoid friction. The IT department is excluded from MFA because "they know what they are doing." The finance team is excluded from device compliance because "they need to use personal devices sometimes." Each exclusion is a gap. If 20% of users are excluded from the baseline MFA policy, 20% of your workforce is vulnerable to password spray.

Mistake: Not excluding break-glass from a new policy. A new blocking policy is created and the administrator forgets to add the CA-Exclude-BreakGlass exclusion. The policy blocks a scenario that includes all users, including the break-glass accounts. If the policy also blocks the administrator, nobody can fix it. Always verify every new policy excludes break-glass.

Mistake: Leaving policies in report-only indefinitely. Report-only policies evaluate but do not enforce. An organization creates policies in report-only for "testing" and never promotes them to enforcing. The policies provide no protection. The stale report-only detection query in EI3.12 catches this drift.

Environment: Your M365 developer tenant.

Exercise: Using the framework above, create the four foundation policies in report-only mode in your developer tenant:

1. F1: Require MFA. All Users (excl. break-glass), All cloud apps
2. F2: Block legacy auth. All Users (excl. break-glass), All cloud apps, legacy client apps
3. F3: Block disallowed countries. All Users (excl. break-glass), All cloud apps, countries outside your allowed list
4. F4: Protect MFA registration. All Users (excl. break-glass), user action = register security info

Deploy all four in report-only mode. After 48 hours, run the coverage query to see what percentage of sign-ins would be covered. Then run the gap query to identify any remaining uncovered sign-ins.

This is the baseline architecture. In EI4, you will add the attack-specific policies that layer on top of this foundation.

The reference above captures the operational configuration. The principle below crystallises the design decision.