Multi-factor authentication is the single most effective thing you can switch on to stop account takeover in Microsoft 365. A stolen password alone stops being enough, because the attacker also needs the second factor on the user’s phone. The technology is solid and built in — the part that needs thought is which MFA method to use and how to roll it out without locking people out or flooding the help desk.
Microsoft gives you three ways to require MFA, and they suit different tenants. This guide explains when to use each one, walks through enabling it, covers how users register the authenticator, and ends with the one thing too many admins skip: a break-glass account so you don’t lock yourself out of your own tenant.
The three ways to require MFA
Before clicking anything, know your options. They overlap, and two of them can’t run together.
Choosing an MFA approach
| Security defaults | Free, on/off switch, MFA for everyone. Best for small tenants or anyone without Conditional Access licensing. No granular control. |
|---|---|
| Conditional Access | Policy-based MFA with conditions (user, app, location, risk). Needs Entra ID P1/P2. Best when you want control and exceptions. |
| Per-user MFA (legacy) | Enable/enforce MFA account by account. The oldest method. Mainly for quickly protecting one account on a tenant with nothing else set up. |
Option 1: Security defaults (the simplest path)
If you have no special requirements, this is the fastest way to protect everyone.
- Sign in to the Microsoft Entra admin center (
entra.microsoft.com). - Go to Identity → Overview → Properties (or Identity → Protection → Security defaults).
- Set Security defaults to Enabled and save.
That’s it. Every user is now required to register for MFA and will be prompted to do so at next sign-in. Security defaults also block legacy authentication outright, which is good for security but is exactly what can break older apps — read the gotcha near the end before flipping it on a tenant with old devices.
Option 2: Conditional Access (control and exceptions)
Conditional Access is the grown-up option. Instead of “MFA for everyone, always,” you write policies like “require MFA for all users, except from the office IP, and always for admins.” It needs Entra ID P1 or P2 licensing.
A solid starter policy looks like this:
- In the Entra admin center, go to Protection → Conditional Access → Policies → New policy.
- Assignments → Users: include All users, then under Exclude add your break-glass account(s).
- Target resources: select All cloud apps.
- Grant: choose Grant access → Require multifactor authentication.
- Set Enable policy to Report-only first (not On), and create it.
Report-only lets you see who would be prompted without actually enforcing anything. Once the report-only logs look right, flip the same policy to On.
Option 3: Per-user MFA (legacy, situational)
Per-user MFA toggles MFA on individual accounts. It predates the other two and Microsoft now nudges tenants away from it, but it’s still handy for protecting one account fast when nothing else is configured.
- In the Microsoft 365 admin center, go to Users → Active users.
- Click Multi-factor authentication (this opens the legacy MFA management page).
- Select the user(s), then choose Enable.
- After they register, you can move them from Enabled to Enforced.
The catch with per-user MFA is that “Enabled” prompts for registration but doesn’t fully enforce until the user has registered, and managing it at scale is tedious. For more than a handful of accounts, security defaults or Conditional Access is far less work.
Registering the Microsoft Authenticator
However you require MFA, users register a second factor the same way. Push the authenticator app as the primary method — it’s stronger than SMS and supports number matching, which defeats the “approve by accident” attacks.
- The user signs in and is prompted for More information required.
- They install Microsoft Authenticator on their phone from the app store.
- In the browser prompt they choose Mobile app / Authenticator app and scan the QR code.
- They approve a test notification — for number matching, they type the number shown on screen into the app.
- They add a backup method (a phone number) in case they lose the device.
A sane rollout, not a Monday-morning surprise
Turning MFA on for everyone at 9am with no warning guarantees a bad day. A phased approach keeps it calm.
MFA rollout best practice
- Create and test break-glass accounts first, excluded from all MFA policies
- Inventory apps and devices that use legacy auth (old Outlook, scanners, IMAP/POP)
- Pilot MFA on IT and a small willing group before going wide
- Email users ahead of time with the aka.ms/mfasetup link and what to expect
- Use Conditional Access report-only mode to preview impact before enforcing
- Roll out by department or in waves, not the whole tenant at once
- Keep the help desk briefed for the first week of each wave
Don’t forget break-glass accounts
This is the safeguard that saves you when MFA itself becomes the problem. A break-glass (or emergency access) account is a cloud-only admin account you deliberately exclude from MFA and Conditional Access policies, so a locked-out tenant or an MFA outage doesn’t trap you outside your own environment.
Set them up like this:
- Create one or two cloud-only Global Administrator accounts not tied to any individual.
- Give each a long, unique, random password and store it somewhere secure and offline (a sealed envelope in a safe, or a dedicated vault).
- Exclude them from every MFA and Conditional Access policy.
- Monitor sign-ins to these accounts with an alert — they should almost never be used, so any sign-in is worth noticing.
Wrapping up
For most tenants, the decision is short: small shop with no special needs, turn on security defaults; need exceptions, trusted locations, or admin-specific rules and you have P1/P2, use Conditional Access with report-only first; just need to protect one account fast, reach for per-user MFA. Whatever you pick, push the Authenticator app over SMS, roll out in waves with warning, account for legacy-auth apps, and build break-glass accounts before you enforce anything.
MFA is also a building block for tighter access policies down the line — if you go the Conditional Access route, it pairs naturally with the kind of identity hardening you’ll layer on top later. For related Microsoft 365 administration, see our guides on creating a shared mailbox and tracing an email message in Exchange Online.
