Conditional Access without locking everyone out
The control is straightforward. Deploying it without an outage takes report-only mode, break-glass accounts and a rollout order most people get backwards.
Conditional Access is the most useful security control in Microsoft 365 and the most likely to take down your tenant for an afternoon.
Both of those are true for the same reason: it is an identity-layer control that evaluates on every sign-in, so a policy with an unintended match applies instantly, everywhere, to people who have no idea what changed.
The way to deploy it safely is well understood. It is just rarely followed in order.
Start with break-glass, before anything else
Two cloud-only accounts, in no group, excluded from every Conditional Access policy without exception, with long random passwords held in a physical safe or a sealed credential store, and sign-in alerting on both.
This is not a formality. The failure mode Conditional Access produces is a tenant where nobody can authenticate to fix the policy that stopped everybody authenticating, and the only exit is a support ticket with a multi-hour clock on it.
Two accounts rather than one, because a single break-glass account with an expired password is not a break-glass account. Test them quarterly and record that you did.
Report-only is not optional
Every policy ships in report-only first. It evaluates on every sign-in and records what it would have done, without doing it.
Leave it there for at least a full business cycle — a fortnight covers most fortnightly and monthly patterns, and it will surface the things nobody remembered: the service account that signs in from a scheduled task, the contractor on an unmanaged device, the conference room display, the mailbox that a line-of-business application reads.
Then read the sign-in logs filtered to that policy. The question is not “did it work”. The question is “who would have been blocked, and is every one of them expected”.
Inventory before you block legacy authentication
Blocking legacy authentication protocols is the highest-value single policy available, because those protocols cannot present a second factor. It is also the one that breaks the most in an environment nobody has audited.
The things that still use it are consistent and easily missed: multifunction printers scanning to email, monitoring and alerting systems, older line-of-business applications with hardcoded SMTP or IMAP, and a long tail of small integrations built by people who have left.
Run the report-only pass, get the list, fix or exempt each item deliberately, then enforce. Every one of those exemptions should have an owner and a review date, because an exemption without a date is a permanent hole with good intentions attached.
Build the policy set in rings, not all at once
The order that works:
- Break-glass exclusions established and tested.
- MFA for administrators. Small population, highest value, and the group most able to self-diagnose if something goes wrong.
- Block legacy authentication, after the inventory above.
- MFA for all users, deployed by ring: IT first, then a pilot business unit, then the rest.
- Device compliance requirements, which is where the MDM finally connects to the identity layer.
- Risk-based policies and session controls, last, because they are the ones that behave differently for different people on different days.
Each ring runs in report-only, then enforced, before the next one starts. It is slower on paper and faster in practice, because a single tenant-wide incident costs more time than the entire staged rollout.
Device compliance is where the fleet actually pays off
This is the step that converts device management from a configuration exercise into a security control.
Once compliance is a Conditional Access condition, a device that falls out of policy — unpatched, non-compliant, or flagged by mobile threat defence — loses access to corporate data automatically, without a human reading an alert. That is the difference between telemetry and enforcement, and it is worth the entire MDM investment on its own.
Two things to get right. Make sure the compliance signal from the mobile fleet is actually reaching the identity layer, rather than sitting in a console nobody watches. And decide in advance what “non-compliant” should do — block outright, or allow web-only access with no download — because the harsher setting generates the support calls.
The things people get wrong
- Policies that overlap without anyone mapping them. Conditional Access policies combine, and blocks always win. Two reasonable policies can intersect into a rule neither author intended.
- Excluding a group rather than fixing a case. The exclusion group grows quietly until it is most of the organisation.
- No documented change process. These policies deserve the same change control as a firewall rule, for the same reason.
- Nobody watching the sign-in logs after enforcement. The first 48 hours are where you find what report-only missed.
The short version
Conditional Access fails in deployment, not in design. Break-glass accounts first, report-only for a full business cycle, an inventory before you block legacy protocols, and a ringed rollout with one change at a time.