The password reset flow is one of the most overlooked security surfaces in account protection. Users invest significant effort in creating strong passwords and enabling two-factor authentication, only to leave an insecure recovery mechanism that attackers can exploit to bypass both. A secure password reset process must be at least as strong as the primary authentication it can replace — because by definition, the reset flow provides access to anyone who successfully completes it, regardless of whether they know the original password. For a broader walkthrough, our Complete Guide to Online Security and Privacy is a good next read.
This matters for two audiences: developers and product owners who build login systems (who control what the reset flow actually does), and end users who configure and use reset options (who can strengthen or weaken the recovery path within the options the service provides).
Why default reset flows are often insecure
The most common mechanism — a reset link emailed to the user — has a security ceiling determined by the security of the email account itself. If the email account can be accessed by an attacker (through credential stuffing, phishing, or the email account’s own weak recovery options), the attacker can trigger a reset on any account using that email address for recovery, receive the reset link, and complete the reset without ever knowing the original password. The “forgot your password” flow has effectively become a second password — and often a weaker one.
Security questions are weaker still. Questions like “What was the name of your first pet?” draw answers from information that may be publicly available (social media, data broker profiles, family members), guessable from context, or consistent across multiple services. An attacker who finds these answers can reset the account without touching the email. This was the mechanism used in the 2014 iCloud celebrity photo breach: security questions were answered using publicly available information about the targets. Security questions are now deprecated by security professionals — any service that still relies on them for primary recovery is using a known-weak mechanism.
SMS-based password reset — sending a one-time code via text message — is stronger than security questions but vulnerable to SIM swap attacks, where an attacker convinces a mobile carrier to transfer the target’s phone number to an attacker-controlled SIM. Once transferred, the attacker receives all SMS messages including reset codes. SIM swaps specifically target SMS recovery as the weakest link in accounts that have otherwise strong primary authentication.
Recovery strength hierarchy — from strongest to weakest
- Backup codes stored in the password manager — single-use codes generated at 2FA setup; the strongest individual-controlled recovery mechanism
- Authenticator app backup method — can be reconfigured on a new device through the app’s backup; stronger than SMS because no carrier involvement
- Hardware security key backup — enrolled backup key stored at a separate location
- Recovery email address — strength is entirely dependent on the security of the recovery email account itself
- Recovery phone number (SMS) — vulnerable to SIM swap; avoid for high-value accounts
- Security questions — deprecated; use random nonsense answers stored in the password manager if the service requires them
Best practices for users — securing the recovery chain
The most important password reset configuration step: securing the recovery email address. If an account uses email-based password reset, the recovery email account must be as secure as — or more secure than — the account being protected. A Gmail recovery address with a strong unique password and authenticator app 2FA provides a much stronger reset chain than one with a weak password or SMS-only 2FA.
Consider using a dedicated recovery email address rather than the everyday account — so that phishing attacks targeting the everyday email don’t automatically provide a path to password reset links for all other accounts. Our guide on securing your email covers the complete email account hardening that a recovery address requires.
Practical steps for users:
- Secure the recovery email first. Unique strong password + authenticator 2FA. This one action strengthens the reset chain for every account that uses it as recovery.
- Replace security questions with nonsense answers. Where the service still uses security questions, store random generated answers in the password manager. “Mother’s maiden name: xT9#qQ2mWk”. The service doesn’t verify accuracy — only consistency.
- Save backup codes at the time of 2FA setup. Password manager secure notes alongside the account credentials. A 2FA-enabled account with no saved backup codes has no safe recovery path if the authentication device is lost.
- Upgrade SMS recovery to authenticator app where possible. Most major services allow switching from SMS to authenticator app in the security settings. Do this for email and financial accounts as a priority.
- Annual review of recovery options. A recovery phone number for a mobile number no longer active, a recovery email for a lapsed account, or social-media-discoverable security question answers all accumulate through inattention. Set a calendar reminder for annual review of critical account recovery options and test each one to verify it actually works.
Developer and product best practices — building it right
Time-limited single-use tokens: every password reset link or code should be valid for a short window (15–60 minutes maximum) and invalidated immediately upon use. A reset link that remains valid indefinitely creates a persistent access path if the link is intercepted later. Store only a hashed version of the reset token in the database — the cleartext token in the link, the hash in storage — so a database breach doesn’t expose active reset tokens.
Avoid user enumeration: responding differently to “email exists” versus “email not found” during reset requests reveals which email addresses have accounts — information attackers use for targeted attacks. Return the same response regardless: “If an account exists for that email address, you will receive a reset link.” Consistent response prevents user enumeration through the reset flow.
Rate limiting and suspicious activity detection: reset flows without rate limiting allow automated attacks requesting tokens for thousands of accounts in minutes. Rate limit reset requests per account (3–5 per hour maximum), per IP address, and alert account owners when a reset is requested from an unusual location or outside normal usage patterns.
Invalidate all active sessions when a password is reset. A password reset should terminate all active sessions, not just future logins. An attacker who triggered a reset to compromise an account while the legitimate user is logged in — a less common but real attack scenario — retains their access if sessions are not invalidated on reset completion.
Notify the account holder immediately via all available channels when a password reset is requested and when it is completed — email notification, push notification, or both. If the legitimate user didn’t initiate the reset, this notification is the only warning they receive before their account is compromised.
Offer passkey enrollment after successful reset. A password reset is the moment when the user has confirmed their identity through the recovery chain — the ideal moment to offer passkey enrollment, which will prevent future password-based account compromise entirely. Prompt the user to set up a passkey at the end of the successful reset flow.
The account recovery hierarchy — for services supporting multiple methods
| Method | Resistance to attacks | User friction | Implementation complexity |
| Backup codes + identity verification | High — codes are unique, not network-transmitted | Low (if codes are stored in password manager) | Low |
| Authenticator app TOTP recovery | High — requires physical access to enrolled device | Low | Low |
| Hardware security key | Very high — phishing-resistant, domain-bound | Low (physical tap) | Medium |
| Trusted contact verification | High — requires cooperation from trusted person | Medium — requires coordinating with a contact | Medium |
| Email recovery link | Medium — depends on email account security | Low | Low |
| SMS OTP | Low-medium — SIM swap vulnerable | Low | Low |
| Security questions | Low — often publicly answerable | Low | Low |
| Support ticket + ID verification | Variable — depends on support agent thoroughness | High — slow, requires documentation | High (process-intensive) |
Shared business accounts — the recovery ownership problem
Shared business accounts — where multiple employees access the same service account — face a specific recovery risk. A shared account whose recovery email is a personal address belonging to one team member creates a single-person dependency: if that team member leaves, the recovery path leaves with them.
For shared business accounts:
- Use a team-accessible recovery email (a group address administered through the company’s email system, not an individual’s personal account)
- Store backup codes in the team password manager where multiple administrators have access
- Document recovery procedures in the internal knowledge base so any authorised team member can execute them
Our guide on password manager for teams covers the credential management structure that includes recovery access as part of complete team account security. A shared account whose recovery mechanisms are controlled by a single person is a single point of failure that a departure, illness, or adversarial exit can transform into an access crisis — preventable with 15 minutes of configuration.
Support-based account recovery — the social engineering risk
When all other recovery mechanisms have failed, the fallback is usually contacting the service’s support team. This is the recovery path most susceptible to social engineering — a support agent who can be convinced that a caller is the legitimate account holder, despite not knowing the original password, represents a reset path that bypasses all technical controls.
Examples of this attack in practice: the 2014 iCloud celebrity photo breach (security questions answered using public information), and numerous high-profile Twitter/X account compromises through support social engineering. Attackers research their targets — full name, registered email address, billing address if known, account creation date, recent activity — and use this information to pass identity verification with support agents.
For individual users, reducing the information available for this attack means applying data minimisation principles broadly: limiting publicly available personal information, using email aliases rather than the primary address for account registrations, and being aware that the information required to “prove” account ownership to a support agent is often the same information that data brokers sell. If this sounds familiar, Secure Your Email is worth a look.
For service developers: support-based account recovery should require documentation that is difficult to social-engineer, take time (to allow the legitimate account holder to notice the request), and trigger notifications to the account holder at every stage of the process. Some services now require video identity verification for support-based recovery of high-value accounts — this is a proportionate response to the social engineering risk at the highest-stakes accounts. Our guide on Secure Your Smart Home covers an adjacent issue.
Annual account recovery audit — what to check
A 15-minute annual review of recovery options on critical accounts:
- Primary email account: log into the email account → Security settings → review recovery email and recovery phone number → confirm both are current and accessible → verify 2FA method is authenticator app not SMS → confirm backup codes are saved in password manager
- Password manager master account: confirm emergency access is configured (Bitwarden Emergency Access; 1Password Emergency Kit) → confirm the master password is memorised and that a backup copy exists in a physically secure location
- Financial accounts (bank, investment, payment): log in → Security or Account settings → review recovery options → confirm none are SMS-only → confirm backup codes saved if 2FA active
- Any account where the recovery phone number or email has changed since last review: update immediately, as the old contact may now belong to someone else or be inactive
The stress of being locked out of a critical account — particularly a primary email or a financial account during a time-sensitive transaction — creates pressure to accept whatever recovery mechanism the service offers or to provide whatever verification a support agent requests. Building and maintaining a robust recovery structure in advance, while there is no urgency, is the preparation that prevents both the lockout and the security compromises that lockout pressure leads to. See also Online Account Security for a related case.
