Per-User MFA vs Security Defaults vs Conditional Access: Which Microsoft MFA Should You Use?
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. In both cases, switch off the old 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 set per-user MFA back to Disabled for everyone.
🛡️ Security Defaults
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
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 June 2026, P1 lists at $6 per user per month and P2 at $9, 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.
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, only a postponement window that closes for most tenants on July 1, 2026. It applies to 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.
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 a hacker spams approval prompts until someone taps Approve. We covered exactly how that attack works in why hackers love your MFA.
- 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.
Common MFA questions
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.
Not sure what your tenant is actually enforcing?
Most environments we review are running two MFA methods at once, leaving admins half-covered, or paying for Conditional Access they never turned on. Our Identity and Insurance Evidence Pack proves what MFA, Conditional Access, and admin controls your Microsoft Entra ID actually enforces, in the format a cyber-insurance renewal asks for. Worth knowing before a breach or an audit, not after.
See the Identity and Insurance Evidence PackNeed help implementing this?
We turn these concepts into secure configurations for your tenant.
Request a scoping session