MFA in Microsoft 365: Security Defaults, Conditional Access or Per-User MFA?

MFA should be straightforward by now, but Microsoft 365 tenants still end up in odd halfway states.

Some tenants rely on Security Defaults because they are small and simple. Some use Conditional Access because they need proper policy control. Others still have per-user MFA hanging around from an earlier era, often mixed with newer controls in a way that confuses everyone.

The hard part is not choosing the strongest marketing phrase. It is choosing the enforcement model that matches the tenant and cleaning up the leftovers.

The three common options

Option	Best fit	Main limitation
Security Defaults	Small tenants that need a baseline quickly	Little room for custom scope or nuanced exceptions
Conditional Access	Tenants that need real access control	Needs design, testing, and ownership
Per-user MFA	Legacy situations that have not been modernised yet	Hard to govern at scale and not recommended alongside Conditional Access

That last point matters. Microsoft is clear that if you use Conditional Access policies, you should not also enable or enforce per-user MFA for the same purpose. It creates operational confusion without giving you a better control model.

Security Defaults are simple for a reason

Security Defaults are fine for very small environments that need a baseline and do not have complex access requirements. They bring in Microsoft-managed protections without the design overhead of Conditional Access.

The trade-off is control. You do not get the kind of scoped logic you need if you want one policy for admins, another for unmanaged devices, another for guests, and a neat exception path for a specific app.

If that level of nuance is not required, Security Defaults can be a sensible starting point. If it is required, forcing the tenant to stay there just because it feels simpler usually becomes a false economy.

Conditional Access is where MFA becomes part of access design

Conditional Access lets you treat MFA as one signal in a broader access model. That usually means:

1. protecting admins more tightly than normal users
2. blocking legacy authentication
3. applying stronger requirements to risky sign-ins
4. tying access to device state where the risk justifies it

That is why Conditional Access is the usual end state for a tenant that has grown past "just turn MFA on somehow".

Per-user MFA still exists, but it should not be your design target

Per-user MFA is still supported, but it is best understood as a legacy control path.

If you see it in a tenant today, ask these questions:

• Is Conditional Access already available?
• Is the business intentionally avoiding Security Defaults?
• Does anyone know which users are enabled and why?

Quite often the answer is "this was set years ago and nobody wanted to touch it". That is not a good reason to keep a control model.

Good MFA is more than a checkbox

Whatever route you choose, the quality of MFA depends on more than whether prompts exist.

Review these areas:

Area	What to look for
Coverage	Admins and users are protected in a way you can explain quickly
Methods	Stronger methods are preferred where practical, not just whatever users happened to register first
Legacy auth	Older protocols that bypass modern controls are blocked
Recovery	Account recovery does not quietly undermine the whole model
Exceptions	Break-glass and genuine edge cases are documented and minimal

This is where plenty of tenants still wobble. MFA exists on paper, but the method policy is messy, the exception list grew quietly, or a legacy application forced a loophole nobody went back to challenge.

A practical rule of thumb

Use Security Defaults if the tenant is small, uncomplicated, and just needs a sensible baseline.

Use Conditional Access when identity is part of how you run the business and you need policy choices you can actually control.

Move away from per-user MFA when the tenant is ready for either of those cleaner models.

That is the whole thing, really. The better choice is the one the team can explain, support, and review six months from now without squinting at old screenshots.

References

• Microsoft security defaults
• Microsoft Entra Conditional Access overview
• Enable per-user Microsoft Entra multifactor authentication
• Microsoft Entra authentication methods