How to Set Up a Conditional Access Policy in Microsoft Entra ID

TL;DR: In the Microsoft Entra admin center, go to Entra ID > Conditional Access > Policies > New policy. Pick a who (Users), a what (Target resources), an optional condition (location, device state, risk), and a control (Require MFA, Require compliant device, Block). Always create with Enable policy = Report-only first, watch the sign-in logs for 48 hours, then flip to On.

Conditional Access is the workhorse of Microsoft 365 security. It’s what enforces “MFA for everyone except corporate-IP traffic from Intune-compliant devices” and a hundred other access patterns. This guide builds one policy end-to-end and covers the rollout discipline that keeps you from locking yourself out.

What this does

A Conditional Access policy evaluates every sign-in against three things:

  • Assignments — who the policy applies to (users, groups, directory roles) and what they’re trying to access (resources, user actions like security info registration)
  • Conditions — sign-in attributes (location, device platform, client app, sign-in risk, user risk)
  • Access controls — what to do when conditions match (grant with MFA, block, require compliant device, limit session lifetime)

If a sign-in matches all the assignments and conditions, the access controls run. If multiple policies apply, all their grant controls combine — the most restrictive set wins.

When you’d want this

  • Requiring MFA on Microsoft 365 access (the most common policy on every tenant)
  • Blocking legacy authentication protocols that bypass MFA
  • Requiring corporate-managed devices for sensitive apps
  • Restricting access by geography (block sign-ins from countries you don’t operate in)
  • Forcing reauthentication on a session lifetime for browser sessions
  • Responding to risky sign-ins or risky users from Microsoft Entra ID Protection

Prerequisites

  • Microsoft Entra ID P1 or P2 license. Included in Microsoft 365 Business Premium, E3, F3, A3, E5, A5.
  • Conditional Access Administrator role at minimum. Use this — not Global Administrator — for routine policy work.
  • Break-glass accounts documented. At least one (preferably two) emergency-access accounts that are excluded from every policy you build, with offline-stored credentials and monitoring on their sign-ins.
  • Security defaults disabled. Conditional Access and security defaults can’t coexist; the admin center will block one if the other is on.

Steps

We’ll build the most common starter policy: require MFA for all users when accessing all cloud apps, with break-glass exclusions.

1. Open the Conditional Access blade

  1. Sign in to the Microsoft Entra admin center at https://entra.microsoft.com as a Conditional Access Administrator.
  2. Go to Entra ID > Conditional Access > Policies.
  3. Select New policy.

2. Name the policy

Use a naming standard from day one. Something like:

CAxxx — <Action> for <Audience> on <Target> — <State>

Example: CA001 — Require MFA for all users on all cloud apps — Production. The number lets you keep policies in stable order; the suffix lets you have report-only twins of policies in flight.

3. Set Assignments — Users

Select Users or workload identities.

  • Include: All users.
  • Exclude:
    • Select Users and groups > pick your break-glass accounts (or the security group containing them).
    • If you use Microsoft Entra Connect or Microsoft Entra Connect Cloud Sync, select Directory roles and exclude Directory Synchronization Accounts so service accounts don’t fail.

Excluding break-glass accounts is non-negotiable. If you skip this and the policy turns out to be too aggressive, you have no way back in.

4. Set Target resources

Select Resources (formerly cloud apps).

  • Include: All resources (formerly ‘All cloud apps’).

For more targeted policies, you can pick specific apps here (Office 365, Microsoft Admin Portals, Windows Azure Service Management API, custom enterprise apps).

5. Set Conditions (optional)

For a basic “always require MFA” policy, leave conditions unset. For more nuanced policies you can add:

  • Sign-in risk / User risk (requires Microsoft Entra ID P2)
  • Device platforms — iOS, Android, Windows, macOS
  • Locations — including or excluding named locations (corporate IP ranges, countries)
  • Client apps — modern auth, Exchange ActiveSync, legacy clients
  • Filter for devices — based on Intune compliance or hybrid join state

6. Set Access controls — Grant

Select Grant.

  • Select Grant access.
  • Check Require multifactor authentication.
  • Select Select.

For other common patterns:

  • Require device to be marked as compliant — pairs with Intune compliance policies
  • Require Microsoft Entra hybrid joined device — for tenants with traditional domain-joined Windows
  • Require approved client app — for mobile, restricts to apps that support Intune App Protection
  • Block access — for blanket denies (e.g., legacy authentication, unsupported countries)

7. Set Enable policy to Report-only

This is the most important step. Always start with Report-only so you can see what the policy would have done without enforcing it.

  1. Set Enable policy to Report-only.
  2. Select Create.

8. Monitor for 24-72 hours

The policy now runs on every sign-in but doesn’t enforce anything. Check its impact:

  1. In Microsoft Entra > Monitoring > Sign-in logs, filter by your policy.
  2. Look at the Conditional Access column — does it show the policy applying when you’d expect, and not applying to your break-glass accounts?
  3. Check What If at the top of the Conditional Access > Policies page: simulate sign-ins for representative users to see which policies match.
  4. Use the Conditional Access insights and reporting workbook for tenant-wide visualizations.

9. Flip to On

When you’re confident the policy applies as intended:

  1. Edit the policy.
  2. Change Enable policy from Report-only to On.
  3. Save.

The policy is now enforcing.

For a new tenant, build these in order:

  1. Block legacy authentication — required first; otherwise MFA can be bypassed
  2. Require MFA for all users (the policy above)
  3. Require MFA for admins on all admin portals (extra protection on privileged ops)
  4. Block unknown device platforms — defense against device platform spoofing
  5. Sign-in frequency: 1 hour for non-managed devices (session controls)
  6. Geo-fence to operating countries — if applicable

The Microsoft Entra admin center has policy templates that scaffold each of these. Use them; don’t reinvent.

Notes and gotchas

  • Report-only is your friend. Every policy starts there. Always.
  • What If is your other friend. Before flipping to On, simulate sign-ins for at least three personas: a regular user, an admin, and a break-glass account. Confirm the right policies apply (and don’t apply) to each.
  • Multiple policies stack — restrictively. If two policies match a sign-in, all of their grant controls apply. Plan for the union.
  • Break-glass exclusions on every policy. Build a security group named something like CA-BreakGlass, put the emergency accounts in it, and exclude that group from every CA policy at creation time. Audit monthly.
  • CA policies don’t cover everything. They run on Microsoft Entra ID sign-ins. They don’t cover legacy on-premises Active Directory authentication, certain B2B flows with non-Entra IDPs, or some service-to-service token issuance.
  • Synced identity caveat: Directory Synchronization Accounts service accounts (used by Microsoft Entra Connect) need to be excluded explicitly or sync breaks.
  • Token lifetime ≠ policy enforcement timing. CA evaluates at sign-in. Existing tokens stay valid until they expire even if you tighten the policy. Use Sign-in frequency session controls if you need to force reauthentication.
  • License gotcha: Conditional Access uses the user’s license at sign-in time, not the policy author’s. If you target users who don’t have Microsoft Entra ID P1, the policy won’t apply to them.

Related guides