10.3 Planning & Implementing Conditional Access Policies
Key Takeaways
- A Conditional Access policy is an if-then rule: if the assignments (users, cloud apps, conditions) match, then the access controls (grant with MFA/compliant device/etc., block, or session controls) apply
- Assignments have three buckets — Users (include/exclude), Cloud apps or actions (include/exclude), and Conditions (user risk, sign-in risk, platforms, locations, client apps, authentication context)
- Grant controls include Block, Grant with one or more of MFA/require compliant device/require hybrid joined/require approved app/require password change, with a toggle for requiring all vs any one selected control
- Report-only mode lets you assess a policy's impact on real sign-ins before enforcing it; Microsoft also publishes reusable Conditional Access templates
- Always exclude at least two break-glass / emergency access accounts from every Conditional Access policy to avoid tenant-wide admin lockout
Quick Answer: A Conditional Access (CA) policy is an if-then rule: if a sign-in matches the assignments (specific users, cloud apps, and conditions), then the access controls you defined apply — grant with MFA, require a compliant device, block, or apply session controls. CA replaces ad-hoc per-user MFA and Security Defaults with scoped, policy-driven access. Every CA policy should exclude break-glass accounts, and new policies should start in Report-only mode.
What Conditional Access Is
Conditional Access is Microsoft's recommended access-control mechanism for Entra ID. It evaluates signals at sign-in time and enforces controls before access is granted. The model is declarative: you describe the conditions that matter and the controls you want, and Entra ID applies them consistently across every sign-in.
The Two Halves of a Policy
Every CA policy has two halves — Assignments (the "if") and Access controls (the "then").
Assignments
| Assignment | What you configure |
|---|---|
| Users | Include and/or exclude users, groups, directory roles. Exclude is critical for break-glass accounts. |
| Cloud apps or actions | Include All cloud apps, specific apps, or user actions (like registering security info); exclude specific apps. |
| Conditions | Optional but powerful: user risk, sign-in risk, device platforms, locations/named locations, client apps (browser, mobile, Exchange ActiveSync, legacy protocols), authentication context. |
The Conditions blade is where Identity Protection integrates: user risk and sign-in risk appear here as selectable conditions, each with a Low/Medium/High threshold.
Access Controls
| Control | Options |
|---|---|
| Grant | Block, or Grant with zero or more of: Require MFA, Require device to be marked compliant, Require hybrid Entra-joined device, Require approved client app, Require password change. A toggle lets you require all selected controls or any one of them. |
| Session | Limited sign-in frequency, app-enforced restrictions, persistent browser session, sign-in frequency (re-auth interval), Continuous Access Evaluation. |
The Grant control is the most common. "Grant with Require MFA" is the standard MFA policy. "Block" is absolute — use it for legacy authentication or high-risk scenarios. When you select multiple grant controls, the Require all the selected controls toggle enforces AND logic; Require one of the selected controls enforces OR logic.
Policy Mode: Report-Only vs On
Every CA policy has a Enable policy toggle with three states:
- Report-only — the policy evaluates every sign-in and logs what it would have done, but does not enforce. Use this to assess impact before enforcement.
- On — the policy is enforced.
- Off — the policy is disabled.
Microsoft's documented best practice is to run every new policy in Report-only for a period, review the Conditional Access Insights and reporting workbook, and then flip to On. The workbook shows aggregate impact and per-user results, including which policies matched each sign-in.
Conditional Access Templates
Microsoft publishes a catalog of Conditional Access templates in the Entra admin center — pre-built policy definitions for common scenarios such as:
- Require MFA for admins
- Require MFA for all users
- Block legacy authentication
- Require compliant or Entra-joined device for admins
- Securing security info registration (require MFA to register, only from trusted locations)
- Require MFA for Azure management
- Identity Protection starter policies (sign-in risk, user risk)
Templates are a starting point, not a finished policy — you still scope users, choose report-only, and exclude break-glass accounts before enabling.
Common Policy Patterns
Four patterns cover most real-world deployments:
- Require MFA for all users — Include All users, exclude break-glass; All cloud apps; Grant with MFA. This is the baseline.
- Require MFA for admins — Include directory roles like Global Administrator, Privileged Role Administrator, Security Administrator; All cloud apps; Grant with MFA. Layered on top of the all-users policy.
- Block legacy authentication — Include All users; Conditions → Client apps → Other clients (Exchange ActiveSync legacy, IMAP, POP, SMTP); Grant → Block. Legacy auth cannot do MFA, so blocking it removes a major bypass.
- Require compliant device for access — Include All users (or a group); All cloud apps or a sensitive app; Grant with Require device marked compliant (often combined with Require hybrid Entra-joined for domain-joined devices).
Conditions-to-Controls Reference
| Condition | Typical control |
|---|---|
| User risk = High | Block, or require secure password reset (via Identity Protection user risk policy) |
| Sign-in risk = Medium/High | Require MFA, or block at High |
| Location = untrusted | Require MFA |
| Location = trusted (named location) | Skip MFA (used as exclude) |
| Client apps = legacy protocols | Block |
| Device platform = macOS/iOS/Android | Require approved client app, require compliant device |
| Authentication context (step-up) | Require MFA for sensitive actions within a session |
Best Practices
- Always exclude break-glass accounts. Keep at least two emergency-access accounts (cloud-only, no MFA, strong passwords) excluded from every CA policy. If a misconfigured policy locks out all admins, the break-glass accounts still sign in.
- Start in Report-only. Assess impact before enforcement; review the workbook.
- Scope least privilege. Prefer targeted include groups over All users where possible, and use exclude for exception users.
- Use named locations. Define trusted office IP ranges as named locations so you can exclude them from MFA requirements.
- Block legacy authentication. Always include a block-legacy-auth policy; legacy protocols cannot satisfy MFA and are the most common bypass.
- Don't stack too many policies. A user can match multiple policies; Entra ID applies the most restrictive intersection. Too many overlapping policies make troubleshooting hard — use the Conditional Access What If tool and the sign-in logs to see which policies matched.
- Naming convention. Name policies so the intent is obvious (for example,
CA-001-Require-MFA-All-Users-ReportOnly) — the sign-in logs show the policy name, and a clear name speeds triage.
You create a Conditional Access policy that includes All users, excludes two break-glass accounts, includes All cloud apps, and under Grant selects both 'Require MFA' and 'Require device to be marked compliant' with the 'Require all the selected controls' toggle enabled. A user signs in from an unmanaged personal device. What happens?
A new Conditional Access policy is created to require MFA for all users. Before enforcing it, the administrator wants to know how many existing sign-ins would have been interrupted. Which feature should they use, and what does it do?