SaaS password reset and account recovery security guide
Design a password reset flow that resists account enumeration and token abuse with generic responses, random single-use links, rate limits, safe notifications and a clear session recovery policy.
In this guide
How should a SaaS password-reset flow work?
A secure password-reset flow lets the account owner prove control of a trusted recovery channel, set a new password and return to the normal sign-in process. Use a high-entropy, short-lived, single-use reset token, store it safely, limit requests and attempts, and give the same public response whether an account exists or not. Protect the link from leakage and decide what happens to existing sessions after a reset.
Use the same public response for known and unknown accounts
A reset request should not reveal whether an email address or username belongs to a customer. Keep response wording and processing behavior reasonably similar, rate-limit abuse, and avoid locking an account merely because someone repeatedly requested a reset. Monitor for enumeration patterns without exposing account existence to the requester.
Make reset tokens random, limited, single-use and safely stored
Generate tokens with a cryptographically secure random source, bind each token to one account and purpose, expire it after a risk-appropriate interval, and invalidate it immediately after successful use or replacement. Store a verifier or hash where practical instead of a reusable raw token. Rate-limit token guesses and prevent a reset token from being used to access unrelated account functions.
Build links from trusted configuration and prevent leakage
Create recovery URLs from a configured canonical HTTPS origin, not an untrusted Host header. Keep tokens out of analytics events, application logs, support tickets and third-party resources. Set a restrictive Referrer-Policy on the reset page, avoid external scripts there where possible, and do not send a user’s new password by email.
| Flow step | Proof of account control | Enumeration or abuse control | Token and session handling | Accessibility and recovery owner |
|---|---|---|---|---|
| Request reset | ||||
| Open reset link or enter code | ||||
| Set password and finish |
How do you protect account recovery beyond the reset link?
Apply the normal password rules and return to normal sign-in
Use the same password storage and account policy as the standard change-password flow. Confirm the new password safely, show a completion message, and ordinarily ask the user to sign in through the usual mechanism rather than automatically creating a fresh authenticated session from the recovery token.
Choose a deliberate session and notification policy
After a successful reset, invalidate the reset token and decide whether to revoke existing sessions, remember-me tokens and refresh tokens. For higher-risk products, automatic revocation may be appropriate; explain the effect to the user and handle devices consistently. Send a notification that the password changed, without including the password or a new sign-in link that bypasses authentication.
Design recovery for MFA, support and accessibility
Password recovery and MFA recovery are related but separate proofs of control. Do not silently bypass a user’s MFA because a password was reset. Provide a documented, accessible route when a person has lost access to a recovery channel, and require support staff to use approved identity verification and audit steps rather than ad hoc security questions or emailed secrets.
How can a team test and monitor account recovery?
Test abuse, expiry and one-time-use behavior
Verify that an expired, guessed, altered, already-used or superseded token fails, and that repeated requests do not create unlimited valid links. Check rate limits by useful dimensions such as account identifier and network signals without letting an attacker cheaply deny service to a victim. Confirm rejected requests do not change the password or session state.
Check for user enumeration and link leakage
Compare responses for registered and unregistered addresses, including status, content and obvious timing differences. Inspect email templates, redirects, referrer headers, analytics, logs and support tooling for the token. Ensure reset URLs use the expected production host even when inbound Host headers or proxy forwarding values are unexpected.
Exercise session revocation and support escalation
After a reset, test old browser sessions, refresh tokens and remembered devices according to the stated policy. Test lost-email or lost-device support paths, audit who performed an override, and ensure staff cannot reveal account passwords or bypass identity checks. Re-test after authentication, email-provider or account-linking changes.
SaaS password-reset questions
Should the reset form say whether an email address has an account?
Usually no. A consistent public response reduces account enumeration. The email or another verified channel can deliver next steps to a legitimate account holder.
Should a password-reset token work more than once?
No. A token should be limited to its purpose, expire, and become invalid after use or replacement. This reduces the chance that an exposed link can be replayed later.
Should users be signed in automatically after a reset?
OWASP recommends returning users to the normal login flow because automatically establishing a session adds complexity and risk. Revoke or retain existing sessions according to a documented risk policy.
Does resetting a password recover a lost MFA factor?
Not by itself. MFA recovery needs its own documented verification process and should not be silently bypassed by the password-reset flow.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Forgot Password Cheat SheetOWASP Foundation
- OWASP Session Management Cheat SheetOWASP Foundation
- NIST SP 800-63B-4: Authentication and Authenticator ManagementNational Institute of Standards and Technology