Setting Up Conditional Access Baseline Policies in Microsoft Entra ID

Whenever I take over a new Microsoft 365 tenant, the first thing I set up is three Conditional Access policies: MFA for everyone, block legacy sign-ins, and stricter rules for admins. That is not a complete security concept, but it closes the gaps through which most accounts actually get compromised.

Before you start

• License: Conditional Access requires Entra ID P1. It is included in Microsoft 365 Business Premium, E3 and E5. With Business Standard you only get Security Defaults, more on that below.
• Two emergency (break-glass) accounts: cloud-only accounts with the Global Administrator role, long passwords, stored safely. I put them in their own group and exclude that group from every policy. Forget this once and a single typo can lock you out of the tenant.
• Role: Conditional Access Administrator is enough to create the policies.

Policy 1: MFA for all users

In the Entra admin center under Conditional Access → Policies → New policy:

• Users: All users, excluding the break-glass group
• Target resources: All resources (formerly “All cloud apps”)
• Grant: Require multifactor authentication

I set the policy to Report-only first and let it run for a few days. The sign-in logs then show, per sign-in, whether the policy would have applied. This almost always turns up accounts nobody thought of: the scanner that sends mail via SMTP, or an old service account for some line-of-business app. Sort those out before enforcing, not after.

Policy 2: Block legacy authentication

Old protocols such as POP, IMAP or SMTP with username and password cannot do MFA. A stolen password is enough to sign in there, no matter what policy 1 says. Microsoft has already turned off basic auth in Exchange Online for most protocols; this policy catches the rest.

• Users: All users, excluding break-glass
• Conditions → Client apps: “Exchange ActiveSync clients” and “Other clients”
• Grant: Block access

Beforehand I filter the sign-in logs by client app “Other clients”. Anything still showing up there needs to move to modern authentication. It is usually multifunction printers or old mail clients.

Policy 3: Stricter rules for admins

Admin accounts are the most valuable target. For them, “some kind of MFA” is not enough for me:

• Users: Directory roles, at least Global, Exchange, SharePoint, User and Security Administrator; break-glass excluded
• Target resources: All resources
• Grant: Authentication strength “Phishing-resistant MFA” (FIDO2 key, passkey or Windows Hello for Business)

If you only administer from the office, you can add a policy that blocks admin roles outside your own named locations (office IPs). That only makes sense with a static IP, though. If you sometimes need to step in from your phone or from home, you are more likely to lock yourself out.

Before enforcing: What If

Under Conditional Access → Policies → What If I pick a test user, an app and, if needed, a location or device. The tool shows which policies would apply. I always test at least one regular user, one admin and one break-glass account. For the break-glass account, no policy should apply.

No P1? Security Defaults

Without Entra ID P1 you are left with Security Defaults. They enforce MFA registration and block legacy authentication, but cannot be customised and have no exclusions. For a small office that is still far better than nothing. Security Defaults and Conditional Access are mutually exclusive: to use CA, turn the defaults off first.

In short

Break-glass first, then every policy in report-only, then What If, then enforce. The order matters more than the individual settings. How this fits together with password protection and LAPS is covered in the Microsoft 365 Security Baseline.