01
Verify the user
Follow the organization’s identity-verification process before changing authentication methods. MFA recovery is a security-sensitive admin action.
Everyday IT · MFA Recovery
Recover the user without weakening the tenant.
Lost phone, broken Authenticator registration, missing prompt, or a new device can all look like “MFA is broken.”Verify identity first, identify the failing factor, then use the approved recovery path.
The safe recovery path
Do not delete every method or disable policy as the first move.
02
Prove the password layer
Determine whether the password is accepted and the failure occurs afterward. If the password itself fails, do not treat the ticket as MFA yet.
03
Review registered methods
Identify the expected phone, Authenticator registration, security key, or other approved factor. Preserve any known-good recovery method.
04
Use the approved bootstrap method
Use the organization’s supported recovery method, such as another working factor, re-registration, Temporary Access Pass, or the approved vendor-specific enrollment process.
Missing prompt does not automatically mean MFA is down
The sign-in may never be reaching the MFA stage.
Password rejected
MFA may never be called
If authentication fails before the second factor, troubleshoot the account state, password, sign-in block, or upstream identity path first.
Prompt goes elsewhere
Old registrations survive
A replaced phone or stale registration can send the challenge to a device the user no longer has.
One app fails
Check session and token state
If browser sign-in works but one application does not, focus on that client’s cached session, device state, or token before resetting the user’s MFA again.
Policy block
Read the sign-in evidence
Conditional Access or another security control may be intentionally denying the sign-in even when the password and registered factor are correct.
What not to do
A quick bypass can create a larger security problem than the original ticket.
Do not
Disable MFA tenant-wide
Do not weaken broad security controls to solve one user’s registration problem.
Do not
Delete every method blindly
Removing a working method can eliminate the cleanest recovery path.
Do not
Keep resetting the password
If the password is already accepted, another reset adds noise rather than evidence.
Escalate
When policy or identity is unclear
Escalate when sign-in logs show a policy block you do not own, the user cannot be verified, privileged access is involved, or the recovery path would require weakening security.
Recover access. Preserve the control.
The ticket is complete only after the user successfully signs in to the real application that originally failed.