MFA problems usually land on the help desk in one of two shapes. Either a user can’t get past the prompt this morning when it worked fine yesterday, or you’ve just rolled out MFA to a group and a handful of people are now locked out. Both are fixable, but they have different causes, and chasing the wrong one wastes a lot of time.
The trick is to separate the person from the policy. A single user who suddenly can’t approve a sign-in almost always has a phone or registration issue. A whole group failing right after a change points at Conditional Access, Security Defaults, or per-user MFA stepping on each other. This guide walks both paths: the quick per-user fixes first, then the tenant-level settings that cause the wider outages, and finally app passwords for the legacy apps that can’t do modern MFA at all.
Start by reproducing what the user actually sees
Before you change anything, find out what’s failing. “MFA isn’t working” covers at least four different situations, and the fix depends on which one it is.
- The Authenticator notification never arrives.
- The notification arrives but approving it does nothing.
- A verification code is entered but rejected.
- The user gets blocked or an error code before any prompt appears.
The fastest source of truth is the sign-in logs. In the Microsoft Entra admin center, open Users, pick the affected person, and look at their recent sign-ins, or go to the tenant-wide sign-in logs. The failure reason and error code there tell you whether MFA was even reached or whether a policy blocked the sign-in first. If you’re not comfortable reading those, our walkthrough on checking Microsoft 365 sign-in logs covers the columns that matter.
Per-user fixes: the phone and the registration
Most day-to-day MFA tickets are one device having a bad day. Work through these in order.
Notifications and connectivity
The Authenticator app needs a working data connection to receive a push notification. On weak Wi-Fi or no signal, the notification simply doesn’t arrive. Have the user open the Authenticator app directly and read the one-time code instead of waiting for a push. If the code works, the account is fine and the problem is notification delivery.
Then fix delivery itself: confirm notifications are enabled for Authenticator in the phone’s OS settings, and check that battery optimisation or a power-saving mode isn’t suspending the app in the background. Both are common on Android after an OS update.
Number matching and the right prompt
Microsoft Authenticator push approvals use number matching: the sign-in screen shows a two-digit number that the user types into the app. People who are used to the old “tap Approve” flow sometimes don’t realise they need to read the number off the computer screen and enter it on the phone. If they’re tapping a button that isn’t there, that’s why nothing happens.
Time sync for verification codes
If the user relies on the time-based code rather than push, a drifted phone clock breaks every code. The codes are calculated from the current time, so a clock that’s a minute off produces a code the server rejects. Turn on automatic date and time on the phone, then generate a fresh code.
Re-register when the phone changed
A new phone is the classic silent break. The MFA registration lives on the old device, so the new phone has no account set up even though the user expects it to. The fix is to make the user re-register their security info.
In the Entra admin center: open Users, select the person, go to Authentication methods, and choose Require re-register multifactor authentication. This revokes their existing methods and forces a clean setup at the next sign-in.
If the user can’t sign in at all to reach the registration page, issue a Temporary Access Pass from their authentication methods. It’s a short-lived code that lets them in once so they can register a real method, and it’s a much safer move than disabling MFA for the account.
Per-user MFA triage
- Check the sign-in log for the exact failure reason and error code
- Have the user open Authenticator and use the code instead of push
- Confirm OS notifications and background activity are allowed for Authenticator
- Turn on automatic date/time so verification codes match
- Re-register methods if the phone was replaced or reset
- Issue a Temporary Access Pass if they can't sign in to re-register
Tenant-level causes: when a whole group breaks at once
If multiple users fail right after a change, stop looking at phones. The cause is almost always how MFA is being enforced. Microsoft 365 has three overlapping ways to require MFA, and trouble starts when more than one is active.
Three ways MFA gets enforced (don't stack them)
| Security Defaults | Free, tenant-wide on/off. Enforces MFA for everyone, no exceptions. Can't coexist with Conditional Access. |
|---|---|
| Per-user MFA (legacy) | Old per-account Enabled/Enforced state. Causes prompts independent of policy. Should be Disabled once you use CA. |
| Conditional Access | Targeted policies (Entra ID P1+). The model to standardize on. Lets you scope users, apps, and exclusions. |
The conflict to watch for: a tenant has per-user MFA set to Enforced for some accounts, then an admin builds a Conditional Access policy that also requires MFA. Now the account is being pushed through MFA by two systems, which produces double prompts and confusing failures. The fix is to pick one model. For almost every tenant that’s Conditional Access, after which you set the per-user MFA state back to Disabled for those accounts so the legacy enforcement stops.
Security Defaults is the other common surprise. It’s all-or-nothing and can’t run alongside Conditional Access, so turning on a CA policy means Security Defaults has to be off. If you’ve got both fighting, that’s your group-wide breakage.
When the block is the point: read the policy
Sometimes MFA “not working” is Conditional Access doing exactly what you told it to. A policy that requires a compliant device, blocks a location, or excludes legacy clients will stop a sign-in cold, and the user reads that as MFA failing.
This is where report-only mode and a careful look at policy scope pay off. If you’re not sure how your policies are evaluated or why a sign-in is blocked, our guide on Conditional Access for Microsoft 365 admins breaks down assignments, conditions, and the “block always wins” rule that catches people out.
A few policy-driven failures worth knowing:
- Compliant device required, device isn’t enrolled. The user can authenticate but the grant control fails. The sign-in log names the control that wasn’t satisfied.
- Location or country block. A user travelling or on a VPN hits a named-location rule and gets blocked before MFA.
- Legacy authentication blocked. Older clients can’t do MFA, so a block-legacy-auth policy stops them. That’s the correct behavior, not a bug.
App passwords for apps that can’t do MFA
Some older applications use legacy authentication and can’t present a modern MFA prompt at all. For those, an app password is the fallback: a long, randomly generated password the app uses in place of the normal one, which satisfies the sign-in without an interactive second factor.
App passwords are a legacy mechanism, and Microsoft’s direction is to move clients to modern authentication instead. A few things to know before you rely on them:
- App passwords are only available when the tenant’s MFA settings allow them. With Security Defaults enabled, app passwords are not offered. They’re tied to the older per-user MFA service settings.
- They don’t work for every scenario, and they bypass the protection MFA is meant to add, so use them only for an app that genuinely has no modern-auth option.
- The real fix is almost always to update or replace the legacy client so it supports modern authentication.
Where users create an app password (when enabled):
1. Sign in at the My Sign-Ins / security info page.
2. Open the app passwords section (only shown if the tenant allows it).
3. Create one, copy the generated string, and paste it into the legacy app
in place of the account password.If an old client is what’s actually failing — Outlook repeatedly asking for credentials, for example — the cause is usually authentication settings rather than MFA itself, and our guide on Outlook that keeps asking for a password is the better starting point.
A note on the deprecated MSOnline cmdlets
You’ll still find scripts online that reset MFA with Set-MsolUser -StrongAuthenticationMethods. The MSOnline and Azure AD PowerShell modules are deprecated and being retired, so don’t build new processes on them. Manage authentication methods through the Entra admin center or Microsoft Graph PowerShell instead. The portal flow described above (Authentication methods → Require re-register) does the same job and is supported.
Wrapping up
Split the problem before you troubleshoot it. One user failing is a device or registration issue: check the sign-in log, use the code instead of push, fix notifications and clock, and re-register if the phone changed. A group failing is an enforcement problem: stop stacking Security Defaults, per-user MFA, and Conditional Access, standardize on Conditional Access, and read the policy to see whether the block is intentional. Keep break-glass accounts excluded so you always have a way back in, and treat app passwords as a last resort for legacy apps you can’t modernise yet.
If you’re rolling MFA out for the first time rather than fixing it, start with our guide on enabling MFA for Microsoft 365 users, then layer Conditional Access on top once everyone is registered.
