---
{
  "title": "Secure account recovery",
  "summary": "Examine password-reset links, lost-authenticator recovery, and session handling as alternate routes to controlling an account.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Forgot Password",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html"
    },
    {
      "title": "NIST: Digital Identity Guidelines — Authentication and Authenticator Management",
      "url": "https://pages.nist.gov/800-63-4/sp800-63b.html"
    }
  ],
  "editorialVersion": 2
}
---

## Recovery is another route into the account

Account recovery restores access when someone cannot complete the usual sign-in process. A forgotten password, lost authenticator, or inaccessible recovery channel can trigger different workflows. Each workflow grants something valuable: renewed control of an identity. Its security therefore matters as much as the ordinary login.

A password reset is one kind of recovery, not the entire subject. Replacing an MFA device, changing a recovery email address, and asking a help desk to restore access create related decisions with potentially different assurance requirements. Map these routes separately before assuming one reset screen covers them all.

## Follow a reset link through its lifecycle

Imagine a fictional customer, Imani, requests a password reset. The service sends a recovery link through an established channel. The link carries a token associated with the intended account, and presenting an acceptable token permits a limited reset operation. It should not silently grant unrelated account changes.

A secure design considers unpredictability, expiry, single use, storage, and delivery. Expiry limits how long a stolen token remains useful; single use prevents successful reuse after a legitimate reset. A token that has expired should not become valid merely because the user restarts a browser.

Imani might request a second link before using the first. The service needs a documented policy for that situation so the team can explain which links remain valid. Ambiguous behavior becomes difficult to diagnose when a user and an attacker are both interacting with the workflow.

## Avoid turning recovery into an account directory

A public reset page can reveal whether a particular address has an account if its messages or behavior differ. Consistent responses and appropriate request limits help reduce unnecessary disclosure and abuse. [[rate-limiting]] explains the broader control.

However, a generic message alone does not prove the entire workflow behaves consistently. A review may need to consider timing, repeated requests, delivery behavior, and what information is exposed at later steps. The goal is a useful recovery route without giving a stranger unnecessary information or disruptive power.

## What happens to existing access?

Suppose Imani is recovering after suspected account misuse rather than a simple forgotten password. The response may need to address active sessions and registered authenticators, depending on the evidence and the service's policy. [[sessions-and-cookies]] explains why a session can continue independently of the original password check.

A recovery workflow should tell users what changed and how to report an unexpected reset. The organization also needs a process for exceptional cases where the ordinary recovery channel is unavailable. Public biographical knowledge is weak evidence for granting control of an important account.

## Review with two fictional users

In an application you own or a designated training environment, check that a token for one test account cannot reset another account, that a used token cannot be reused, and that expiry is enforced. Record the expected and observed outcomes without using real customer credentials.

Then draw the lost-authenticator route beside the password-reset route. Ask who can authorize each transition and what evidence they rely on. This exercise connects recovery to [[authentication]] and [[multifactor-authentication]] while exposing a common design mistake: strengthening the front door and overlooking an easier alternate entrance.