Secure Account Recovery: Passwords, Passkeys, and Support

Account recovery is an alternate authentication system. If it is weaker than normal login, attackers will use it instead of attacking the login screen.

A secure recovery design starts before a user loses access. It registers independent recovery factors, explains what happens when a device or email account is lost, and defines what support staff can—and cannot—override. The goal is not recovery at any cost. It is restoring legitimate access without handing the account to someone who knows a birthday, phone number, or invoice.

Map every way a user can lose access

Recovery requirements depend on the authenticators and identifiers the product uses.

User loses	Recovery may use	Main risk
Password	Verified email, passkey, recovery code	Compromised mailbox
Passkey device	Synced passkey, another registered device, recovery code	No independent factor
Email account	Passkey, verified phone, manual review	Attacker changes primary email
Phone number	Email, passkey, recovery code	Recycled number or SIM swap
MFA device	Backup code, another enrolled factor	MFA reduced to a weak help-desk check
Organization administrator	Another authorized administrator, documented governance process	Support grants privileged access

Do not design one universal “contact support” path and improvise the decision each time.

Enroll recovery before it is needed

Ask users to register recovery options while they still control the account. Suitable options may include:

• more than one passkey or device;
• single-use recovery codes stored offline;
• a separately verified recovery channel;
• another authorized organization administrator; or
• an enterprise-managed identity recovery process.

Show users which options are active and when they were added. Let them remove stale devices and regenerate recovery codes after recent authentication.

Do not force every user to add a phone number merely for recovery if the product does not otherwise need it. More personal data is not automatically more security.

Recovery links must be short-lived and single-use

A password-reset or recovery link is a bearer credential. Anyone who obtains it may gain account access.

Generate a cryptographically random value, store only a protected representation where practical, bind it to one account and purpose, expire it quickly, and invalidate it after use. Issuing a new link should invalidate older outstanding links unless the design has a strong reason not to.

Do not place sensitive tokens in analytics events, support tickets, referrer headers, or long-lived logs. The landing page should prevent third-party resources from receiving a URL that still contains the credential.

Prevent account enumeration and request abuse

The public response should not reveal whether an email address or phone number belongs to an account. A neutral message such as “If an eligible account exists, recovery instructions will be sent” reduces enumeration.

Apply rate limits by account identifier, network, device signals, and broader abuse patterns. Per-IP limits alone are weak against distributed attacks and can block many legitimate users behind shared networks.

The authentication rate-limiting guide covers layered controls. Monitor both requests and successful recoveries; a low request rate can still be dangerous if each attempt targets a high-value account.

Treat identifier changes as sensitive actions

Changing a primary email address or phone number can silently transfer future recovery authority.

Require recent authentication, notify the old and new channels where appropriate, and delay or review high-risk changes. Give the user a clear way to report an unauthorized change without relying only on the newly configured channel.

After a material identifier or recovery-factor change, consider revoking other sessions and outstanding recovery links. At minimum, show the user which sessions and factors remain active.

Passkeys still need a recovery plan

Passkeys improve phishing resistance, but “the user has a passkey” does not explain what happens when a device is lost.

Some passkeys synchronize through a platform account. Others are device-bound. A product should not assume synchronization without knowing the authenticator behavior. Encourage multiple authenticators for higher-value accounts and provide recovery codes or an appropriately strong alternative.

Do not undermine passkeys with a recovery path based only on knowledge questions. Public records and social media make names, addresses, schools, and family details poor authenticators.

The passkeys adoption guide explains enrollment and product trade-offs.

Support must not become an authentication bypass

Support staff need a documented decision tree. It should define:

• which evidence is acceptable for each account type;
• which actions require a second reviewer;
• what staff can see;
• what staff can change;
• which events must be audited; and
• when recovery must be refused or escalated.

Avoid collecting a government identity document by default. If a regulated or high-risk product requires identity evidence, define the purpose, access controls, retention, and deletion process with counsel and privacy owners.

Support should never ask for passwords, one-time codes, private keys, or complete recovery codes. A staff member should not be able to set an arbitrary new password and suppress notifications without an independently logged approval.

Secure the state transition after recovery

Successful recovery should do more than change one credential:

1. Mark the recovery credential as consumed.
2. Rotate or revoke relevant sessions and refresh tokens.
3. Invalidate outstanding reset and verification links.
4. Review or remove compromised authenticators.
5. Notify the user through independent channels where possible.
6. Record the method, actor, time, and affected account in the audit trail.
7. Apply a temporary hold to unusually sensitive actions when risk warrants it.

A recovery event can be legitimate and still indicate that a device or mailbox was compromised. Give users a session list and a path to remove unfamiliar access.

Test adversarial scenarios

Test recovery when:

• the attacker controls the email account but not a passkey;
• the phone number has changed owners;
• two reset links are requested concurrently;
• a user clicks an old link after completing recovery;
• support receives convincing but incomplete personal information;
• an organization has only one administrator; and
• a recovered account still has an attacker’s active session.

Account recovery is successful only when the legitimate user regains control and previous unauthorized access is contained.

NamoID centralizes customer authentication and session controls so product teams do not need to treat recovery as an isolated form. Explore NamoID Customer Identity and review the credential-stuffing defense guide for the login-side threat model.