Handle lost MFA with single-use recovery codes issued at setup, a requirement to enrol more than one factor, and a documented support identity check. Never let the fallback be weaker than the primary method, because attackers will go straight to the recovery path.
Why recovery is the real attack surface
When a strong factor is hard to attack, attackers ask support to reset it. A reset flow that accepts an email address and a date of birth turns your MFA into a speed bump. OWASP states the principle plainly: fallback must not be weaker than the primary method.
Recovery options and their trade-offs
OWASP lists several, each with a different cost.
- Single-use recovery codes: strong if stored safely, but users lose or ignore them.
- Several factor types enrolled: strong, but needs enrollment nudges.
- One-time code to a registered address: only as strong as that mailbox, which is weak if email has no MFA.
- Support identity check: depends on your process, slow, and a social engineering target.
- Vouching by a trusted user: good for teams, but needs an admin model.
Design rules
- Issue recovery codes at setup and show them once. Tell users to store them in a password manager or printed in a safe place.
- Make each code single use and invalidate all of them when a new set is generated.
- Require more than one factor type where you can, so losing a phone is not total loss.
- Block downgrades. OWASP recommends blocking downgrades from phishing-resistant authenticators unless a documented policy requires it.
- Notify on failed second factors and on any reset, as OWASP advises.
- Re-authenticate and end sessions after a reset, so an attacker who got in earlier is thrown out.
- Protect the support path. Written checks, two person approval for privileged accounts, and a log of every reset.
For teams, not just products
Admin accounts need a plan that does not depend on one person's phone. Keep a second admin, and store break-glass credentials in a separate system as OWASP's secrets guidance suggests. Review the list of who can reset whom.
For passkeys specifically, see passkey account recovery design.
Audit the reset history every quarter. Count how many resets happened, who approved them and how the person was verified. Look for patterns, such as many resets requested out of hours or from a new country. A sudden rise often means attackers have found your support path. Feed what you learn back into the identity check script, and retire any step that an attacker could pass using only public information.
Quick check
Should recovery codes be emailed?
Avoid it. Show them once in the app at setup so they are not sitting in a mailbox that may lack its own MFA.
Who can reset an admin's MFA?
Name a small group, require a second approver, and log it. A help desk agent alone should not be able to.
Sources
Last reviewed: 19 October 2026.
