A person loses a phone, replaces a laptop or finds that an email account has been taken over. The recovery screen now decides whether the legitimate owner gets back in, and whether an attacker can take the account instead.
A useful recovery flow starts by treating recovery as a separate security ceremony. It is not simply a shorter login.
Map the ways a person can prove control
NIST recognizes four broad recovery methods: saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing. A service can also use an application-specific method after a documented risk analysis.
That list is a design prompt. Write down every recovery route your product actually offers, including customer support. Then record what evidence each route accepts and what level of account it can restore.
A high-value account should not fall back from two strong factors to one email link. NIST’s current guidance requires stronger combinations for accounts that can authenticate at Authentication Assurance Level 2. That can mean two recovery codes obtained through different methods, one recovery code plus a remaining authenticator, or repeated identity proofing.
Give people a second path before they need it
Recovery is safer when people prepare while they still have access. NIST recommends encouraging subscribers to keep at least two separate means of authentication.
The product implication is simple: do not bury backup setup in a security page nobody sees. Offer it after enrollment, after a successful sign-in on a new device, and when a user removes an authenticator. Good options include an additional passkey, a second hardware key or an offline recovery code.
This complements a careful passkey recovery design. A synced passkey may survive a device change, but its cloud account can have a recovery process of its own. Device loss and account takeover are different failure cases.
Make a recovery code act like a secret
A recovery code should not behave like a permanent support number. NIST says a saved recovery code should contain at least 64 random bits, be stored by the service in hashed form and be invalidated after use. The service should issue a replacement after a successful recovery.
Issued codes need short, explicit lifetimes. NIST sets maximum validity periods of ten minutes for text or voice delivery and 24 hours for email delivery. A product may choose a shorter period when the risk justifies it.
For a product team, this means the code record needs a state machine: created, delivered, attempted, consumed, expired or revoked. Logging only a generic “password changed” event hides the part of the flow that needs investigation.
Do not reveal whether an account exists
A forgot-password form can become a directory of customers. OWASP recommends returning the same message for existing and non-existing accounts and keeping response timing consistent.
The service also needs limits on automated submissions. Per-account rate limits, abuse controls and asynchronous processing can stop an attacker from flooding someone’s inbox or phone. Do not lock an account merely because a reset was requested. OWASP recommends making no account change until the requester presents a valid token.
The visible message can stay calm: “If an account matches those details, we’ll send recovery instructions.” The backend should still record the request and its abuse signals.
Separate password reset from compromised-account recovery
A routine forgotten password and a suspected takeover need different endings. OWASP notes that changing the password alone may leave an attacker with an active session, a newly added recovery address or a changed MFA method.
After recovery from suspected compromise, review authenticators and recovery channels with the verified owner. Invalidate sessions, outstanding reset links and unused recovery codes. Remove unauthorized changes. Send notifications through established channels that remain safe.
This is where audit-log design matters. The log should show who initiated recovery, which method succeeded, which authenticators changed and when old sessions stopped working. It should avoid storing the secret itself.
Notify without making the notification the only defense
NIST requires account-recovery notifications. The notice helps the owner catch a fraudulent recovery, but it arrives after a sensitive action has started or completed.
Send it to previously established addresses where possible. Include the time, the action that changed and a clear way to report an unauthorized event. Avoid putting live recovery links, codes or sensitive account data in the message.
A notification should be useful even if the attacker changed one channel. Products with higher-risk accounts may need more than one independent notification route.
Test the failure cases, not only the happy path
A practical review can use a short set of scenarios:
- the user lost one authenticator but still controls another;
- the user lost every authenticator;
- the email address was recently changed;
- the attacker still has a valid session;
- the user cannot access a phone number while traveling;
- support receives convincing but incomplete identity evidence;
- a recovery code is replayed after use.
For each case, identify the acceptable proof, the waiting period, the notification path and the artifacts that are revoked. Then test what happens if any step is repeated.
Recovery will always add friction. The goal is to place that friction where it protects ownership, while giving prepared users a reliable second route before an emergency.
