Requiring multi factor authentication for every user is one of the highest value settings in Microsoft 365, and also the one people put off, because the horror story is real: one wrong Conditional Access policy and every admin, including you, is locked out of the tenant. Here is how to turn it on for everyone safely, so the only thing that happens is that attackers stop getting in.
Why people are scared of this policy
Conditional Access policies apply to whoever they are scoped to, immediately, with no undo button once you are locked out. If you require MFA for all users and your own account cannot complete MFA for some reason, you are out, and so is everyone who could fix it. That fear is why so many tenants have MFA switched on for some people and quietly off for others, which is the gap an attacker walks through. The fix is not to avoid the policy. It is to build it so a lockout cannot happen.
Make a break glass account first
Before you touch Conditional Access, create a break glass account. This is the key under the mat, the account you use only if everything else is locked out.
- A cloud only account, not synced from anywhere, with its own long random password.
- Excluded from every Conditional Access policy, including the one you are about to build. That exclusion is what guarantees you can always get back in.
- Not a daily account. Nobody signs in with it for normal work.
- The password written down and stored offline somewhere physically safe, not in the same systems it is meant to rescue.
- Sign in alerts on it, so you know the moment it is ever used.
With that account in place, a lockout is recoverable, which takes all the risk out of the next step.
Build the require MFA policy in report-only
In the Entra admin centre, create a Conditional Access policy:
- Users: all users, and under Exclude, add your break glass account.
- Target resources: all cloud apps.
- Grant: require multi factor authentication.
- Enable policy: Report-only.
Save it and leave it in report only for about a week. Report only applies the policy in the logs without actually enforcing it, so the sign in logs show you exactly who would have been prompted and who would have been blocked, before anyone really is. You are looking for surprises: service accounts, a scanner, an old integration, anyone who signs in a way that cannot do MFA. Deal with each one before you enforce.
Turn it on, and the traps
Once the report is clean, change the policy from Report-only to On. A few things catch people here.
- The "don't lock yourself out" box. When your own account is in scope, Entra shows a warning and defaults to re-adding you as an exclusion. If you let it, you have quietly carved yourself out of your own MFA policy. Tick the option that says you understand and proceed anyway, so the policy really does cover you.
- Legacy authentication. MFA does nothing against old protocols that cannot do MFA in the first place, so pair this with a policy that blocks legacy authentication. We cover that in a separate guide.
- Service accounts. Do not solve a stuck service account by excluding it and forgetting it. Move it to a managed identity or an app registration where you can, and where you genuinely cannot, scope it tightly to a trusted location and watch it.
- Guests. Decide whether external guests are in scope. Usually they should be, so a shared document is not a soft way in.
What good looks like
Every user, including the directors, has to pass MFA to sign in. Legacy authentication is blocked so there is no side door. There is one break glass account, excluded from everything, with its password held offline. That is the combination that closes the single most common way small firms get breached, and none of it requires a project, just an hour done carefully. It is the first thing we check in a Health Check and the first thing we fix in a Hardening project.