Conditional Access is the single most consequential surface in an Entra tenant, and also the easiest one to configure into a state that feels secure, passes the tick-box review, and breaks under any serious scrutiny. Here's what actually survives audit.

Start from a named baseline

Every policy should have a name that encodes its scope, purpose and state: BASE-001-BlockLegacyAuth-All-On, USER-014-RequireMFA-Finance-On. The convention looks pedantic until an auditor asks why you have 38 policies and which one enforces MFA for guests.

"Block legacy auth" is necessary, not sufficient

It's table stakes. The interesting question is what you do after legacy auth is blocked — because attackers move to token theft, consent phishing, and device-code abuse. A modern baseline includes:

  • Legacy auth blocked (obviously).
  • Require device compliance or hybrid join for resource access.
  • Require phishing-resistant MFA for privileged roles, not just "any MFA."
  • Block or require step-up MFA for device code flow — the sleeper risk most tenants still allow.
  • Session controls on unmanaged browsers (prevent download, token lifetime reduced).

Named locations, used correctly

Named locations are useful for trust, not for blocking. A policy that trusts the HQ IP range to skip MFA is reasonable; a policy that blocks sign-ins from "anywhere except Italy" is cargo-cult security that breaks on day one when someone travels. The pattern I use: trusted locations raise the device-compliance floor but never lower the MFA floor.

Device-state signals

The strongest CA signal is device compliance joined with user risk. "User is low risk AND device is compliant" is the only condition under which I'll allow session persistence; everything else gets a shorter token lifetime and re-auth.

Three gotchas I keep hitting

  • Guest accounts bypass most policies unless you explicitly scope them. Put guests in their own user-assignment bucket.
  • Break-glass accounts must be excluded from every policy, stored in a physical safe, and monitored for sign-in via a separate alerting rule. Not one of those three steps. All three.
  • Report-only mode is your friend, but only if you actually review the reports. Set a calendar reminder. Every week.

The audit checklist

When a SOC 2 or ISO auditor asks about CA, what they actually want is evidence that: (a) policies exist for privileged access, (b) legacy auth is blocked, (c) break-glass accounts have compensating controls, and (d) changes to CA policies are logged and reviewed. Every tenant I've handed off has a one-page PDF that answers exactly those four questions with screenshots.