Azure MFA best practices: the handful that actually change your risk

"Turn on MFA" is where most guidance stops and most breaches slip through. The gap between MFA that's switched on and MFA that actually protects you is a short list of specific decisions. Here it is.

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

Effective Azure MFA comes down to a few things: enforce it through Conditional Access rather than legacy per-user MFA, require phishing-resistant methods (not SMS) for anyone who matters, block legacy authentication so nothing can route around the requirement, turn on number matching, keep monitored break-glass accounts, and watch risky sign-ins. Everything else is detail. Miss any one of those and "we have MFA" is quietly less true than it sounds.

MFA is the single most effective security control in Microsoft Entra ID — it stops the overwhelming majority of account-takeover attacks, which almost all start with a stolen or sprayed password. But "enabled" and "effective" are different states, and the space between them is where real incidents live: the admin protected by SMS that got SIM-swapped, the mailbox reached over IMAP that never saw a prompt, the user who tapped Approve on an attacker's tenth push at midnight. These practices close those gaps.

1. Enforce with Conditional Access, not per-user MFA

Entra has three ways to require MFA, and only one is the modern answer. Per-user MFA is the oldest — a per-account on/off flag with no context; avoid it. Security Defaults is a free, all-or-nothing baseline that's fine for a small tenant with no Entra ID P1. Conditional Access is the standard for everyone else: it requires MFA based on signals — who the user is, which app, what device, where from, and how risky the sign-in looks — so you can demand strong auth exactly where it matters without drowning low-risk logins in prompts. If you have P1, build your MFA on Conditional Access.

2. Prefer phishing-resistant methods; demote SMS

Not all second factors are equal. Rank them, and require the strong ones where the stakes are highest:

Use Authentication Strengths in Conditional Access to require a phishing-resistant method for administrators, rather than merely allowing it. SMS should be a break-in-case-of-emergency fallback, never the primary factor for a privileged account.

3. Block legacy authentication — or the rest doesn't matter

This is the one people skip, and it silently voids everything above. Legacy authentication protocols — older Office clients, IMAP, POP, SMTP AUTH — cannot do modern MFA, so they bypass it entirely. As long as legacy auth is allowed, an attacker with just a valid password can sign in over one of those protocols and never be prompted. Add a Conditional Access policy that blocks legacy authentication so there is no path around your MFA requirement. Check your sign-in logs for legacy-auth usage first so you know what breaks, then block.

4. Turn on number matching (anti-fatigue)

"MFA fatigue" attacks work by spamming Approve/Deny pushes until a tired user taps Approve. Number matching defeats it: the sign-in screen shows a number the user must type into Microsoft Authenticator to approve. Because the number only appears on the real sign-in page, a user can't approve an attacker's push without it. It's on by default now — keep it on, and pair it with the app showing application and location context on the prompt.

5. Keep monitored break-glass accounts

The failure mode of aggressive MFA is locking yourself out — a misconfigured policy or an MFA-service outage that leaves no admin able to sign in. Prevent it with two or more emergency access (break-glass) accounts: cloud-only, excluded from all Conditional Access policies, protected by very long unique passwords stored offline, and — critically — alerted on every sign-in so any use is noticed immediately. The MFA exclusion is deliberate, and the monitoring is what makes it safe.

6. Require MFA for admins first, then everyone

If you can't do everything at once, protect privileged roles first — Global Administrator and the other high-impact roles are the accounts attackers want. Then extend MFA to all users; a standard user account is a foothold to everything they can reach. Pair privileged-role MFA with Privileged Identity Management so admin rights are elevated just-in-time rather than standing, which shrinks the window an unprotected admin session is even useful.

7. Run a registration campaign, then watch risky sign-ins

Two operational habits close the loop. Use the Authenticator registration campaign to nudge users off SMS onto the app before you tighten policy, so enforcement day isn't a helpdesk flood. And if you have Entra ID P2, turn on Identity Protection risk policies so a risky sign-in triggers a step-up or block automatically — MFA that reacts to a suspicious login is worth more than MFA that fires the same way for everyone. Review the sign-in and audit logs regularly for anomalies; that's the same login-auditing discipline every good governance setup runs.

MFA that's merely switched on stops password spray. MFA that's configured well stops the attacker who already has the password.

Questions people also ask

How should I enforce MFA in Microsoft Entra ID?

With Conditional Access, not the legacy per-user toggle. Conditional Access requires MFA based on signals — user, app, device, location, sign-in risk — and is where phishing-resistant methods and Authentication Strengths apply. Security Defaults is a fine baseline for small tenants without P1; per-user MFA is the least flexible and should be retired.

Is SMS MFA secure enough?

It's better than nothing but the weakest method, exposed to SIM-swap and interception. Use it only as fallback. Prefer FIDO2/passkeys, Windows Hello for Business, or certificate-based auth, and require them for admins via an Authentication Strength. Authenticator push with number matching is a solid middle tier.

Why block legacy authentication?

Legacy protocols (older Office, IMAP, POP, SMTP AUTH) can't do modern MFA, so they bypass it. While legacy auth is allowed, a valid password alone can sign in with no prompt. Block it with Conditional Access so there's no route around your MFA requirement.

Should break-glass accounts be excluded from MFA?

Yes — keep two or more emergency accounts excluded from Conditional Access so an MFA misconfiguration or outage can't lock out every admin. Protect them with long offline passwords and alert on every sign-in so any use is caught immediately.

What is number matching?

An anti-fatigue control: instead of a tap-to-approve push, the user types a number shown on the sign-in screen into Authenticator. The number only appears on the legitimate screen, so an attacker's push can't be approved. It's on by default and should stay on.