Enforcing MFA with Conditional Access in Entra ID: policies that don't lock you out

Everyone in identity has heard the story: an admin turns on a tenant-wide MFA policy at 5pm, forgets to exclude anyone, and locks the whole company — including themselves — out of Microsoft 365. This is the order of operations that makes that story impossible to tell about you.

New to cloud? CAMPUX is a free, build-first course. Start here →

To enforce MFA with Conditional Access in Entra ID, create two excluded break-glass accounts first, then build one policy — all users, all cloud apps, require multifactor authentication — run it in report-only mode for about a week, and only then switch it on. You need Entra ID P1, and the order matters more than the policy itself.

That is the whole article in one sentence. The rest is the detail that keeps it from going wrong, because every step in that sentence exists to prevent a specific, well-documented way this project blows up. I have rolled MFA enforcement out in real tenants, and the thing I want you to take away is not a clever policy design — the baseline policy is deliberately boring — it is the sequence. People who skip the sequence get the lockout story. People who follow it get a quiet Tuesday.

Step 1: break-glass accounts, before you touch anything else

Before you create your first Conditional Access policy, create two emergency access accounts. Not one — two, in case one is broken for a reason you have not discovered yet. These are usually called break-glass accounts, and they are the reason a policy mistake is an embarrassment instead of an outage.

The requirements are specific, and each one has a reason:

• Cloud-only. Created directly in Entra ID with a *.onmicrosoft.com UPN, not synced from on-premises Active Directory. If your sync breaks or your federation provider has an outage, a synced account goes down with it. The whole point of this account is that it works when everything else does not.
• Excluded from every Conditional Access policy. Every single one, forever, including the ones you write next year. The cleanest way to keep this honest is a dedicated security group — something like CA-Exclude-BreakGlass — that gets added to the exclusions of every policy as a matter of habit.
• Long random passwords, stored offline. Think a generated passphrase split across sealed envelopes in a safe, or whatever physically-secured arrangement your org can actually operate. Not in the same password manager that requires the sign-in you might be locked out of.
• Alerts on every sign-in. These accounts should sign in close to never. Wire up an alert — Microsoft's guidance shows how to do it with a log query and an alert rule — so that any authentication by a break-glass account pages a human immediately. An unmonitored break-glass account is just a privileged account with a weak process around it.
• Global Administrator, tested quarterly. An emergency account you have never actually signed in with is a hope, not a control. Put a recurring reminder on the calendar and prove they work.

Microsoft's own documentation on emergency access accounts covers the same ground in more depth. Nobody skips this step twice. The people who preach it loudest are the ones who learned it the expensive way.

Step 2: know what you're replacing

Tenants arrive at "we should enforce MFA properly" from three different starting points, and the migration path differs slightly for each. It is worth being precise about which one you are in.

Two honest notes on that table. First, the licensing line is real: Conditional Access requires Entra ID P1, and if your org does not have it, security defaults are a genuinely respectable fallback rather than a consolation prize — they block legacy authentication and push MFA registration, which is most of the risk reduction. The differences between the paid tiers are laid out in Entra ID P1 vs P2; for plain MFA enforcement you only need P1, and P2's risk-based policies are a later refinement, not a prerequisite.

Second, if you are switching from security defaults to Conditional Access, understand that you are taking over responsibility for things the defaults did silently — most notably blocking legacy authentication. Turn security defaults off and ship only an MFA policy, and you have quietly become less secure than you were. We will fix that in step 5. If you are fuzzy on what Conditional Access even is under the hood, start with Conditional Access basics and the distinction drawn in Conditional Access vs MFA — MFA is a control, Conditional Access is the engine that decides when to demand it.

Step 3: the baseline policy — boring on purpose

Here is the canonical first policy, and it should look almost exactly like this in every tenant:

Resist the urge to be clever. Every scoping decision you make — "just Office apps for now", "just the finance department" — is a gap an attacker does not have to respect and a future you has to remember. The strength of all users, all cloud apps is that there is nothing to forget. The exclusions are where the judgment lives, so let's be honest about them.

The service account problem, honestly

This is the part most guides wave past. Real tenants have accounts that are not people: a user account that a scanner binds with, a mailbox a legacy app authenticates into, a vendor integration someone set up in 2019. These cannot answer an MFA prompt, and the moment your policy goes live they start failing — usually at 2am, usually attached to something the business cares about.

The uncomfortable truth is that user-style service accounts in Conditional Access are a real, unsolved-by-policy problem. Excluding them from MFA leaves password-only accounts sitting in your tenant, which is exactly the kind of account attackers hunt for. The honest hierarchy of fixes, best to worst:

1. Stop using a user account at all. If the workload runs in Azure, a managed identity removes the credential entirely; if it cannot, a service principal with a certificate is next best. The trade-offs are covered in managed identity vs service principal. Workload identities are not subject to your user Conditional Access policies — they have their own policy type, which requires separate (Workload ID) licensing — so moving workloads out of user accounts is both the security fix and the policy fix.
2. If a user-style account must stay, exclude it from the MFA policy but compensate: a long random password, a separate Conditional Access policy restricting it to known egress IPs, and monitoring on its sign-ins. This is a mitigation, not a solution, and it deserves a follow-up ticket, not a shrug.
3. What you should not do is quietly exclude a broad "IT stuff" group and move on. Every exclusion is an attack path; keep the list short, named, and reviewed.

Step 4: report-only mode, and actually reading it

Conditional Access has a policy state called report-only, and it is the single best lockout-prevention feature in the product. The policy evaluates on every sign-in and records what it would have done — required MFA, blocked, not applied — without doing any of it.

Set the baseline policy to report-only and leave it there for about a week, long enough to catch the weekly rhythms: the Monday-morning sync job, the Friday payroll run. Then go to the Entra sign-in logs, open individual sign-in entries, and read the Report-only tab, or use the Conditional Access insights workbook to see the aggregate. You are looking for one thing: sign-ins that would have failed that you did not expect.

Every tenant I have watched go through this finds something. An app in a forgotten office authenticating like it's 2015. A conference-room device on a shared account nobody documented. A vendor integration on basic auth. When the report-only week is quiet, or every noisy line has an explanation and a decision, flip the policy to On — mid-morning on a normal weekday, with the helpdesk warned and watching, not at 5pm on a Friday.

Report-only mode is how you meet your tenant's skeletons on your own terms, instead of meeting them as an outage.

Step 5: refinements that earn their place

With the baseline enforced, most of the risk reduction is banked. These three additions are the ones that consistently justify themselves.

Block legacy authentication — the highest-value policy after baseline MFA

Legacy authentication protocols — IMAP, POP3, SMTP AUTH, older Exchange ActiveSync — cannot perform MFA at all. A password is the entire conversation. That makes them the front door for password-spray attacks: your MFA policy does not protect a protocol that never asks for a second factor. Microsoft has disabled basic auth for most Exchange Online protocols, but "most" is not "all", and a dedicated Conditional Access policy — all users, all cloud apps, condition: legacy authentication clients, grant: block — closes the door in your tenant explicitly. Run it through report-only first like everything else; this is the policy most likely to surface an ancient scanner or a printer that emails scans via SMTP. If you came from security defaults, this policy is not optional — it is you re-creating protection the defaults were already giving you.

Require compliant devices for admins

An admin session is worth more than a user session, so it can carry more requirements. If you run Intune, a policy requiring privileged roles to sign in from a compliant (or hybrid-joined) device means a phished admin credential is not enough by itself — the attacker also needs a managed machine. Scope it to the directory-role level (Global Admin and friends), and again: break-glass accounts excluded, report-only first, because getting device compliance wrong for admins is a lockout with extra steps.

Named locations — useful, weaker than they look

Named locations let you tag IP ranges — your offices, your VPN egress — and use them as conditions. They are useful for reducing prompt fatigue and as a compensating restriction on excluded service accounts. But be clear-eyed about what an IP proves: that traffic came from a network, not that a trustworthy human sent it. Attackers rent residential proxies in your country for pennies, and "trusted location, skip MFA" quietly turns your office LAN into an MFA bypass for anyone with a foothold on it. My rule: use locations to add friction — block countries you never operate from, restrict service accounts — rather than to remove it.

Microsoft is enforcing some of this whether you act or not

One development worth knowing before your first policy: through 2025 and into 2026, Microsoft has been rolling out Microsoft-managed policies and mandatory MFA requirements of its own — most visibly, required MFA for sign-ins to administrative surfaces like the Azure portal, and Microsoft-managed Conditional Access policies that appear in tenants in report-only mode before enforcing. The specifics, timelines, and affected apps have shifted during the rollout, so check the current state on Microsoft Learn's mandatory MFA page rather than trusting any blog's snapshot, including this one. The direction, though, is settled: unenforced MFA is being phased out from above. Building your own Conditional Access baseline means you decide the shape of enforcement instead of inheriting whatever the managed policy does.

The honest gap: enforced MFA is not phishing-proof

Here is the section that should temper the victory lap. The baseline policy, fully enforced, stops the classic attack — a stolen or sprayed password used directly — and that is a large share of real-world account compromise. What it does not stop is attacker-in-the-middle phishing, which is now commodity tooling. The kit sits between the victim and the real Microsoft sign-in page, relays the password, relays the MFA code or prompt approval in real time, and walks away with the session token. The user did MFA. It did not matter.

The answer is phishing-resistant authentication: FIDO2 security keys, passkeys, and Windows Hello for Business. These bind the credential cryptographically to the genuine site, so a proxy in the middle receives nothing it can replay. Conditional Access can require them via authentication strengths — a grant control that demands not just "MFA" but "phishing-resistant MFA". The pragmatic sequencing: enforce standard MFA for everyone first (it is the step that stops the bulk of attacks and requires no new hardware), then move privileged roles to phishing-resistant methods as the next project, then widen from there. If your MFA rollout plan ends at "everyone gets the Authenticator app", it has a known expiry date — write the phase-two ticket now.

When it goes wrong anyway: What If and the sign-in log

Two tools cover most Conditional Access debugging. The What If tool (in the Conditional Access blade) lets you simulate a sign-in — this user, this app, this platform, this location — and see exactly which policies would apply and what they would demand. Use it before enforcing anything and any time someone claims a policy "should" cover a case.

After the fact, the sign-in logs are the ground truth. Open the specific sign-in entry and look at the Conditional Access tab: every policy in the tenant is listed with its result — Success, Failure, Not applied — and clicking one shows which condition matched or did not. Nine times out of ten, the mystery ("why was I prompted?", "why wasn't I?") dissolves the moment you read the entry instead of guessing. This is also where you audit reality: filter for sign-ins where no MFA policy applied and ask why each one exists. If you have inherited a tenant mid-migration — say, policies scoped to groups that no longer mean what they meant — remapping Conditional Access after a migration walks through untangling that.

The order, one more time

1. Two cloud-only break-glass accounts, excluded from everything, passwords in a safe, alerts on sign-in.
2. Know your starting point: security defaults, per-user MFA, or nothing — and what turning each off means.
3. One boring baseline policy: all users, all cloud apps, require MFA, short and honest exclusion list.
4. Report-only for a week. Read the logs. Fix or consciously exclude what you find.
5. Enforce, then add the refinements: block legacy auth, compliant devices for admins, careful named locations.
6. Write the phase-two ticket: phishing-resistant methods, starting with admins.

None of it is glamorous. All of it is the difference between the lockout story and a quiet Tuesday.

Questions people also ask

How do I enforce MFA for all users in Entra ID?

Create a Conditional Access policy that targets all users and all cloud apps, with a grant control of require multifactor authentication. Exclude two break-glass emergency accounts before you do anything else, run the policy in report-only mode for about a week, read the sign-in logs to see what would have been blocked, then switch it to On. You need an Entra ID P1 license for Conditional Access; without it, security defaults are the fallback.

Do I need Entra ID P1 to use Conditional Access?

Yes. Conditional Access requires Entra ID P1, which is included in bundles like Microsoft 365 Business Premium and E3. Without P1 you can still get tenant-wide MFA through security defaults, which are free, but you get no exclusions, no report-only mode, and no conditions — it is all-or-nothing. P2 adds risk-based policies on top, but plain MFA enforcement only needs P1.

What is a break-glass account and why do I need one?

A break-glass account is a cloud-only emergency admin account that is excluded from every Conditional Access policy, so you can still sign in if a policy misfires, MFA breaks, or a federation outage locks everyone else out. The standard practice is two of them, with long random passwords stored somewhere physically secure, no MFA dependency on a phone that can be lost, and alerts that fire on any sign-in so misuse is noticed immediately.

What is the difference between security defaults and Conditional Access?

Security defaults are a free, all-or-nothing baseline: MFA registration for everyone, legacy authentication blocked, no exceptions and no configuration. Conditional Access is the configurable replacement that requires Entra ID P1: you choose who the policy applies to, which apps it covers, under what conditions it fires, and what it requires, and you can test it in report-only mode before enforcing. Turning on your first Conditional Access policy means taking responsibility for the coverage security defaults gave you for free — including blocking legacy authentication yourself.

Why is MFA not enough to stop phishing?

Because most MFA methods can be relayed. An attacker-in-the-middle kit sits between the user and the real sign-in page, forwards the password and the one-time code in real time, and steals the resulting session token — the user approved the MFA prompt, and it did not help. Phishing-resistant methods like FIDO2 security keys, passkeys, and Windows Hello for Business bind the credential to the real site, so a proxy in the middle gets nothing. Enforce standard MFA first, then move admins to phishing-resistant methods.