Six policies, in a specific order, with the break-glass account built before any of them. Each one in report-only for a week before it blocks anybody.
Conditional access is the part of Microsoft Entra ID that decides, at each sign-in, whether to allow it, challenge it or block it, based on who is asking, from where, on what device, for what. It is included in Microsoft 365 Business Premium and the E3 and E5 plans, which means most organisations reading this already own it.
It is also the control that most often locks an administrator out of their own tenant, which is why the order below starts at zero.
Policy zero: the break-glass accounts
Before you create any policy, create two cloud-only accounts with global administrator rights, excluded from every conditional access policy you will ever write.
Why two: because one can fail. Why cloud-only: because if the problem is your identity synchronisation or your MFA provider, an account that depends on either is no help. Why excluded from everything: because the scenario these exist for is precisely the one where a policy has gone wrong.
Give them long random passwords, store those somewhere physical and controlled, and configure an alert that fires when either account signs in. Then test that the alert works, because an emergency account nobody is watching is a permanent back door rather than a safety net.
This takes thirty minutes and it is the difference between a bad afternoon and a support case.
The order
The sequence is deliberate. Administrators first because the group is small, the value is highest, and nobody objects. Everyone else second because it is the single largest reduction in risk available to you. Legacy authentication third because it closes the bypass that makes the first two leakier than they look. Device compliance fourth because it requires device management to be working, and if you attempt it before that you will spend the week exempting people.
Legacy authentication deserves a warning
Legacy protocols cannot present a modern authentication challenge, which means they cannot do MFA. Blocking them is therefore necessary for the MFA policies to mean what you think they mean.
It is also the policy most likely to break something, because the things still using legacy protocols are old and nobody remembers they exist. Commonly: a multifunction printer that scans to email, a line-of-business application that sends notifications, an old mail client on a device somebody forgot about, a monitoring script.
Check the sign-in logs before enforcing, filtered to legacy client applications. Every result is something you need a plan for. Most of them have a modern alternative that takes an hour to configure; a few will need an application-specific arrangement.
Report-only is the whole technique
Report-only mode evaluates the policy at every sign-in and records what would have happened without actually doing it. A week of that data converts a risky change into a list.
Read the list properly. Each would-be block is either a person who needs help before enforcement, a service account that needs a different approach, or a genuine thing you want to block. Resolving them in advance is the difference between a quiet rollout and a queue of locked-out users.
Exclusions, and how they become permanent
Every conditional access deployment accumulates exclusions. The executive who travels, the service account that cannot do MFA, the contractor on an unmanaged device.
Each exclusion is a hole, and holes that nobody revisits become the shape of your security. Three rules that keep this manageable:
Exclude groups, not individuals. A named group with a clear purpose is visible and auditable. An individual exclusion inside a policy is invisible six months later.
Every exclusion group has an owner and a review date. Put it in the group description. Review quarterly, and actually remove people.
Service accounts get workload identities or a tightly scoped policy, not a blanket exemption. An excluded service account with a password and no MFA is exactly what an attacker is looking for.
What to add after the first six
Once the baseline is enforced and stable, the next tier in rough order of value:
Sign-in risk and user risk policies, if you have Entra ID P2, which require additional verification or a password change when Microsoft's signals indicate something unusual. These are genuinely good and they need P2.
Session controls for unmanaged devices, allowing browser-only access with no download rather than a binary allow or block. This is the policy that lets you say yes to contractors safely.
Authentication strength requirements, specifying phishing-resistant methods for administrators. Pushing admins to hardware keys or passkeys closes the remaining gap that MFA fatigue attacks exploit.
Token protection and shorter sessions for high-privilege roles.
Three mistakes that recur
Enforcing everything in one evening. It feels efficient and it means that when something breaks you have no idea which policy did it. One at a time, a week apart.
Forgetting guests. External users in your tenant are covered by policies scoped to all users, and are a common source of unexpected blocks. Decide explicitly how guests are handled.
No documentation. Six months later, somebody will ask why a policy exists. Put the reason in the policy name and keep a one-page register: what each policy does, who owns it, when it was last reviewed. It takes an hour and saves an afternoon of archaeology every time.
