HackBlue

Tools · Cloud security · 16 / 24

Microsoft Entra Conditional Access policies: a beginner walkthrough

Learn how Conditional Access combines users, apps, conditions, and controls into if-then rules, and how to roll out MFA safely with report-only mode and break-glass accounts.

11 min read · practice only with authorization

If these signals, then these controls

A Conditional Access policy is an if-then statement evaluated after the first factor of sign-in. The assignments describe who and what: users or groups, target resources such as Office 365 or the Azure management portal, and conditions such as sign-in risk, device platform, location, and client app. The access controls describe the outcome: block, or grant only if the user satisfies MFA, uses a compliant or hybrid-joined device, or accepts terms of use. Session controls can limit sign-in frequency or enforce app restrictions.

All matching policies apply together. If one policy blocks, the sign-in is blocked. If several require different grants, the user must satisfy all of them.

A sensible starting set

Most tenants start with a small set: require MFA for all users, require phishing-resistant MFA for administrator roles, block legacy authentication protocols that cannot do MFA, and require MFA for Azure management. Microsoft also publishes managed policies and templates covering the same ideas.

  • Exclude two emergency access (break-glass) accounts from every policy and monitor their sign-ins.
  • Use groups for exclusions so they are reviewable.
  • Start in report-only mode and read the impact before enforcing.

Lab: report-only first

In a developer or trial tenant, create a policy that requires MFA for a pilot group, set it to Report-only, and sign in as a pilot user. Open the sign-in log entry and select the Report-only tab: it shows whether the policy would have applied and what result it would have produced. The What If tool on the Conditional Access page gives the same prediction for a chosen user, app, and location without a real sign-in.

Only after the report-only results look right, switch the policy to On. Record which policies apply to break-glass accounts: the answer should be none that could lock them out.

Common mistakes

Excluding large groups “temporarily” and forgetting them, trusting named locations as a replacement for MFA, and forgetting that service accounts using legacy protocols will break when legacy authentication is blocked. Review exclusions on a schedule and move service workloads to workload identities or managed identities.

Diagram

How a Conditional Access decision is made

  1. First factor

    User proves the password or passkey. Signals are collected: user, app, IP, device, risk.

  2. Match policies

    Every enabled policy whose assignments match is selected.

  3. Combine controls

    Any block wins. Otherwise all required grant controls must be met.

  4. Outcome

    Access granted, MFA prompted, or blocked; the sign-in log records each policy result.

Check yourself

1. Two policies match a sign-in: one requires MFA and one requires a compliant device. What must the user do?

2. Which mode lets you see a policy’s effect in sign-in logs without enforcing it?

3. Which accounts should be excluded from every Conditional Access policy and closely monitored?