Conditional Access Without the Lockouts

Sample post — replace with your own writing.

Every Conditional Access horror story has the same shape: someone scopes a policy to All users, requires a compliant device, and clicks save. Minutes later the help desk lights up, and the one account that can fix it is also locked out.

Aggressive policy is good. Getting locked out is not. These four habits let you have the first without the second.

1. Always keep break-glass accounts

Create at least two cloud-only emergency accounts that are excluded from every Conditional Access policy, stored offline, and monitored for any sign-in. They are the fire extinguisher you hope never to use — but the rollout below assumes they exist.

2. Start in report-only mode

Conditional Access has a report-only state that evaluates the policy and logs what would have happened without enforcing it. Ship every new policy report-only first, then read the sign-in logs:

Which sign-ins would have been blocked?
Are any of them service accounts or legitimate edge cases you forgot?

Only promote to On once the report-only data is boring.

3. Exclude, then narrow

It is far safer to launch with broad exclusions and remove them than to launch tight and add them under pressure. Exclude your break-glass accounts and any known automation up front, enforce, then tighten the exclusions deliberately.

4. Treat policies as code

Hand-clicked policies drift and nobody remembers why an exclusion exists. Export your policy set, keep it in version control, and review changes the way you review any other production change. The audit trail is a bonus; the real win is that “why is this account excluded?” has an answer in the git history.

None of this slows the rollout down. Report-only and staged exclusions are how you move faster, because you stop being afraid of the save button.