A pragmatic Conditional Access baseline for Entra ID

Conditional Access (CA) is the policy engine at the heart of Entra ID. Done well, it quietly blocks the overwhelming majority of identity attacks. Done badly, it locks admins out and floods the service desk. Here’s the baseline I reach for on most tenants — small enough to reason about, strict enough to matter.

Start in report-only mode

Every new policy should ship in report-only first. You get the sign-in impact in the logs without breaking anyone, then flip to On once the numbers look right.

Rule of thumb: never enable a brand-new CA policy directly to On in production. Report-only for a few days is cheap insurance.

The baseline policies

#	Policy	Target	Control
1	Require MFA for all users	All users, all apps	Grant: require MFA
2	Block legacy authentication	All users	Grant: block
3	Require compliant device for admins	Directory roles	Grant: compliant or Hybrid-joined
4	Require MFA for risky sign-ins	Sign-in risk: medium+	Grant: require MFA
5	Block access from unsupported countries	All users	Named locations

Always exclude your break-glass accounts

This is the single most important detail. Maintain at least two cloud-only emergency access accounts and exclude them from every CA policy. Otherwise a single bad policy can lock the entire tenant out.

# Quick audit: list enabled CA policies and whether they have user exclusions
Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy |
    Where-Object { $_.State -eq 'enabled' } |
    Select-Object DisplayName,
        @{ N = 'ExcludedUsers'; E = { $_.Conditions.Users.ExcludeUsers.Count } } |
    Format-Table -AutoSize

If ExcludedUsers is 0 on a tenant-wide policy, stop and add your break-glass group before you do anything else.

Block legacy authentication first

Legacy protocols (IMAP, POP, SMTP AUTH, older Office clients) can’t do MFA, so they’re where password spray attacks land. Blocking them often removes more risk than any other single change:

• Check Sign-in logs → Client app to see what’s still using legacy auth.
• Migrate or retire those clients.
• Then enable the block policy in report-only, confirm impact, and switch it on.

Where to go next

Once the baseline is stable, layer on:

1. Phishing-resistant MFA (FIDO2 / passkeys) for admins.
2. Token protection and sign-in frequency for sensitive apps.
3. Authentication strength policies mapped to data sensitivity.

Keep it boring, keep break-glass excluded, and let report-only do the worrying for you.