Account recovery: do's and don'ts
Updated 2026-05-07
Account recovery is the most-attacked surface in CIAM. Login is where most attention goes; recovery is where the bypass lives. The patterns below distill the lessons from production breaches and the audit findings that surface in security reviews.
For broader context, see the account takeover defense guide and the MFA pillar guide.
Do
Enroll at least two recovery factors at signup
Single-factor recovery becomes the bypass: lose the phone, the only path to recovery is email, but if email is the auth, that's auth-by-email-control. Two factors give the user a recovery path that doesn't bypass MFA.
Best practice in NIST SP 800-63-4 and the OWASP Authentication Cheat Sheet. Production deployments at major CIAM platforms enroll at least two recovery factors as the default since 2024.
Require at least one recovery factor to complete recovery
Recovery without verifying any factor is auth bypass. Even weakly-verified factors (alternate email) are stronger than no verification at all, and enrolled-recovery-factors are stronger than ad-hoc anything.
Production breaches in the 2022–2024 window repeatedly traced to recovery flows that quietly skipped MFA after a password reset; the pattern is so common it has its own bypass class in OWASP.
Rate-limit recovery initiation per account and per IP
Recovery flows are an under-defended surface, attackers probe recovery before login because recovery often has weaker rate limits and weaker factor requirements.
Real production attacks have used recovery-flow probes to enumerate accounts, harvest password reset tokens, and ultimately bypass MFA. Rate limits at 5 per hour per account and 50 per hour per IP catch most automation without affecting legitimate users.
Audit-log every recovery event with timestamps and IP
When account compromise happens, the recovery audit trail is the first thing forensics looks at. Production-grade audit logs include the recovery initiation, the factors verified, the factors changed, and the outcome, searchable per-user.
Required by SOC 2 Type II for the auth surface and routinely audited in incident response. Most B2B-mature CIAM ship audit logs scoped per-Organization for the customer's security team to query.
Notify the user out-of-band when recovery completes
Out-of-band notification (email + SMS to the previously-enrolled factors) catches recovery-flow abuse the user didn't initiate. The notification is a chance to block the takeover before damage.
Major B2C CIAM platforms (Auth0, Okta, Apple, Google) send out-of-band notifications on recovery and have published case studies of users blocking takeovers within minutes of receiving the alert.
Don't
Don't allow recovery to bypass MFA
The most common ATO bypass class observed in production: user clicks forgot password, verifies email, sets new password, logs in fully authenticated, bypassing MFA entirely.
Recovery flow audits at multiple production CIAM deployments find this pattern routinely. The fix is structural: recovery requires presenting at least one enrolled recovery factor before completing.
Don't let support reps reset MFA without policy and audit
An unmonitored support-reset path is a bypass attackers will reach for via social engineering. Document the policy, rate-limit the path, audit every event, notify the user out-of-band.
Multiple high-profile ATO incidents in 2023–2024 traced to social-engineered support resets. Major CIAM vendors now publish customer guidance specifying support-reset rate limits and audit requirements.
Don't accept recovery from an unverified email address
Unverified email at recovery becomes 'enter any email and recover.' Production deployments must verify the recovery email matches an enrolled factor for the account.
Several production ATO incidents have traced to recovery flows that allowed users to specify a new email at the recovery step. Modern CIAM rejects this pattern by default.
Don't expose whether an account exists in recovery flows
Account-existence enumeration via recovery (different response for known vs unknown emails) is an information leak attackers exploit to build target lists.
OWASP Top 10 includes user enumeration in API design. Best practice: identical response for valid and invalid recovery requests, with the actual email going only to the verified address.