Setting Up Conditional Access Policies in Microsoft Entra ID
A practical guide to creating Conditional Access policies in Microsoft Entra ID to enforce MFA, block risky sign-ins, and require compliant devices for Microsoft 365 access.
Overview
Conditional Access is Microsoft Entra ID's policy engine that controls who can access what, from where, and under what conditions. It is the foundation of a Zero Trust security model for Microsoft 365. Instead of blanket MFA for everyone, Conditional Access lets you create granular rules: require MFA from untrusted networks, block legacy authentication, and demand device compliance before granting access.
This guide walks through the essential policies every organisation should implement.
Prerequisites
- Microsoft Entra ID P1 licence (included in Microsoft 365 Business Premium, E3, E5)
- Global Administrator or Conditional Access Administrator role
- At least one break-glass (emergency access) account excluded from all policies
- MFA registration completed for all users before enforcing MFA policies
Always create and test a break-glass account before enabling Conditional Access policies. If you lock yourself out, you need an account that bypasses all policies to regain access. Use the dedicated Exclude option in each policy to exclude your break-glass accounts, and set up an alert rule in Microsoft Entra ID to notify you if the break-glass account is used. Store its credentials in a physical safe, not in a password manager that requires Microsoft Entra ID to sign in.
Policy 1: Require MFA for All Users
This is the single most impactful security control you can implement.
Configuration
- Go to the Microsoft Entra admin center (entra.microsoft.com) > Protection > Conditional Access > Create new policy
- Name: Require MFA — All Users
- Assignments:
- Users: All users
- Exclude: Break-glass accounts, service accounts that cannot support MFA
- Target resources: All cloud apps
- Conditions: None (apply to all conditions)
- Grant: Require multi-factor authentication
- Session: Not configured
- Enable policy: Report-only (test first, then switch to On)
Number matching is now mandatory for Microsoft Authenticator push notifications (enforced since May 2023). Users are prompted to enter a number displayed on the sign-in screen to approve the notification, which mitigates MFA fatigue attacks. For the strongest protection, recommend passkeys and FIDO2 security keys as a phishing-resistant MFA method. You can enforce this using the Authentication strengths Grant control, which lets you require phishing-resistant MFA for sensitive resources.
Always start policies in Report-only mode. Review the sign-in logs for 1-2 weeks to identify users or apps that would be blocked, then switch to On once you are confident there are no unintended impacts.
Policy 2: Block Legacy Authentication
Legacy protocols (POP3, IMAP, SMTP AUTH, older Exchange ActiveSync) do not support MFA and are the most common entry point for credential-stuffing attacks.
Microsoft has fully disabled basic authentication for Exchange Online protocols as of September 2025. Creating this policy is still recommended as a defence-in-depth measure to block any remaining legacy client app types across all cloud applications, not just Exchange Online.
Configuration
- Name: Block Legacy Authentication
- Users: All users (exclude break-glass accounts)
- Target resources: All cloud apps
- Conditions > Client apps: Select only Exchange ActiveSync clients and Other clients
- Grant: Block access
- Enable: Report-only first
Verify before enforcing
Check the Microsoft Entra sign-in logs filtered by Client app = "Other clients" and "Exchange ActiveSync". If users are still using legacy mail clients, migrate them first.
Policy 3: Require Compliant Device for Desktop Apps
If your devices are managed by Intune, you can require that only compliant devices can access company data.
Configuration
- Name: Require Compliant Device — Desktop Apps
- Users: All users (exclude break-glass accounts)
- Target resources: Office 365 (or specific apps like Exchange Online, SharePoint)
- Conditions > Device platforms: Windows, macOS
- Grant: Require device to be marked as compliant
- Enable: Report-only first
Pair this with an Intune compliance policy that requires BitLocker encryption, up-to-date OS, and active antivirus. Non-compliant devices will be blocked from accessing email and files until they meet the requirements.
Policy 4: Block Access from High-Risk Countries
If your organisation operates in specific countries, block sign-ins from everywhere else.
Step 1 — Create a named location
- Go to Protection > Conditional Access > Named locations
- Click Countries location
- Name it "Allowed Countries" and select the countries where your staff operate
Step 2 — Create the policy
- Name: Block Sign-In — Unapproved Countries
- Users: All users (exclude break-glass accounts)
- Target resources: All cloud apps
- Conditions > Locations: Include Any location, Exclude Allowed Countries
- Grant: Block access
Policy 5: Require MFA for Risky Sign-Ins
If you have Microsoft Entra ID P2, you can use Microsoft Entra ID Protection (formerly Azure AD Identity Protection) risk signals to require MFA only when a sign-in looks suspicious.
Configuration
- Name: Require MFA — Risky Sign-Ins
- Users: All users
- Target resources: All cloud apps
- Conditions > Sign-in risk: Medium and High
- Grant: Require multi-factor authentication
This reduces MFA friction for normal logins while catching suspicious ones.
The legacy User Risk Policy and Sign-in Risk Policy configuration pages in Microsoft Entra ID Protection became read-only on July 31, 2025 and the UI will be fully retired on October 1, 2026. If you still manage risk policies from those legacy pages, migrate them to Conditional Access policies now. Creating risk-based policies directly in Conditional Access (as shown above) is the supported path going forward.
Recommended Policy Set Summary
| Policy | Target | Grant | Priority |
|---|---|---|---|
| Require MFA — All Users | All users, all apps | Require MFA | Essential |
| Block Legacy Authentication | All users, legacy clients | Block | Essential |
| Require Compliant Device | All users, desktop platforms | Require compliance | High |
| Block Unapproved Countries | All users, risky locations | Block | High |
| Require MFA — Risky Sign-Ins | All users, risky sign-ins | Require MFA | Medium (requires Entra ID P2) |
Testing Policies
Report-only mode
Every policy should run in report-only mode for at least one week before enforcement. Review results at:
Microsoft Entra admin center > Sign-in logs > add filter Conditional Access = "Report-only: Failure"
This shows which sign-ins would have been blocked if the policy were active.
What-If tool
Use the built-in What-If tool to simulate policies:
- Go to entra.microsoft.com > Protection > Conditional Access > What If
- Select a user, an application, and conditions (location, device platform)
- Click What If to see which policies would apply and what the result would be
Troubleshooting
| Issue | Cause | Fix |
|---|---|---|
| Users blocked unexpectedly | Policy too broad or missing exclusion | Check sign-in logs, add exclusions as needed |
| MFA not prompted | Legacy client bypassing MFA | Create the Block Legacy Authentication policy |
| "You cannot access this" on mobile | Compliance policy blocking personal devices | Create a separate policy for mobile with app protection instead of device compliance |
| Service account blocked | Service account not excluded | Add to exclusion group, consider using managed identity instead |
| Break-glass account locked out | Account included in policy by mistake | Always use a dedicated exclusion group for emergency accounts |
Next Steps
- Enable Microsoft Entra ID Protection for user and sign-in risk policies
- Configure Microsoft Entra Privileged Identity Management (PIM) to enforce just-in-time access for admin roles
- Configure session controls (sign-in frequency, persistent browser sessions) for sensitive apps
- Explore authentication strengths to require phishing-resistant MFA (passkeys, FIDO2) for privileged operations
- Audit policies quarterly and remove any in report-only mode that have been validated
Related Articles
Was this article helpful?