A user lost their phone with the authenticator app on it. Or their security key. Or they wiped their device. They can't sign in because they can't complete the MFA step. Force MFA reset is the escape hatch.
What it does
Section titled “What it does”User detail page → Actions menu → Force MFA reset.
- Every enrolled MFA factor for this user is removed.
- The next time the user signs in, the platform demands MFA enrolment as the first step.
- The user enrols a new factor (usually a new TOTP code or WebAuthn credential) and proceeds.
This is one of the higher-risk operations in the console because it removes the second factor that protects the account. Treat it like a sensitive operation:
- Verify the user's identity out-of-band (a phone call to a known number; a video call; a corroborating IT-ticket process).
- Don't rubber-stamp it. The audit log records you as the actor; if the request was social-engineered, you're the one who let it through.
The platform's safeguards
Section titled “The platform's safeguards”Force MFA reset on its own doesn't reveal anything to an attacker — they still need the password to complete sign-in. But if the password is also compromised, force-reset hands the account over.
Tenant policy can require step-up for force MFA reset — the platform demands you (the admin) prove your own AAL is high enough before the action is allowed. Configure in Settings → Authentication policy → Admin step-up requirements. We recommend leaving it on.
After the reset
Section titled “After the reset”The user signs in:
- Email + password (still required).
- Enrolment flow — same as new-user MFA enrolment. Pick factor, set up, confirm.
- Backup codes — usually regenerated as part of this flow; user copies them.
Audit log records the full sequence:
mfa.factor_admin_reset(you removed all factors)user.signed_in.mfa_required(next sign-in attempt)mfa.factor_enrolled(the new factor)
Common scenarios
Section titled “Common scenarios”"I lost my phone, but I have backup codes"
Section titled “"I lost my phone, but I have backup codes"”The user doesn't need an admin reset. They sign in with their password + a backup code. After signing in, they re-enrol a new factor from their profile page.
Don't force-reset just because they ask — check backup codes first.
"I lost my phone and I never wrote down backup codes"
Section titled “"I lost my phone and I never wrote down backup codes"”This is the legitimate case for admin force-reset.
"Someone in my family/team had access to my old phone and might still have it"
Section titled “"Someone in my family/team had access to my old phone and might still have it"”Force-reset AND revoke sessions AND reset password. Belt-and-braces; reset everything so the old device is fully out of the picture.
"I'm reading this guide to set up a process for my support team"
Section titled “"I'm reading this guide to set up a process for my support team"”The right shape is a documented MFA recovery runbook with an identity-verification step in front of the force-reset. Don't let support agents force-reset on a customer's word alone.
What NOT to do
Section titled “What NOT to do”- Don't force-reset every user when the policy changes. That logs everyone out simultaneously and produces a support deluge. Tighten the policy with a grace period for re-enrolment instead.
- Don't force-reset for "the user just wants to change their TOTP app." They can do that themselves from their profile.
- Don't pair force-reset with a password reset on every reset request. Each is a separate operation with separate justification. Combining them for routine "lost device" cases produces unnecessary churn.