Almost everyone who has run Entra ID for any length of time has a Conditional Access story, and it usually ends badly. Someone builds a sensible-looking policy, flips it straight to On, and within the hour the service desk is lighting up. Or worse: the person who built it can no longer sign in to turn it off. Conditional Access is one of the most powerful controls you have, and one of the easiest to hurt yourself with.
The mistakes are predictable, though. The same handful come up again and again, and none of them are exotic. Here are the ones worth knowing before you go near a production tenant.
Break-glass accounts first, and exclude them from everything
This is the one that saves you, so do it before anything else. You need at least two emergency access accounts: cloud-only, each with its own FIDO2 key or certificate (mandatory MFA applies to them too), not tied to any individual, and excluded from every Conditional Access policy you ever create.
The reasoning is blunt. Conditional Access can lock out everyone, and that includes you. A policy that demands a compliant device or a particular authentication method can, if it’s wrong, leave nobody able to sign in to switch it off. The break-glass accounts are your way back in. People skip this because it feels paranoid, right up until the afternoon it’s the only thing standing between them and a support ticket to Microsoft.
Exclude them from everything, then watch them like a hawk. Alert on every sign-in, because an account that bypasses all your controls is exactly what an attacker would love to find. There’s more on setting break-glass accounts up properly, including the alert query.
How do you roll out a policy without locking everyone out?
Report-only mode is the single best habit in Conditional Access, and the one most people skip because they’re in a hurry. A new policy set to report-only is evaluated against every sign-in and logged, but it doesn’t actually enforce anything. You get to see precisely who it would have blocked, and what it would have demanded, before it can do any damage.
Leave it there for a week or two and read the sign-in logs. You’ll nearly always find something you didn’t expect: a service account authenticating in a way you’d forgotten about, a group of users on a platform the policy quietly catches, a legitimate workflow you were about to break. Fix those first. Only then flip it to On.
The temptation to skip this is strongest exactly when you shouldn’t, when the policy feels obvious and low-risk. Those are the ones that bite.
Block legacy authentication: the high-value policy you’re putting off
If you do nothing else this year, block legacy authentication. Older protocols that predate modern auth, basic auth endpoints, legacy mail clients speaking POP, IMAP or SMTP AUTH, have no way to perform an MFA challenge. Conditional Access still sees them, but a policy that requires MFA can never be satisfied by them. Unless you block them outright, a password alone gets through. This is exactly why password spray attacks still work in 2026: attackers deliberately target the legacy endpoints because they know MFA won’t be in the way.
The reason people delay is that they’re not sure what still depends on it, and they’re afraid of breaking something. Which is fair. So this is another one for report-only first: switch on a block-legacy-auth policy in report-only, watch what gets caught, chase down whatever’s still using it, and migrate it. The boring legwork is the actual job here. The policy itself takes thirty seconds.
Report-only turns “I don’t know what’ll break” into a list of names.
“All users, all apps” is a bigger blast radius than it looks
It’s tempting to scope a policy to everyone and everything because it feels thorough. Sometimes that’s right. Often it’s how you catch the one account or workload you really shouldn’t have.
Think about the blast radius before you save. Who is genuinely in scope, and what happens to the edge cases: the guests, the service principals, the accounts synced from on-premises, the break-glass accounts, the one team with a workflow that doesn’t fit the rule? Scope deliberately, exclude what needs excluding, and know what you’re aiming the thing at. A precise policy you understand beats a broad one you’re nervous about.
Don’t build forty policies you’ll never understand again
Conditional Access estates rot the same way permissions do. Someone adds a policy for a one-off project, names it “Test 3,” and never removes it. A year later there are thirty-odd policies, several overlapping, a couple contradicting each other, and nobody fully sure what the live behaviour actually is.
Keep the set small and name them so a stranger could read the list and understand your intent: who, what, and the condition, right there in the name. Review them on a schedule, because they will drift, and the drift is invisible until an incident forces you to read every one. The hard part isn’t technical, it’s the discipline to delete the policy nobody remembers creating.
Test it before you trust it
Microsoft gives you a What-If tool that simulates how your policies apply to a given user, app and condition. Use it. It costs nothing and it’ll show you interactions between policies you wouldn’t spot by reading them one at a time: the two that combine to block someone, or the exclusion that quietly cancels the control you thought you’d applied.
Between What-If and report-only logs, you’ve no real excuse to be guessing. A Conditional Access policy you haven’t tested is a policy you’re hoping about, and hope isn’t a control.
What good Conditional Access looks like
Good Conditional Access means a small set of policies you understand, can explain, and can stand over at 2am when something fires, rather than the most policies. Build them slowly, roll them out in report-only, exclude your way back in, and document what each one is for. None of it needs cleverness, just care, and care counts for a lot when one wrong toggle can lock out the building.
Originally published at alanconlon.com, where I post practical security, Azure and data write-ups every other Tuesday.
Top comments (0)