Architecting Conditional Access Policies

Conditional Access Is the Policy Engine

In Lesson 1 we said Zero Trust has a central policy engine that turns signals into decisions. In Microsoft Entra ID, that engine is Conditional Access (CA). Think of it as an if-then statement evaluated on every sign-in: IF a particular user, accessing a particular resource, under particular conditions (risk, device, location, app), THEN allow, block, or allow only with extra controls.

CA is where ‘verify explicitly’ becomes real. It does not replace authentication — it sits after the first factor and decides what else is required before a token is issued. Because tokens gate access to every Microsoft 365 and integrated app, CA is the single most important identity control you will design. Get it right and a stolen password is nearly useless; get it wrong and you either lock out your company or leave the door open.

Anatomy of a Policy: Assignments vs. Access Controls

Every CA policy has two halves.

Assignments (the IF):

• Users and groups — who the policy targets, with exclusions (this is where break-glass accounts go).
• Target resources — cloud apps, user actions (e.g., register security info), or authentication context.
• Conditions / signals — the contextual inputs: sign-in risk, user risk, device platforms, device state (compliant/hybrid-joined), locations, and client apps (browser, mobile/desktop, legacy).

Access controls (the THEN):

• Grant controls — block access, or grant only if controls are met: require MFA, require phishing-resistant MFA, require a compliant device, require hybrid-joined device, require approved client app, require app protection policy. Combine with require all or require one.
• Session controls — shape the session even after access is granted: sign-in frequency, persistent browser, app-enforced restrictions (e.g., limited web-only access to Exchange/SharePoint), and Conditional Access App Control via Defender for Cloud Apps.

The Signals That Drive Decisions

CA is only as smart as the signals it can read. The key ones:

• User/group membership — the baseline scope.
• Sign-in risk (from Microsoft Entra Identity Protection) — the probability this specific sign-in is not the legitimate user (impossible travel, anonymous IP, malware-linked IP).
• User risk (also Identity Protection) — the probability the account itself is compromised (leaked credentials found, atypical behavior over time).
• Device compliance / state — comes from Microsoft Intune: is the device enrolled, compliant with policy (encryption, OS version, defender healthy), or hybrid-joined? This is the bridge between the identity and endpoint pillars.
• Location — named locations / trusted IPs or country-based conditions.
• Client app — modern auth browser/desktop vs. legacy authentication (POP, IMAP, SMTP, older Office). Legacy auth can’t do MFA and should be blocked outright.

A Realistic Policy as Graph JSON

CA policies are objects you can read and deploy via Microsoft Graph. Below is a policy that requires phishing-resistant MFA for all users on all apps, in report-only mode, excluding break-glass accounts. Note grantControls.authenticationStrength referencing the built-in phishing-resistant strength.

{
  "displayName": "CA001 - Require phishing-resistant MFA for all users",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeUsers": ["All"],
      "excludeUsers": [
        "<break-glass-1-objectId>",
        "<break-glass-2-objectId>"
      ]
    },
    "applications": {
      "includeApplications": ["All"]
    },
    "clientAppTypes": ["all"]
  },
  "grantControls": {
    "operator": "AND",
    "authenticationStrength": {
      "id": "00000000-0000-0000-0000-000000000004"
    }
  }
}

A second policy blocks legacy authentication, which cannot satisfy MFA at all:

{
  "displayName": "CA002 - Block legacy authentication",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": { "includeUsers": ["All"], "excludeUsers": ["<break-glass-1-objectId>"] },
    "applications": { "includeApplications": ["All"] },
    "clientAppTypes": ["exchangeActiveSync", "other"]
  },
  "grantControls": { "operator": "OR", "builtInControls": ["block"] }
}

Deploy and inspect policies with Graph PowerShell, for example Get-MgIdentityConditionalAccessPolicy and New-MgIdentityConditionalAccessPolicy -BodyParameter $json.

Safe Rollout: Report-Only, What If, and Phasing

Never flip a tenant-wide blocking policy straight to On. The discipline:

1. Report-only mode (enabledForReportingButNotEnforced) — the policy is evaluated on real sign-ins and the result is logged (would-grant / would-block / would-require-control) without affecting users. Watch the sign-in logs and the report-only workbook for days.
2. What If tool — simulate a specific user, app, and conditions to see which policies apply and why.
3. Phased enforcement — pilot on a small group, then ring out to the org; keep exclusion groups for users who need temporary relief.
4. Monitor after enabling — confirm no spike in failures or help-desk tickets before declaring success.

This is the difference between an architect and someone who locks out the CEO on a Friday afternoon.

Break-Glass Accounts and the Layered Baseline

Break-glass (emergency access) accounts are your insurance against a CA mistake or an MFA-provider outage locking everyone out. Best practice: at least two cloud-only accounts (*.onmicrosoft.com), Global Administrator, with long unique passphrases stored offline, excluded from blocking CA policies, and wired to alerts on every sign-in so any real use is noticed immediately.

With that safety net, layer the baseline from broad hygiene to adaptive response:

1. Block legacy authentication (CA002 above) — kills the easiest password-spray path.
2. Require MFA / phishing-resistant MFA for all users (CA001) — the core ‘verify explicitly’ control.
3. Require a compliant or hybrid-joined device for sensitive/admin apps — ties access to Intune endpoint health.
4. Identity Protection risk policies — high sign-in risk → block; high user risk → require secure password change (self-remediation via MFA).

Each layer maps to a Zero Trust principle, and every layer carries the same break-glass exclusion. That is a defensible, portfolio-grade Conditional Access architecture.