The 5 Conditional Access Mistakes That Lock Users Out (And How to Fix Them)

One wrong Conditional Access policy and your entire organization is locked out. No exceptions. Not some users — everyone, including you.
These are the five mistakes I see most often. Each one has locked out real users in real environments.

Mistake 1: No break-glass account
This is the one that causes the most damage. A break-glass account is a cloud-only Global Administrator account that is excluded from every single Conditional Access policy. Its only purpose: if a misconfigured policy locks out all admins, you can still get in and fix it.
Most environments don't have one until after the first lockout.
How to set it up correctly:
Create a cloud-only account — not synced from on-prem AD. Something like [e-mail]. Assign Global Administrator permanently, not via PIM. Use a long random password stored offline. Register MFA using a FIDO2 hardware key, not an authenticator app tied to a personal phone. Exclude this account from every Conditional Access policy you create. Monitor sign-ins — any login from this account should trigger an alert immediately.
Never skip this step. Microsoft explicitly recommends break-glass exclusions in every CA policy tutorial in their documentation for good reason.

Mistake 2: Enabling "Require compliant device" before devices are enrolled
This is the fastest way to lock out your entire user base in one click.
What happens: you enable the policy targeting All Users, and every user whose device is not yet enrolled in Intune and marked compliant gets blocked from everything — including the Intune portal they need to enroll.
The correct order:

Create an Intune compliance policy first
Confirm at least one device is enrolled and marked compliant
Start with a pilot group of 10-20 users, not All Users
Use the flexible version first: require compliant device OR MFA — this gives unenrolled users a fallback instead of a hard block
Expand to All Users only after full enrollment is complete

If you are not ready to enforce device compliance for everyone, use the flexible policy. It is always better than a hard block on day one.

Mistake 3: Not using Report-only mode first
Every new Conditional Access policy should start in Report-only mode. In this mode the policy is evaluated but not enforced — users are not blocked or prompted. You see exactly who would be affected before anything happens.
Most lockouts happen because someone created a policy, set it to On immediately, and did not check the impact first.
The correct flow:

Create policy → set Enable policy to Report-only → Save
Wait 24-48 hours
Review sign-in logs: Entra Admin Center → Monitoring → Sign-ins → Conditional Access tab
Use the What If tool to simulate specific users and scenarios
Only switch to On after confirming the impact is what you expected

This costs you 24 hours. Skipping it can cost you hours of emergency recovery.

Mistake 4: Blocking legacy authentication without checking who uses it
Blocking legacy authentication is one of the highest-value CA policies you can enable — over 99% of password spray attacks use legacy auth protocols. But if you enable it without checking first, you will block legitimate users.
Common legacy auth users that get missed:

Older printers and scanners sending email via SMTP
Shared mailboxes accessed via older Outlook versions
On-premises applications authenticating via basic auth
Some conferencing equipment

How to check before enabling:
Go to Entra Admin Center → Monitoring → Sign-ins → filter by Client app → select Exchange ActiveSync and Other clients. Any sign-ins showing here are using legacy authentication. Document them before you block anything.
Then enable the policy in Report-only mode, review the impact, handle the exceptions, and only then turn it on.

Mistake 5: Forgetting that all policies apply simultaneously
This is a logic mistake that creates unexpected blocks.
Conditional Access policies are not evaluated one at a time — all applicable policies must be satisfied simultaneously. If Policy A requires MFA and Policy B requires a compliant device, the user must complete both MFA AND use a compliant device. There is no "first match wins" logic.
This creates problems when:

You have a policy requiring MFA for all users
And a separate policy requiring a compliant device for all users
And a user is on an unenrolled device

They cannot satisfy the compliant device requirement, so they are blocked — even though your intention was to allow MFA as a fallback.
Fix: think through policy combinations carefully. Use the What If tool to simulate specific users before enabling. And when in doubt, use OR logic in grant controls instead of AND.

The safe rollout order
If you are starting from scratch, enable policies in this order:

Create break-glass accounts first — non-negotiable
Disable Security Defaults
Create all policies in Report-only mode
Review sign-in logs for 24-48 hours
Enable Block legacy authentication — low user impact, high security gain
Enable MFA for all users — communicate to users first
Enable device compliance — start with pilot group only

Never enable everything at once. One policy at a time, Report-only first.

I put together a complete playbook covering all 10 essential Conditional Access policies with exact configuration steps, the full safe rollout order, 5 lockout scenarios with fixes, and a 28-item implementation checklist — all sourced from official Microsoft documentation.
Get it here: https://exactey.gumroad.com/l/ConditionalAccess-IntuneCompliance
Questions? Drop them in the comments.
Sources: learn.microsoft.com/en-us/entra/identity/conditional-access