Conditional Access That Won't Get You Fired

Most Conditional Access disasters look the same: someone flips a big switch in production on a Friday, and by Monday the helpdesk is on fire. The fix isn't to avoid Conditional Access — it's to roll it out like an engineer, not a gambler.

Start in report-only

Every new policy should be born in report-only mode. You get the sign-in logs and the "would this have blocked" signal without breaking a single login. Let it bake for a week, review the impact in the sign-in logs, then enforce.

If you can't explain what a policy will block before you enforce it, you're not ready to enforce it.

The baseline that covers 90% of attacks

Here's the core set I deploy on almost every tenant:

• Require MFA for all users — with a break-glass account excluded.
• Block legacy authentication — this single policy kills the majority of password-spray success.
• Require compliant or hybrid-joined devices for access to sensitive apps.
• Require MFA for risky sign-ins using Identity Protection signals.
• Block access from unsupported or unexpected countries.

Don't forget the break-glass account

Two cloud-only global admin accounts, excluded from all Conditional Access, with long random passwords stored offline. Monitor them with an alert. If you ever lock yourself out, these are the accounts that save your weekend.

Measure it

After enforcement, watch three things: failed legacy auth attempts (should be near zero), MFA registration coverage, and helpdesk tickets tagged "can't sign in." If tickets spike, you rolled out too fast — dial back, communicate, and stage it.

Conditional Access done well is invisible to good users and a brick wall to attackers. Done badly, it's a career-limiting move. The difference is entirely in the rollout.