Conditional Access policies that hold, and the emergency account you must create first

Before anything else in this article: create two break-glass accounts, cloud-only, with long random passphrases stored in a physical safe or a separate password vault, excluded from every Conditional Access policy you ever write, with sign-in alerts routed to the security team.

This is not a formality. The most common Conditional Access incident is not a bypass — it is an organisation that requires a compliant device for all users including the administrators, deploys it from a compliant device, and then discovers that nobody can sign in to undo it. Excluded emergency accounts are the only way out of that room.

The baseline set

These are the policies we deploy for essentially every organisation, in report-only mode first.

1. Require MFA for all users. Not just admins. The attack that works today is password spraying against the one account that was exempted. Use the authentication strength setting to require phishing-resistant methods (FIDO2 keys, passkeys, certificate-based auth) for administrators — a push notification is no longer a sufficient control for a Global Administrator.

2. Block legacy authentication. POP, IMAP, SMTP AUTH and older Office clients cannot do MFA, so any policy requiring MFA is silently bypassed by them. This must be a separate explicit block. Check sign-in logs for legacy auth first; there is always one scanner or one line-of-business application still using it, and it needs a plan before you block.

3. Require MFA for Azure management. The Windows Azure Service Management API target covers the portal, CLI and PowerShell. Separate from the general MFA policy so the requirement holds even if you later carve exceptions.

4. Block access from countries you do not operate in. A blunt control with real value against commodity attacks. Named locations, allow-list style. Expect to maintain it for travelling staff.

5. Require compliant or hybrid-joined devices for privileged roles. This is the one that most reduces risk from a stolen credential, and the one most likely to cause a lockout, which is why it comes after the break-glass accounts and after the report-only period.

6. Sign-in risk and user risk policies. With Entra ID P2, require MFA on medium sign-in risk and force a password change on high user risk. These react to signals nothing else sees.

7. Session controls for unmanaged devices. Sign-in frequency and no persistent browser session when the device is not compliant. This limits the window a stolen session token is useful for.

Deploy in report-only, always

Every policy starts in report-only mode. Leave it for at least two weeks, then use the What If tool and the sign-in logs filtered by that policy to see exactly who would have been blocked. There will be service accounts, a conference room device and one integration nobody remembered. The report-only period is how you find them without an incident.

Then enable one policy at a time, with a day between each. A batch of five policies enabled simultaneously produces a failure you cannot attribute.

The gaps to close alongside

Conditional Access does not cover everything, and three gaps matter:

• Service principals and workload identities. They are not users and most Conditional Access policies do not apply. Use Workload Identity Premium for location and risk conditions on service principals, and audit which ones have credentials that never expire.
• Consent to third-party applications. Restrict user consent to verified publishers with low-impact permissions, and route the rest to an admin consent workflow. Illicit consent grants are a well-worn path into a tenant and no MFA policy stops them.
• Guest access. Cross-tenant access settings decide what partner organisations can do. Default settings are more permissive than most people expect; review them explicitly.

Standing privilege is the other half

A perfect Conditional Access baseline with twelve permanent Global Administrators is not a secure tenant. Privileged Identity Management, eligible rather than active assignments, activation with justification and approval, expiry on every elevation, alerts on activation. Aim for zero standing Global Administrators and fewer than five people eligible.

We deploy these together in a security engagement, because each undermines the other when done alone.

What to do this week

Create the two break-glass accounts and exclude them from every existing policy. Then open the sign-in logs, filter for legacy authentication over the last 30 days, and list what shows up. Those two actions are the prerequisites for everything else here.