Setting Up Conditional Access Baseline Policies in Microsoft Entra ID

In this post I walk through three Conditional Access baseline policies in Microsoft Entra ID that make sense in almost any environment: enforcing MFA for all users, blocking legacy authentication, and restricting access for administrative roles.

Why Conditional Access?

Conditional Access is the central tool in Entra ID for controlling access based not just on username and password, but on signals like location, device state, application, and risk level. Instead of enforcing the same security bar for everyone, policies can be tailored to specific groups, apps, and conditions.

Prerequisites

• Microsoft Entra ID P1 or P2 license (included in Microsoft 365 Business Premium and most E3/E5 plans)
• At least two break-glass admin accounts excluded from all policies
• Conditional Access Administrator or Security Administrator role

Policy 1 — Require MFA for all users

In the Entra admin center under Protection → Conditional Access → Policies → New policy, I set:

• Users: All users, exclude break-glass accounts
• Cloud apps: All cloud apps
• Access controls: Grant, condition “Require multi-factor authentication”

I enable the policy in report-only mode first, check the impact in the sign-in logs, and only then switch it to enforced.

Policy 2 — Block legacy authentication

Older protocols such as POP, IMAP, or legacy Office clients don’t support MFA and are a common entry point for attacks. The policy:

• Conditions → Client apps: select “Other clients” and “Exchange ActiveSync clients”
• Access controls: Block access

Before enforcing, it’s worth checking the sign-in logs filtered by client app “Other clients” to spot any legacy connections that are still active before locking them out.

Policy 3 — Restrict access for administrative roles

For accounts with privileged roles (Global Admin, Exchange Admin, SharePoint Admin, etc.) I further restrict access to trusted locations:

• Users: select directory roles (e.g. Global Administrator)
• Locations: all locations except the defined named locations (office IPs)
• Access controls: Block

Testing with the “What If” tool

Before a policy goes live, I test it in the Conditional Access section under “What If” with a specific test user, target app, and location. That shows which policies would apply beforehand, without risking real sign-ins.

Conclusion

These three policies cover the most common attack vectors: missing MFA, outdated protocols, and unprotected admin accounts. The key is to watch every policy in report-only mode before enforcing it — and to always keep at least one break-glass account outside every policy.