M365 MFA Troubleshooting Guide (2026)

Why MFA Troubleshooting Is Every Helpdesk's Top Priority in 2026

If you're working an IT helpdesk right now, you already know — MFA tickets have basically taken over. Microsoft completed mandatory MFA enforcement for all Microsoft 365 admin accounts on February 9, 2026, as part of its Secure Future Initiative. And then, just two weeks later on February 23, a major MFA outage (incident MO1237461) hit North American users with 504 gateway timeout errors during authentication.

So yeah, helpdesks everywhere are drowning in MFA calls.

This guide gives you a systematic, no-nonsense approach to diagnosing and resolving every common MFA issue — from users who can't receive push notifications to admins completely locked out of their own tenant. I've organized it the way I wish someone had organized it for me when I was neck-deep in tickets.

How MFA Works in Microsoft 365: A Quick Refresher

Before we dive into troubleshooting, let's make sure we're on the same page about the three layers controlling MFA behavior in Microsoft 365:

Security Defaults — A tenant-wide toggle that enforces MFA for all users. Simplest option, but you get zero granularity.
Conditional Access Policies — Rules that trigger MFA based on conditions like user role, location, device compliance, or risk level. You'll need at least a Microsoft Entra ID P1 license for this one.
Per-User MFA — The legacy method that sets MFA state (Enabled, Enforced, or Disabled) on individual accounts. Microsoft really wants you to move away from this, and honestly, you should.

When someone says MFA "doesn't work," it usually falls into one of two buckets: MFA never triggers at all (a policy config issue), or MFA triggers but the user can't complete authentication (a device or method issue). Knowing which bucket you're in saves you a ton of time.

MFA Not Triggering at All

Security Defaults Are Disabled and No Conditional Access Policy Exists

This is the most common "MFA not working" scenario helpdesks run into, and it's almost embarrassingly simple. If Security Defaults are turned off and no Conditional Access policy enforces MFA, users just sign in with a password. That's it.

How to verify:

Sign in to the Microsoft Entra admin center.
Navigate to Identity > Overview > Properties.
Scroll to Manage Security Defaults and check if it's enabled.
If disabled, head over to Protection > Conditional Access > Policies and confirm at least one policy grants access with an MFA requirement.

User Is Excluded from the Policy

Conditional Access policies allow exclusions by user, group, or role. One misconfigured exclusion can silently bypass MFA for an entire department — I've seen this happen more than once. Check the Exclude tab on every active policy to make sure the affected user isn't in an excluded group.

User Is Signing In from a Trusted Location

Many orgs define their office IP ranges as "trusted locations" and skip MFA for sign-ins from those IPs. If a user says MFA works from home but not the office, this is almost certainly why. Review Protection > Conditional Access > Named locations to verify your trusted IP definitions.

Legacy Authentication Protocols Are Still Active

Here's one that catches people off guard: legacy protocols like POP3, IMAP, and SMTP AUTH bypass MFA entirely. If users can authenticate without MFA using older email clients, you need to block legacy auth. Create a Conditional Access policy targeting Other clients under Conditions > Client apps and set the action to Block access.

MFA Triggers but the User Can't Complete Authentication

Microsoft Authenticator Push Notifications Not Arriving

This is the big one — the single most common MFA helpdesk ticket. The user's phone buzzes with nothing, or the Authenticator app just sits there with no pending approval. Work through these steps in order:

Check notification permissions — On Android: Settings > Notifications > App settings, confirm Authenticator notifications are enabled. On iOS: Settings > Notifications > Authenticator, enable Allow Notifications.
Disable battery optimization (Android) — Battery saver loves killing background processes. Go to Settings > Battery > Battery Optimization, find Microsoft Authenticator, set it to Not Optimized.
Verify internet connectivity — Push notifications need an active data connection. Have the user toggle between Wi-Fi and mobile data to test.
Update the app — Outdated versions cause silent failures more often than you'd think. Check the App Store or Google Play.
Check date and time settings — Time drift breaks TOTP codes and can mess with push notifications too. Make sure the device is set to automatic date/time.
Remove and re-add the account — In the Authenticator app, remove the work account and re-register from aka.ms/mysecurityinfo. Just make sure the user has an alternative method available before you do this.

SMS Verification Codes Not Arriving

SMS-based MFA is inherently less reliable than the Authenticator app. Common failure points:

Full message inbox — Have the user clear old messages and try again.
Carrier delays — Some carriers throttle short codes. Give it 5 minutes before requesting a new code.
VOIP numbers — Microsoft flat-out won't deliver MFA codes to VOIP numbers. The user needs a real mobile number.
Rate limiting — Mashing "Resend Code" repeatedly triggers a temporary block. Wait 10 minutes, then try once more.

TOTP Codes Rejected (Time-Based One-Time Passwords)

If the six-digit code from the Authenticator app keeps failing, the culprit is almost always time drift on the user's phone. TOTP codes are only valid for 30 seconds, and they depend on synchronized clocks.

Fix: On the user's phone, go to Settings > Date & Time and enable Set Automatically. Have them restart the phone after changing this — it makes a difference.

User Is Stuck in an MFA Loop

The user enters their password, completes MFA, gets prompted for MFA again. Rinse and repeat forever. This one's frustrating for everyone involved.

Common causes:

Conflicting Conditional Access policies — Two policies with different session controls can create loops. Use the What If tool in Conditional Access to simulate the user's sign-in and spot the conflict.
Browser cookies or cache — Have the user clear browser data or try an InPrivate/Incognito window.
Stale refresh tokens — Revoke sessions for the user in Entra > Users > [User] > Revoke sessions.

MFA Prompting Too Frequently

Users complaining about MFA prompts "every single time" is both a morale issue and a productivity killer. Here's how to dial it back without compromising security:

Check Sign-in Frequency settings — In your Conditional Access policy, go to Session > Sign-in frequency. Setting this to 90 days for compliant, Entra-joined devices is pretty standard.
Enable persistent browser sessions — In the same Session section, enable Persistent browser session so users don't get prompted after closing their browser.
Ensure the device is Entra-joined or registered — Unmanaged devices will always get more frequent prompts. Run dsregcmd /status on the device to check its join state.
Check for browser extensions — Some privacy or ad-blocking extensions strip authentication cookies. Have the user try with all extensions disabled.

The "New Phone" Reset: Step-by-Step MFA Method Reset

"I got a new phone and can't sign in" — if I had a dollar for every time I've heard this one. Here's the fastest resolution path.

Method 1: Microsoft Entra Admin Center (GUI)

Sign in to entra.microsoft.com as an Authentication Administrator or higher.
Go to Identity > Users > All users.
Select the affected user, then click Authentication methods.
Click Require re-register multifactor authentication.
The user will be prompted to set up MFA on their next sign-in.

Important: Always verify the user's identity before resetting MFA. Call them at their known office number or confirm through their manager. Unauthorized MFA resets are a real attack vector — don't skip this step.

Method 2: Microsoft Graph PowerShell (Bulk or Scripted Resets)

For resetting a single user's authentication methods via PowerShell:

# Connect to Microsoft Graph with the required scope
Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"

# Get the user's registered authentication methods
$userId = "[email protected]"
$methods = Get-MgUserAuthenticationMethod -UserId $userId

# List all registered methods
$methods | ForEach-Object {
    Write-Host "Method: $($_.AdditionalProperties['@odata.type']) - Id: $($_.Id)"
}

# Remove a specific method (e.g., phone method)
Remove-MgUserAuthenticationPhoneMethod -UserId $userId -PhoneAuthenticationMethodId $phoneMethodId

# Remove Microsoft Authenticator method
Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId $userId `
    -MicrosoftAuthenticatorAuthenticationMethodId $authenticatorMethodId

For bulk resets across multiple users, a CSV-based approach works well:

# Bulk MFA reset from CSV
$users = Import-Csv "C:\MFA-Reset-Users.csv"

foreach ($user in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $user.UserPrincipalName
    foreach ($method in $methods) {
        $type = $method.AdditionalProperties['@odata.type']
        switch ($type) {
            "#microsoft.graph.phoneAuthenticationMethod" {
                Remove-MgUserAuthenticationPhoneMethod -UserId $user.UserPrincipalName `
                    -PhoneAuthenticationMethodId $method.Id
            }
            "#microsoft.graph.microsoftAuthenticatorAuthenticationMethod" {
                Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod `
                    -UserId $user.UserPrincipalName `
                    -MicrosoftAuthenticatorAuthenticationMethodId $method.Id
            }
            "#microsoft.graph.softwareOathAuthenticationMethod" {
                Remove-MgUserAuthenticationSoftwareOathMethod `
                    -UserId $user.UserPrincipalName `
                    -SoftwareOathAuthenticationMethodId $method.Id
            }
        }
    }
    Write-Host "Reset MFA methods for $($user.UserPrincipalName)"
}

Admin Lockout: Recovering Access When MFA Blocks Your Only Global Admin

With mandatory MFA enforcement now active, a surprising number of small businesses have discovered — the hard way — that they can't access their tenant because their sole global admin account never had MFA configured. If this sounds like your situation, here's what to do.

If You Have Another Global Admin Available

Sign in with the other admin account at entra.microsoft.com.
Navigate to Identity > Users > [locked-out admin].
Click Authentication methods and select Require re-register multifactor authentication.
The locked-out admin can now sign in and set up MFA fresh.

If You Have Only One Global Admin

This is the nightmare scenario. Only Microsoft's specialized Data Protection team can help you here.

Contact Microsoft Global Customer Service by phone — don't try the online support portal (you can't get in, obviously).
Request an authentication method reset for your admin account.
Microsoft will verify your organization's identity through domain ownership verification and other checks. This can take a while.
Once verified, they'll reset your MFA methods so you can re-enroll.

Prevention: This scenario is 100% avoidable. Set up emergency access accounts before you need them. Seriously — do it today if you haven't already.

Emergency Access (Break-Glass) Accounts: Your Safety Net

Every organization should have at least two emergency access accounts. No exceptions. Here's the current best-practice configuration for 2026:

Cloud-only accounts using the *.onmicrosoft.com domain — never federated or synced from on-premises.
Permanently assigned the Global Administrator role — not eligible for PIM activation. These need to work when everything else is broken.
Not tied to any individual — these are organizational accounts, not personal ones.
Use phishing-resistant MFA — FIDO2 security keys are the way to go here. Don't use SMS or phone call MFA for break-glass accounts.
Exclude at least one from all Conditional Access policies — MFA is still required for Azure, Entra, and Intune portal sign-ins even when excluded from CA policies, but this prevents other CA rules from blocking access.
Store credentials securely — write the password on paper (yes, paper) and store it with the FIDO2 key in a fireproof safe. Some orgs split the password between two trusted individuals for added security.
Monitor every sign-in — set up an alert rule that fires whenever either break-glass account signs in. Any unexpected use warrants immediate investigation.

Diagnosing MFA Issues with Sign-In Logs

The Entra sign-in logs are honestly your best friend when troubleshooting MFA. Here's how to get the most out of them:

Go to Entra admin center > Identity > Monitoring & health > Sign-in logs.
Filter by the affected user's UPN and the relevant time window.
Click on a failed sign-in event to see the Authentication Details tab — it shows exactly which MFA method was attempted and why it failed.
Check the Conditional Access tab to see which policies were evaluated, applied, or failed.
Look at the Error code. Here are the MFA-related ones you'll see most often:
- 50074 — Strong authentication required (MFA needed but not completed).
- 50076 — User didn't pass the MFA challenge.
- 50079 — User must register for MFA.
- 53003 — Access blocked by Conditional Access.
- 500121 — Authentication failed during strong authentication request.

Using the Conditional Access What If Tool

Before you touch any policies, simulate the impact first. I can't stress this enough.

Go to Protection > Conditional Access > Policies.
Click What If in the toolbar.
Select the user, the target app (e.g., Office 365), and the conditions (device platform, location, etc.).
Click What If to see exactly which policies would apply and what the result would be.

This tool has saved me from breaking MFA for entire organizations more times than I'd like to admit. Use it.

Moving to Phishing-Resistant MFA: The 2026 Standard

Microsoft's direction is crystal clear: SMS and phone-call MFA are legacy. The future is phishing-resistant, passwordless authentication. Here are the tiers of authentication strength available in Entra Conditional Access:

Strength Level	Methods Included	Recommended For
MFA Strength	Authenticator push, TOTP, SMS, phone call, FIDO2, Windows Hello	General users
Passwordless MFA Strength	Authenticator passwordless, FIDO2, Windows Hello for Business	Knowledge workers
Phishing-Resistant MFA Strength	FIDO2 security keys, Windows Hello for Business, Certificate-based auth	Admins and privileged roles

To enforce phishing-resistant MFA for admin roles, create a Conditional Access policy targeting Administrative roles, require Grant > Require authentication strength, and select Phishing-resistant MFA.

A quick note on number matching in Microsoft Authenticator: it's now enabled by default, and while it's a step in the right direction, it's not truly phishing-resistant. It still relies on a shared secret. Genuinely phishing-resistant methods use cryptographic key pairs bound to specific origins, making them immune to man-in-the-middle attacks. That's the standard you want to aim for, especially for privileged accounts.

Handling MFA During Microsoft 365 Outages

The February 23, 2026, MFA outage proved that even Microsoft's authentication infrastructure can go down. When MFA is broken tenant-wide, here's your playbook:

Confirm it's a Microsoft issue — Check the Microsoft 365 Service Health Dashboard, DownDetector, and the Microsoft 365 Status account on X.
Communicate immediately — Tell users it's a known issue and they should stop retrying. Repeated failures can trigger account lockouts, which just makes everything worse.
Consider a temporary CA policy exception — If business-critical operations are blocked, you can temporarily exclude affected users from MFA policies. Document the change and set a calendar reminder to revert it. Don't forget that last part.
Use break-glass accounts — This is literally what they're for.
Monitor for recovery — Once Microsoft resolves the incident, test MFA with a small pilot group before announcing the all-clear.

After the outage: Review your incident response and make sure your break-glass accounts actually work (test them). Document the timeline and resolution for your ITSM records.

Helpdesk Cheat Sheet: Quick MFA Diagnosis Flowchart

Keep this decision tree handy for first-line triage. Print it out, pin it to the wall — whatever works for your team:

User reports MFA issue
│
├── MFA never prompts?
│   ├── Check Security Defaults status
│   ├── Check Conditional Access policies for exclusions
│   ├── Check if legacy auth protocols are in use
│   └── Check Named Locations / Trusted IPs
│
├── MFA prompts but user can't complete?
│   ├── Authenticator push not arriving?
│   │   ├── Check notification permissions
│   │   ├── Check battery optimization (Android)
│   │   ├── Update Authenticator app
│   │   └── Remove and re-add account
│   ├── SMS code not arriving?
│   │   ├── Check phone inbox space
│   │   ├── Verify not a VOIP number
│   │   └── Wait 10 min if rate-limited
│   └── TOTP code rejected?
│       └── Fix device time sync
│
├── MFA loops endlessly?
│   ├── Check for conflicting CA policies (What If tool)
│   ├── Clear browser cache / try InPrivate
│   └── Revoke user sessions in Entra
│
└── User got new phone / lost device?
    ├── Verify identity (call office phone / manager)
    └── Reset MFA via Entra admin center or PowerShell

Frequently Asked Questions

How do I reset MFA for a Microsoft 365 user who got a new phone?

Sign in to the Microsoft Entra admin center as an Authentication Administrator. Go to Identity > Users > All users, select the user, click Authentication methods, and choose Require re-register multifactor authentication. They'll set up MFA again on their next sign-in. And please — always verify the user's identity before performing this reset. Call them at a known number or confirm through their manager.

Why does Microsoft 365 keep asking for MFA every time I sign in?

Excessive MFA prompts usually come down to one of these: Conditional Access sign-in frequency settings, unmanaged or non-compliant devices, browser extensions stripping authentication cookies, or the device not being properly Entra-joined. Check your CA policy session controls and run dsregcmd /status on the device to see what's going on.

What should I do if MFA is down for all users in my organization?

First, confirm it's a Microsoft-side outage — check the Microsoft 365 Service Health Dashboard and DownDetector. Tell users to stop retrying (repeated failures can trigger account lockouts). Use your emergency break-glass accounts for admin access. If operations are truly business-critical, consider a temporary Conditional Access policy exception, but revert it the moment the outage is resolved.

Is SMS-based MFA secure enough for Microsoft 365?

It's way better than no MFA at all, but it's the weakest MFA option available. SMS codes can be intercepted through SIM swapping, SS7 network attacks, and social engineering. Microsoft recommends the Authenticator app as a minimum, and phishing-resistant methods like FIDO2 security keys or Windows Hello for Business for anyone with a privileged account. The direction for 2026 and beyond is clearly phishing-resistant, passwordless authentication.

How do I set up emergency break-glass accounts for my Microsoft 365 tenant?

Create two cloud-only accounts using your *.onmicrosoft.com domain. Assign both the Global Administrator role permanently (not through PIM). Register FIDO2 security keys as their MFA method — skip SMS and phone call entirely. Exclude at least one from all Conditional Access policies. Store the passwords and FIDO2 keys in physically separate, secure locations (fireproof safes are ideal). Finally, set up alerts to monitor any sign-in activity on these accounts — if someone's using them, you want to know about it immediately.