A user who loses their authenticator cannot finish sign-in, and they should not be able to remove that factor with the factor they no longer have. Recovery is a support action. You verify who they are some other way, then you reset MFA in the console.

Enrollment, factors, and the hosted challenge are in [Multi-factor authentication](/docs/mfa). This page is the reset.

## Reset a user

1. Confirm their identity outside the lost factor. A ticket, a video call, or an identity provider your company already trusts. The console reset does not do this check for you.
2. Open the [console](https://console.authdog.com) and select the environment the user belongs to. A reset in `dev` does nothing for `production`.
3. Open the user and disable MFA.
4. Ask them to enroll a new authenticator before they need to sign in from a new device.
5. Read [audit logs](/docs/audit-logs) for the disable action and for sign-ins you don't recognize.

Disabling MFA deactivates the active TOTP secret and the backup codes that were issued with it. Treat the reset as privileged. Limit who can open the user record, and keep the approval next to the audit event.

## What the user can and cannot do

Backup codes are returned when the user enrolls TOTP. Store them in a password manager at that moment. The hosted MFA screen accepts the 6-digit authenticator code or an 8-digit backup code. A backup code works once. Authdog marks it used and still opens the session.

There is no public REST endpoint for enrollment or reset. Management operations the console uses are internal. Build the support process around the console, not around calling those operations from your app.

If **Enforce MFA for all users** is on, the user must enroll again at the next sign-in. If MFA is only available and not enforced, a reset leaves them with a password-only account until they enroll. Decide which of those you want before you disable the factor. An unenforced account after a reset is a gap.

## After a suspicious reset

A reset that the user did not ask for is an account takeover in progress. Suspend the user, review `MFA_SIGNIN_FAILURE` and later successful sign-ins, and rotate anything that user could reach. [Session security](/docs/secure/session-security) covers revocation. [Stop MFA fatigue](/docs/recipes/stop-mfa-fatigue) covers push bombing, which is a different failure: the user still has the factor, and someone is wearing them down.

TOTP is not phishing-resistant. A site that proxies the code can pass this challenge. Recovery does not fix that. Fewer people who can disable MFA does.

## Related

| Read | To learn how to |
| --- | --- |
| [Multi-factor authentication](/docs/mfa) | Factors, enrollment, and the hosted challenge |
| [Audit logs](/docs/audit-logs) | Evidence of the reset and of later sign-ins |
| [Users](/docs/console/users) | The user record you edit |
| [Stop MFA fatigue](/docs/recipes/stop-mfa-fatigue) | Cap repeated MFA prompts |