Secure Account Recovery Design

What it is

Every account has two ways in: login and recovery. As login gets harder with MFA and passkeys, attackers move to recovery, so an account's effective assurance level is that of its weakest recovery flow. If "forgot password" plus an email link plus "can't access my phone" leads to a fresh session that can change the bank account, MFA added almost no protection.

Recovery covers several distinct paths:

• Self-service password reset (email or SMS link or code)
• Lost-factor or lost-device recovery (rebinding MFA or a passkey)
• Support-assisted recovery (phone, chat or email agent)
• Identity re-proofing (document plus selfie, knowledge checks, trusted referee)
• Contact-point change as a disguised form of recovery ("I changed my number, please update it")

What it stops (and what it doesn't)

Design considerations

1. Recovery assurance should be at least equal to the authenticator being replaced. Recovering a passkey-protected account through an SMS code downgrades it. The FIDO Alliance recommends that when no other bound authenticator exists, the service re-run identity proofing at the same or a higher assurance level than the original. NIST SP 800-63B-4 requires its account-recovery procedures to be followed whenever a subscriber can't authenticate at the required level. It also recommends customers keep at least two separate authenticators, which reduces how often recovery is needed at all.

2. Separate getting back in from moving money. A recovered session should be restricted for a period:

• No payout-destination changes or new payees for a set time
• Lower withdrawal limits (Velocity and Exposure Limits)
• A step-up on the first payout, using a factor bound after recovery plus an independent check
• No outbound ACATS, crypto sends or gift-card cash-out during the window

Of all the recovery design decisions, this restriction window does the most to cut losses. See Contact Change Cooling-Off Periods.

Record every recovery as an account change event, so downstream models and monitoring can see that recovery happened.

3. Notify every channel on file. Before and after recovery, alert the old email, the old phone and existing app sessions, with a one-tap "this wasn't me" that freezes payouts. Notifications that go only to the new contact point are worthless.

4. Score the recovery attempt. Use Device Reputation and Linkage (is this a device previously seen on the account?), Phone Risk Signals (recent SIM change or port), Email Risk Signals (recent inbox changes, newly created forwarding domains), Login Anomalies, and Customer Contact Signals (recent calls from other numbers). A recovery request from a known device with a long account history is a different event from one on a new device minutes after a carrier port.

5. Harden the support channel. Support agents are both a recovery path and a target:

• A verification script with non-discoverable factors, such as in-app push to an existing device or callback to the number on file
• No agent override of MFA or cooling-off
• Dual control for high-value accounts
• Monitoring of agent recovery patterns for Insider Fraud

See Customer Support Verification Protocols and Support Team Fraud Training.

6. Plan for deepfakes. Voice and video verification can no longer be treated as strong evidence by itself. NIST SP 800-63A-4 adds explicit controls against injection attacks and forged media in remote proofing (see Document Verification and Liveness and Generative AI and Deepfake Fraud).

Industry lens.

• Brokerage: recovery followed by bank-link change and full liquidation is the classic ATO path. Restrict outbound ACATS and withdrawals for days after recovery.
• Cashback / rewards: recovery is often email-only. Hold the first cash-out to a new destination.
• Neobanks: lost-phone recovery is constant, so rely on device history and re-proofing selfies against the onboarding image.
• Marketplaces: seller-account recovery followed by a payout-account change should trigger a payout hold.

Implementation path

Customer friction and trade-offs

• People locked out of their own money are angry and call support, which increases social-engineering exposure. Aim for recovery that is reliable for legitimate customers and restricted afterward. A hard recovery flow with no post-recovery restrictions frustrates customers and still lets attackers cash out.
• Post-recovery payout holds frustrate customers who recovered because they need money urgently. Be clear about how long the hold lasts and offer an expedited, higher-assurance path such as a video-verified review.
• Re-proofing excludes customers without current IDs or compatible devices. Keep an attended alternative.

Measuring effectiveness

• Recovery-originated ATO rate: the share of confirmed ATO where the attacker's first session came from recovery. Expect it to rise as login hardens, and aim to keep it falling in absolute terms.
• Recovery-to-payout interval distributions, comparing genuine and confirmed-ATO cases.
• "This wasn't me" response rate on recovery notifications, and the median time to that response.
• Support-assisted recovery fraud rate, by agent, team and vendor site (this also tests for insiders).
• Recovery completion rate and time for genuine customers (the friction cost).

Common failure modes

• Downgrade path: recovery can reset MFA through a weaker factor.
• Unrestricted recovered sessions: payouts to new destinations are possible right away.
• Misdirected notifications: alerts go only to the newly added contact point.
• Support overrides: agents can bypass controls "for good customers".
• Contact change as recovery: contact-point changes aren't treated as recovery and skip all controls.
• Recovery codes that are reusable or never trigger alerts.

Regulatory and policy notes

• NIST SP 800-63B-4:
  • Requires its recovery procedures when a subscriber can't authenticate at the required AAL.
  • Requires a way to invalidate a lost or stolen authenticator immediately.
  • Recommends maintaining two or more authenticators.
  • Requires that a phone-number change be treated as binding a new authenticator.
• NIST SP 800-63A-4 adds fraud-management requirements and controls for injection and forged media in remote re-proofing.
• FTC Red Flags Rule (16 CFR Part 681). Section 681.1 requires financial institutions and creditors with covered accounts to run a written identity theft prevention program. Section 681.2 adds a card-issuer duty: when a request for an additional or replacement card arrives during at least the first 30 days after an address-change notice, the issuer must assess the change's validity before issuing the card. It can do that by notifying the cardholder at the former address (or by another agreed means) with a way to report an incorrect change, or by other reasonable program procedures. Validation may also be done when the address change itself arrives. Notices must be clear and conspicuous and sent separately from regular correspondence. Many institutions apply the same logic to other contact changes followed by payout requests.
• Broker-dealers: Reg S-ID red-flags program; see Broker-Dealer Obligations (FINRA and SEC).

Mechanisms addressed

• Account Recovery Abuse
• SIM Swap and Port-Out Fraud
• Account Takeover (ATO) and Payout Redirection
• Impersonation Scams that target support
• Insider Fraud at the support desk
• Generative AI and Deepfake Fraud in voice and video verification

Related controls

• Contact Change Cooling-Off Periods
• Customer Support Verification Protocols
• Multi-Factor Authentication (MFA)
• Passkeys and Phishing-Resistant Authentication
• Document Verification and Liveness
• Withdrawal and Payout Controls
• Insider Access Controls
• Playbooks: Playbook - Account Recovery Hardening Members, Playbook - SIM Swap and Contact Change Abuse Members

Sources and further reading

• NIST SP 800-63B-4: recovery requirement when AAL can't be met; invalidation; two authenticators; phone change counts as binding.
• NIST SP 800-63A-4: fraud management, SIM-swap and device-tenure checks, injection-attack and forged-media controls.
• FIDO Alliance: Account Recovery Best Practices: multiple authenticators; re-proofing at equal or higher assurance; avoid weaker mechanisms.
• eCFR: 16 CFR Part 681 (Identity Theft Rules): program requirements (681.1); card-issuer change-of-address validation window and methods (681.2).