A user contacts support: "I lost my phone, I can't sign in." The platform's MFA requirement is doing its job — and that's the problem the user is having. You need to restore their access without weakening the security posture.
This is a runbook. Follow it.
Step 1 — Verify identity out-of-band
Section titled “Step 1 — Verify identity out-of-band”The user wants you to bypass an MFA check. Before you do anything, confirm they are who they say they are.
Acceptable verification:
- Live video call. They show themselves on video; corroborate against your records (HR photo, ID).
- Phone call to a known number. You call them on a number that was on their account before today (not the number they just supplied — that could be the attacker's).
- Corroborating internal ticket. Their manager / HR has opened a ticket vouching for the request.
- Existing strong auth. They can sign in via a federated identity (Google / SAML / etc.) you also have configured — using that as proof of identity before resetting MFA on the password identity.
NOT acceptable verification:
- "I told you my email and you matched it." — phishing-trivial.
- "I know my birthday + last 4 of SSN." — knowledge-based questions are widely-known answers; attackers find them.
- "Email me a code to my recovery address." — if the user's email is compromised, the attacker reads the code.
- "Slack / chat from someone claiming to be the user." — accounts are stolen; verify out-of-band.
If verification is uncertain, ask for more. Don't proceed.
Step 2 — Check backup codes
Section titled “Step 2 — Check backup codes”Before force-resetting MFA, check: did the user save backup codes when they enrolled?
User detail → MFA tab → look at "Backup codes" section. Shows "X codes remaining" if any.
If backup codes exist:
- Walk the user through using one. They sign in with email + password + a backup code.
- After they sign in, they re-enrol a new MFA factor from their own profile page.
- Tell them to regenerate backup codes after enrolling.
You haven't had to force-reset anything. The user owns the recovery.
If backup codes don't exist (or they've used them all), continue.
Step 3 — Force MFA reset
Section titled “Step 3 — Force MFA reset”User detail → Actions menu → Force MFA reset.
This removes all enrolled factors. Confirm in the modal.
What you've done:
- The user's existing MFA factors are gone.
- Next sign-in: they enter email + password; then they're routed to enrolment for a new factor.
The audit log records mfa.factor_admin_reset with you as the actor + the reason field (fill it in: "Lost device; identity verified via video call 2026-05-17, see ticket #1234").
Step 4 — Wait for the user to sign in + enrol
Section titled “Step 4 — Wait for the user to sign in + enrol”The user signs in. They land on the enrolment page. They enrol a new factor (TOTP via a new phone, or WebAuthn via a new device). They're back in.
Optionally: have them regenerate backup codes after enrolling. Copy + store somewhere safe.
The audit log records mfa.factor_enrolled with the new factor; closes the loop.
Step 5 — Communicate
Section titled “Step 5 — Communicate”Send the user a follow-up:
- Confirm what was done ("I removed your MFA factors at YOUR request; you've re-enrolled with a new device").
- Encourage them to save backup codes this time.
- Note that this action is in our audit log for review.
Keep the follow-up brief; the recovery is done.
What can go wrong + how to recover
Section titled “What can go wrong + how to recover”"The user can't enrol a new factor either"
Section titled “"The user can't enrol a new factor either"”They lost their device AND their authenticator app. Reset to backup codes only:
User detail → MFA → Generate backup codes for this user (admin action). The user gets the codes via the same secure channel you used for identity verification (call, video, etc.). They sign in with email + password + backup code; they enrol a proper factor from their profile.
"The request was actually a social-engineering attack"
Section titled “"The request was actually a social-engineering attack"”You force-reset; the "user" wasn't the user; the attacker now has their account.
Mitigations after-the-fact:
- Suspend the user (Users → Disable). Cuts off the attacker.
- Notify the actual user via your other contact channels (HR-on-file phone, in-person check-in).
- Audit-log the incident with what happened + how it was discovered.
- Force password reset + a real MFA reset when the actual user is verified.
This is the failure mode the verification step is designed to prevent. If it happens to you, treat as a security incident; review the process.
"The user has a federated identity AND a password identity"
Section titled “"The user has a federated identity AND a password identity"”If they signed in via Google or SAML, they could sign in with that identity and re-enrol MFA themselves. Walk them through it; no force-reset needed on your side.
"The user can't access their email"
Section titled “"The user can't access their email"”Email is the recovery channel. If they can't read email, you've lost the channel.
Sequence: verify identity out-of-band → admin force-reset MFA → reset password → admin-set a temporary password → share the temporary via the secure channel → user signs in with new password + enrols MFA.
What audit captures
Section titled “What audit captures”Every step of this runbook generates audit:
mfa.factor_admin_reset— the force-reset.user.password_set_by_admin— if you reset their password.mfa.factor_enrolled— they enrol a new factor.- (You should also write a reason in each action's reason field — visible in audit.)
The audit trail is the paper trail. Six months from now, a compliance auditor asks "show me every admin-initiated MFA reset"; you produce the filtered audit log.
When to refuse
Section titled “When to refuse”Some requests should be refused without escalation:
- The user can't verify their identity out-of-band.
- The user is pressuring you ("this is urgent! I need it now!"). Urgency is a classic social engineering pattern.
- The user's account has unusual recent activity (multiple failed sign-ins from unusual IPs).
- Your gut says no.
Escalate to a senior tenant admin. Document the refusal in audit (you can audit-log a manual entry via the admin console's "Note" feature on the user's record).