10.3 Planning & Implementing Conditional Access Policies

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

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

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:

1. Require MFA for all users — Include All users, exclude break-glass; All cloud apps; Grant with MFA. This is the baseline.
2. 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.
3. 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.
4. 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

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.