Multi-factor authentication helps protect accounts when passwords are stolen, but users can lose the phone or security key that provides their second factor. Recovery codes offer an emergency route back in. Because they bypass the usual factor, they must be treated as powerful credentials rather than a convenience feature. A good design balances availability for legitimate users with clear limits against theft and social engineering.
Generate codes at enrollment
Create recovery codes only after the user has completed a strong authenticated session and enrolled an MFA method. Use a cryptographically secure source and make each code unpredictable and single use. Show them once with instructions to store them separately from the device used for sign-in. Do not email them or place them in ordinary account notifications. Store a hash or other verifier rather than plaintext where the implementation allows it. The application should be able to verify a code without a support agent ever seeing the user's list.
Keep the number and scope limited
A small set of codes is usually enough. Each code should be consumed atomically so two simultaneous attempts cannot reuse it. Rate-limit attempts and avoid response differences that help an attacker guess whether a code was close to valid. Codes should recover access to the account, not silently grant a higher tenant role. For highly privileged accounts, using a recovery code may trigger a limited session that requires additional review before changing sensitive settings. Define that policy in advance so support does not improvise during a lockout.
Make regeneration safe
A user who still has access may generate a new set, which should invalidate the old set immediately. Require recent authentication or another strong factor before regeneration. Notify the user through a separate channel when codes are generated or used. If suspicious activity is detected, revoke active sessions and review account changes. The panel should state how many unused codes remain without revealing them. An administrator may need to enforce regeneration after a security incident, but should not be able to read another user's codes.
Plan for total loss
Some users will lose both their factor and recovery codes. A support-based recovery process may be necessary, but it can become the weakest link. Define what evidence is accepted, who approves the action, and whether a waiting period or notification applies. Avoid knowledge questions based on public or easily discovered facts. For organization administrators, consider a second administrator or a documented ownership verification process. Test the case in which the only admin is locked out, because that is when staff feel the most pressure to make an unsafe exception.
Audit recovery events
Record the time, account, tenant, method, and outcome of recovery without logging the code itself. Alert users to successful recovery and to new factor enrollment. Review repeated failed attempts and unusual changes following recovery. A code used from an unfamiliar location is not automatically malicious, but it deserves context. Keep audit data accessible to authorized security and support staff. Recovery is part of the account lifecycle and should be included in incident response plans.
Measure the user experience
Track lockouts, support requests, and failed recovery attempts. If most users never store codes successfully, improve the enrollment instructions or offer an additional registered passkey. Do not remove recovery because it is hard; make it safer and clearer. For SMB applications, a simple, tested set of single-use codes can prevent costly account lockouts. Its security depends on generation, storage, consumption, and the human fallback all being treated as one coherent design. Include recovery in routine security testing: an MFA policy is only as strong as the path used when the normal factor is unavailable. Check that resetting a password alone does not bypass the required second factor.