Identify which access has been lost
A forgotten password, a lost second factor and a mailbox controlled by someone else are different incidents. A customer who can still sign in with another authenticator may be able to bind a replacement through the normal authenticated session. Someone who has lost every usable authenticator needs a recovery route. NIST makes this distinction explicit. Start a design workshop with actual account types and likely failures: a consumer who replaced a phone, an office administrator who left, and a customer whose email address was changed without permission. Each case needs a different proof and escalation path.
Do not let the support script collapse every case into “send a reset email”. A password reset sent to the same compromised inbox can hand the account to an attacker; a second-factor reset that asks only for a password removes the protection the second factor was meant to provide. Write down which credentials the claimant still controls, which contact channels were previously verified, and whether the account can move money, disclose records or change other users. The more consequential the account, the stronger the evidence and review should be before access changes.
Recovery is a business process as much as an interface. Decide who may approve a high-risk request, what support may see, how long a case may wait, and what happens if the customer cannot meet the standard proof. The answer cannot be “support can make an exception whenever the caller sounds convincing”. A documented exception can involve additional review, a delay or a restricted account state. Tell users in advance which recovery options to set up, so they are not discovering the requirements at the moment they are locked out.
Give users recovery options in advance
NIST describes saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing as recovery method classes for the systems it governs. An SME can use that framework to ask which options suit its own customers, without claiming every NIST assurance rule automatically applies to a private Hong Kong service. A saved code can help a customer who loses a phone but kept the code securely. A preverified alternate contact can help when the primary inbox fails. Neither option helps if the service never offered it before the incident.
At registration and in account settings, explain how to add a second usable authenticator or a recovery option, and let customers confirm they have stored a code safely. A recovery code is a secret, not a general support reference. Do not print it in routine emails, place it in analytics events or let agents read it back from a support screen. NIST describes saved codes as securely delivered, stored as one-way hashes by the service, invalidated after use and replaced. Those details give a supplier concrete implementation questions even when its product uses a different recovery method.
Treat contact-channel changes as security events. If an attacker can change the recovery email and immediately recover the account, the safeguard has moved rather than held. Require appropriate authentication for adding or replacing a recovery channel and notify an existing channel when a change occurs. For sensitive accounts, consider a delay or manual review before a newly added channel can be used for a major recovery. The exact delay is a product risk decision, not a universal number from these sources. Make the rule visible to customers so a legitimate change does not look like a mysterious lockout.
Make the reset path measurable
OWASP advises that a password reset request should return a consistent message whether or not the account exists, so a stranger cannot easily use the form to discover customer addresses. Responses should avoid meaningful timing differences as far as practical, and the request path needs rate limiting against abuse. The reset token should be random, long enough, single-use, securely stored and expire after an appropriate period. Send it over the expected channel and build the reset URL from a trusted configured origin, not from an attacker-controlled request header. These are engineering acceptance points, not user-facing claims of perfect security.
After a valid reset, tell the account holder that a change occurred. OWASP says not to change the account before a valid token is presented and recommends considering whether existing sessions should be invalidated after the password changes. For a service with sensitive records, the owner should decide explicitly whether to revoke other sessions, ask the user to sign in again and alert support to unusual activity. A customer should not be auto-logged in by a reset link if that weakens the intended sign-in checks. Record the event without putting tokens or new secrets into logs.
A lost second factor needs its own route. NIST describes account recovery as different from replacing a forgotten password while another authenticator remains. Map which evidence combination is acceptable for your account class and whether a human review is necessary. Avoid knowledge-based questions such as a birthplace or public business detail as the sole proof; answers can be guessed, researched or shared. Support agents need a script that says when to stop and escalate. A recovery route that is effortless for a genuine user and equally effortless for an impostor has not solved the design problem.
Test the claims support will actually hear
Take a hypothetical supplier portal with two administrators. One administrator loses a phone but still has an active second authenticator. The ordinary signed-in route can let that person add a replacement after the required checks. A second administrator loses both the phone and the saved code, while the registered mailbox remains available. That is a separate recovery case: the system should apply its documented evidence requirements, notify the account holder and record who approved a new factor. The two stories should not be treated as identical merely because both callers say “my phone is gone”.
Now add a hostile variant: a caller knows the company name, invoice amount and employee names but controls none of the registered authenticators or verified channels. Those business details may be known to a contractor or obtained from a leaked message. The support agent should not treat them as enough to remove a factor. The case may require a higher-trust route or remain unresolved until the organisation can verify ownership. This can be inconvenient, so publish the options and expected process in advance rather than promising instant recovery to everyone.
Test the customer experience too. A genuine user needs to know which step is pending, how to contact the service through an independently found channel, and what to do if a recovery notification was unexpected. The test should include a link that has already been used, an expired link, several requests in succession and a request for an unknown account. Check the browser response, emails, support queue and audit record together. A successful unit test of token generation does not show whether a confused person can safely complete the whole recovery journey.
Decide the policy before an emergency
The owner can approve a one-page recovery matrix: account class, remaining authenticator, available preverified channel, required proof, reviewer, notification and resulting account restrictions. Ask the supplier to demonstrate the reset and lost-factor flows using test accounts, including a simulated compromised inbox. Do not accept a description that says “support will verify identity” without specifying what evidence they may rely on and what they must never accept. The strongest design is one support can execute consistently at a busy moment, with a clear route when evidence is insufficient.
Keep the policy current when the product adds passkeys, business accounts or more consequential actions. A method adequate for a newsletter account may be unsuitable for an account that changes payment instructions. Review recovery requests and near misses as evidence of friction or abuse, without claiming that either count proves the design safe. If customers routinely cannot complete a legitimate route, improve pre-enrolment and support communication while preserving the proof boundary. Recovery is complete only when the right person regains appropriate access and the wrong person has not been given a shortcut.
The next practical step is a rehearsal with three test identities: one that knows the password but lost a second factor, one that lost every factor but has a prearranged recovery method, and one that has no trustworthy proof. Have a business owner, support lead and developer observe the same run. Record the decision, notification, time taken and account state for each path. Where the path depends on an informal favour or an agent reading a secret aloud, fix the design before a real customer is stranded or an impostor is served.
Before you proceed
- Are lost-password and lost-factor routes distinct?
- Can support identify insufficient proof and escalate?
- Does every recovery notify the account holder?
