SECURITY
Conditional Access policies worth having before anything else
5 min read
A workable Conditional Access baseline is a small number of policies — administrator protection, legacy authentication blocking, device compliance and session control — each deployed in report-only mode first and each with break-glass accounts excluded.
Conditional Access can express almost anything, which is why so many tenants end up with thirty overlapping policies that nobody can reason about and nobody dares change.
A smaller set, each with a clear job, covers most of the risk and stays maintainable. Here is the set worth starting from, and the order to apply it in.
Before any policy: break-glass accounts
Two accounts, excluded from every Conditional Access policy, with long random passwords stored outside the systems they protect, no routine use, and alerting on any sign-in.
This is not optional and it goes first. Conditional Access is entirely capable of locking every administrator out of the tenant, including the one trying to fix it, and the recovery path without a break-glass account is a support case measured in hours.
The policies that earn their place
Each of these addresses a distinct failure mode rather than a variation of the same one.
- Require multifactor authentication for all administrator roles — the highest-value accounts, protected first
- Block legacy authentication — the protocols that bypass multifactor entirely
- Require multifactor for all users, with the exemption list explicit and reviewed
- Require a compliant or hybrid-joined device for access to company data
- Require multifactor for risky sign-ins, where risk signals are available
- Restrict or control access from unmanaged devices, usually via session controls rather than an outright block
Why legacy authentication comes early
Legacy authentication protocols do not support multifactor. An account protected by every multifactor policy you have written is still reachable with a password alone if legacy authentication is available to it.
Blocking it is the single highest-value policy in the list, and it is also the one most likely to break something — an old mail client, a scanner that sends email, a line-of-business application with hardcoded credentials. Report-only mode finds all three before they become tickets.
Report-only is the whole method
Every policy goes in report-only first, for long enough to cover a full working cycle including whoever works weekends and whoever travels. The sign-in logs then show exactly which accounts and applications would have been blocked.
A fortnight is usually enough. A policy that is enforced without this step is a policy whose blast radius you are about to learn from your service desk.
Keeping it maintainable
Name policies so the name states what they do and who they apply to, because the next person to read them will be doing so during an incident. Keep exclusions in named groups rather than listing individuals inside the policy, so the exclusion list can be reviewed as a thing in itself.
And review the exclusions on a schedule. Every baseline degrades the same way: exceptions granted for a reason, never revisited, until the policy no longer covers the people it was written for.
Questions we get asked
How many Conditional Access policies should we have?
Fewer than most tenants end up with. Six to ten well-named policies covering distinct failure modes is maintainable. Thirty overlapping ones usually means policies were added for individual cases rather than exclusions being managed in groups.
Are security defaults enough instead of Conditional Access?
They are a reasonable starting point for a small tenant with no licensing for Conditional Access, and much better than nothing. They are all-or-nothing, so they cannot express exemptions or device conditions, which is why most organisations move past them as soon as they have a service account or a legacy system.
How often should break-glass accounts be checked?
Test that they work at least every quarter and whenever policies change significantly, because an untested break-glass account is an assumption rather than a control. Any sign-in outside those tests should raise an alert.