Per-User MFA vs Security Defaults vs Conditional Access: Which Microsoft MFA Should You Use in 2026?
Microsoft has three ways to turn on MFA, and admins mix them up daily. Here is what each one is in 2026, which to use, the per-user MFA vs Conditional Access comparison head to head, and why the old per-user method should be switched off even though it still works.
AZ / decision fieldnote
An MFA setting is only one part of an access policy.
What control does the tenant need?
Per-user MFA
Account-by-account legacy enforcement
Security Defaults
A baseline applied across the tenant
Conditional Access
Policies for users, resources and conditions
Use this in your decision
Map the required policy and exceptions before changing enforcement.
- Which users, applications and sign-in conditions need distinct treatment?
- What policy capability is licensed?
- How will access be tested before broad enforcement?
Reading aid for this article. The analysis and supporting sources follow below.
The short answer: if you have no premium identity license, turn on Security Defaults. If you have Microsoft Entra ID P1 or P2 (it comes with Microsoft 365 Business Premium, E3, and E5), use Conditional Access instead. Confirm the replacement policy covers the affected users and passes testing before disabling legacy per-user MFA. It still works, but Microsoft no longer recommends it, and running it alongside the modern methods just creates duplicate enforcement.
Microsoft gives you three different ways to require multi-factor authentication, and the names do not make it obvious that they are alternatives to each other. People enable two at once, leave the legacy one half-configured, and end up unsure what is actually protecting their tenant. This guide explains what each method is, when to use it, and the one configuration almost every tenant should clean up.
The three methods at a glance
| Feature | 🗄️ Per-User MFA | 🛡️ Security Defaults | 🎛️ Conditional Access |
|---|---|---|---|
| What it is | The original method: flip MFA on per account | One free tenant-wide on/off switch | Policies that require MFA based on conditions |
| Cost | Free | Free | Entra ID P1 or P2 (in Business Premium, E3, E5) |
| Granularity | Per user, prompts on nearly every sign-in | All or nothing, everyone the same | By user, app, location, device, and risk |
| Best for | Almost no one in 2026 | Small orgs with no premium license | Anyone who needs exceptions or owns a license |
| Microsoft's stance | No longer recommended | Good baseline | Recommended where licensed |
When to use each
- Use Security Defaults when you are a small organization with no Entra ID P1 or P2 license and you want one safe baseline with nothing to configure.
- Use Conditional Access when you have the license (it is included with Business Premium, E3, and E5) and you need anything beyond all-or-nothing: skipping MFA on the trusted office network, requiring it harder for admins, or blocking risky sign-ins.
- Use per-user MFA only as a last resort, when you can use neither of the above. For almost every tenant in 2026, the right move is to switch it off.
Want this as a one-pager? Get the free Microsoft MFA decision guide: the comparison, the rule, and what to switch off, on a single printable page.
Get the guide🗄️ What is per-user MFA?
Per-user MFA is the original way Microsoft turned on multi-factor authentication, by setting a state on each individual account. Each user sits in one of three states:
- Disabled: the default. The user is not enrolled in per-user MFA.
- Enabled: the user is enrolled and will be asked to register MFA on their next sign-in, but can still sign in with just a password until they do.
- Enforced: the user is fully enrolled and must complete MFA at sign-in.
When a user is enforced this way, they are prompted on nearly every sign-in, with no awareness of whether the request is normal or risky. There is no targeting and no exceptions. It is a blunt instrument from an earlier era of Microsoft 365.
The myth worth correcting
A lot of articles claim per-user MFA was retired in 2025. That is wrong, and it matters. What ended on September 30, 2025 was the ability to manage authentication methods inside the old MFA and self-service-password-reset policies, which moved to the unified Authentication methods policy. The per-user MFA on/off states themselves still exist and still work in 2026. Microsoft simply discourages them and has not announced a retirement date.
Why switch it off anyway
Microsoft's guidance is explicit: do not enable or enforce per-user MFA if you use Conditional Access. Running both means a user is required to do MFA by two systems at once, which is redundant enforcement and a configuration that is hard to reason about. One quirk trips people up here: once Conditional Access or Security Defaults is handling MFA, your users correctly show as "Disabled" on the per-user status page even though they are protected. That is expected. The clean end state is to let Conditional Access or Security Defaults do the work and disable per-user MFA for users whose replacement protection has been verified.
🛡️ Security Defaults: the free baseline when you have no premium license
Security Defaults is a single free switch that turns on a sensible baseline for the whole tenant. Flip it on and Microsoft requires MFA registration for everyone, requires MFA for admins, prompts for MFA when a sign-in looks risky, and blocks the legacy authentication protocols attackers love. There is nothing to configure and nothing to get wrong, which is exactly why it suits a small business with no full-time IT.
The trade-off is that it is all or nothing. Every user gets the same treatment, with no way to skip MFA on a trusted network or apply stricter rules to privileged accounts. The moment you need an exception, you have outgrown it. One hard rule to remember: Security Defaults and Conditional Access cannot both be on. Creating a Conditional Access policy requires turning Security Defaults off.
🎛️ Conditional Access: the right method if you already own Entra ID P1 or P2
Conditional Access is the modern, recommended method, and it is what Security Defaults is a simplified preview of. Instead of one switch, you write policies that decide when MFA is required based on signals: which user or group, which application, the network or country, the device state, and the risk level of the sign-in. That lets you require MFA for everyone, skip the prompt inside the trusted office, demand a stronger method for admins, and block a sign-in that looks like it came from an impossible location.
It requires a license: Microsoft Entra ID P1 for the core policies, and P2 for the risk-based ones that react to suspicious sign-ins automatically. As of July 2026, P1 lists at $7 per user per month and P2 at $10, but most companies already own it without realizing: P1 is included in Microsoft 365 Business Premium and E3, and P2 is in E5. If you pay for one of those plans and still run Security Defaults or per-user MFA, you are leaving the better tool in the box.
Per-user MFA vs Conditional Access, head to head
Most tenants that ask this question have already ruled out Security Defaults — they own the license and need exceptions. So here is the two-way comparison on its own terms:
- When the prompt happens: per-user MFA prompts on nearly every sign-in with no awareness of context. Conditional Access decides per sign-in, using the user, the app, the location, the device state, and the risk signal — which means fewer prompts for normal work and harder checks exactly where they belong.
- Exceptions: per-user MFA has none — it is on or off per account. Conditional Access expresses every exception as policy: skip the prompt on the trusted network, require phishing-resistant methods for admins, block legacy authentication outright.
- Evidence: per-user MFA leaves you a list of enabled accounts. Conditional Access leaves you policies you can show an insurer or auditor, with report-only mode to prove impact before enforcement.
- License: per-user MFA is free on every tier. Conditional Access needs Entra ID P1 or P2 — already included in Business Premium, E3, and E5, which is why most companies asking this question already own it.
- Microsoft's direction: per-user MFA is legacy and discouraged; Conditional Access is where every new capability lands. Running both at once creates duplicate prompts and confusing behavior — the migration ends with per-user MFA off.
The verdict is not close: if the license exists, Conditional Access wins on every axis except "it was already there." The real work is the migration order — build the policies in report-only, verify coverage, enforce, then disable per-user MFA account by account.
The fourth thing that is not a choice: mandatory MFA
Separate from the three methods above, Microsoft now enforces MFA on its own admin surfaces whether you configure anything or not. Since late 2024, signing in to the Azure portal, the Entra and Intune admin centers, and the Microsoft 365 admin center has required MFA. A second phase, which began October 1, 2025, extends this to the tools that manage Azure resources, including the Azure CLI, Azure PowerShell, and infrastructure-as-code, for create and update operations. This is system enforcement with no opt-out. The postponement window that let tenants delay the second phase closed on July 1, 2026, so both phases are in force today. Enforcement covers public Azure, not the government clouds. The practical takeaway: your admins need a working MFA method regardless of which of the three methods you adopt for everyone else. And once their MFA is sorted, the next question is whether those admins should hold their roles permanently at all, which is the subject of PIM eligible vs active: can you still assign permanent admin roles?
Turning it on is half the job
Choosing a method decides when MFA is required. It does not decide how strong the second factor is, and that is where most breaches still get through. Two things to get right once MFA is on:
- Number matching is on by default for Microsoft Authenticator push approvals, and users cannot turn it off. It defeats the "MFA fatigue" attack, where an attacker with a stolen password spams approval prompts, at 2 a.m., twenty times in five minutes, until the user taps Approve just to make it stop. With number matching the user must type a two-digit code shown on the attacker's screen, which they cannot see, so the attack dies.
- Phishing-resistant methods are the new baseline. Microsoft now states plainly that traditional MFA is no longer enough, because codes and push approvals can be phished. The methods that resist phishing are passkeys and FIDO2 security keys, Windows Hello for Business, and certificate-based authentication. SMS and voice codes still work, but they are the weakest option and worth moving privileged accounts off of first. They are also now on a retirement clock: Microsoft retires its SMS and voice delivery on February 1, 2027, and a separate guide covers who breaks and how to check your tenant. The reason the distinction matters is worth understanding before you choose: against a phishing proxy that relays the real sign-in page, a code or a push approval can be passed through and the session stolen after MFA succeeds, which is explained in Microsoft 365 session token theft. Conditional Access is the only one of the three methods that can require a phishing-resistant method at all.
And if what sent you here is an insurer's renewal questionnaire or an auditor asking how sign-in is controlled, picking the method is only step one. An MFA and Conditional Access hardening engagement takes the tenant the rest of the way and leaves written proof of where enforcement stands.
Common MFA questions
Is Conditional Access better than per-user MFA?
For any tenant that owns Entra ID P1 or P2, yes, on every axis that matters: context-aware prompts instead of prompting on every sign-in, policy-based exceptions, report-only mode to test before enforcing, and evidence you can show an insurer. Per-user MFA's only advantages are that it is free on every tier and already familiar. Microsoft discourages it, and the recommended end state is Conditional Access enforced with per-user MFA switched off.
What is the difference between per-user MFA and Conditional Access?
Per-user MFA flips MFA on for an individual account and prompts on nearly every sign-in with no targeting. Conditional Access requires MFA through policies that consider the user, app, location, device, and risk, so you can apply it precisely. Conditional Access is the modern, recommended method and needs an Entra ID P1 or P2 license; per-user MFA is the legacy method Microsoft discourages.
Was per-user MFA retired or deprecated?
No. The per-user MFA states (Disabled, Enabled, Enforced) still exist and work in 2026, and Microsoft has not announced a retirement date. What ended on September 30, 2025 was managing authentication methods inside the old legacy policies, which is a different thing. Microsoft discourages per-user MFA, so the right move is to switch it off and use Conditional Access or Security Defaults, but it was not removed.
Should I use Security Defaults or Conditional Access?
Use Security Defaults if you have no Entra ID P1 or P2 license and want a free, no-configuration baseline. Use Conditional Access if you own the license (it is in Business Premium, E3, and E5) or you need any exception to all-or-nothing MFA. They cannot both be enabled, so turning on a Conditional Access policy means turning Security Defaults off.
Does Microsoft 365 Business Premium include Conditional Access?
Yes. Business Premium includes Microsoft Entra ID P1, which covers Conditional Access. E3 includes P1 as well, and E5 adds P2 for risk-based policies. If you pay for any of these and still rely on Security Defaults or per-user MFA, you already own the better tool.
Sources and implementation references
About this article
Published by AZ Innovations, led by Alwatheq Zboun. We complete scoped Microsoft 365, security, migration and automation work. See who does the work or the delivered work.
Know which accounts are properly protected, and be able to prove it.
Configure the agreed sign-in methods, administrator roles, emergency access and access policies. Test them with a pilot group before enforcement and record the results.