## TL;DR
2FA lockouts need verification before help, not help before verification. Verify identity with two independent factors (account email access plus billing info, ID, or an admin vouch), then use the recovery path: saved recovery codes first, then admin-assisted reset, then re-enrollment. Never disable 2FA on a phone call with no verification. The lockout is the security working; the recovery must be equally careful.

## The query

```text
how to help users who locked themselves out of 2FA
```

## Use this when

- Users lose their authenticator device
- Users get a new phone without migrating
- Users never saved recovery codes
- Writing 2FA recovery procedures

## Not for

- Bypassing 2FA without verification (never)
- 2FA product or UX design
- Enterprise SSO recovery (different flow)
- Sim-swap fraud investigation

## Steps

### 1. Verify identity with two independent factors

Account email access plus one of: billing details (last four of card, invoice number), government ID matching the account name, or an admin on the account vouching. One factor is not enough for a security reset. Document what you verified.

Expected output: two verified factors, logged on the ticket.

### 2. Try recovery codes first

Ask if they saved the recovery codes shown at enrollment. Most users who "lost everything" have them in a password manager or a screenshot. One code gets them in to re-enroll properly.

Expected output: user in via recovery code, or confirmed none exist.

### 3. Perform an admin-assisted reset

With verification complete, an authorized admin disables 2FA on the account. This must require a second pair of eyes or a manager approval: single-agent 2FA resets are how social engineering succeeds.

Expected output: 2FA reset with dual approval logged.

### 4. Re-enroll immediately, in the same session

Do not leave the account without 2FA. Walk the user through enrolling the new device now, and make them save the new recovery codes before closing. Verify the codes work with a test login.

Expected output: 2FA active on the new device, codes saved.

### 5. Log everything

Who verified, what factors, who approved, timestamps. 2FA resets are the highest-risk support action. The log is your defense if the reset is ever questioned.

Expected output: a complete audit trail on the ticket.

## Template: the recovery flow

```text
2FA LOCKOUT RECOVERY
[ ] Identity verified: factor 1 ______ factor 2 ______
[ ] Recovery codes tried: yes / none saved
[ ] Manager approval for reset: ______ (name, time)
[ ] 2FA disabled by admin: [time]
[ ] User re-enrolled on new device: [time]
[ ] New recovery codes saved and tested: yes
[ ] Ticket logged with full trail

NEVER: reset on a single factor, reset without approval, leave the account without 2FA.
```

## Variant phrasings

### lost phone authenticator app

Steps 1 through 4. Verify, codes, reset, re-enroll.

### 2fa recovery without backup codes

Steps 1 and 3. Verification plus dual-approval reset.

### new phone google authenticator locked out

Step 2 first: check for saved codes or cloud backup before the full flow.

## Why it works

2FA exists to stop account takeover, and support-assisted recovery is the classic bypass route attackers try. Two-factor verification plus dual approval makes the recovery as strong as the 2FA itself. The re-enrollment in the same session closes the window where the account sits unprotected.

## Edge cases

- The user cannot verify: do not reset. Offer the longest path (mailed verification, legal process). A hard no beats a breached account.
- Enterprise accounts: route to the customer's IT admin. They own identity; you do not.
- The "user" is aggressive about skipping verification: that is a red flag. Slow down, do not speed up.
- Backup codes were stored on the lost device: proceed to admin reset. Do not accept "just trust me."

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_x78z7VqjpCQIOtk2TzBnLw