UX Patterns Guide
UI + UX Task And Workflow Patterns standard

Password reset

Treat password reset as a recovery-token lifecycle: collect an identifier with neutral response, deliver a single-use expiring reset link or code through an enrolled channel, validate the reset session, hand off to secure new-password creation, clean up sessions and tokens, and notify the account after completion.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need to recover an account because the existing password is forgotten, suspected compromised, or unusable.
  • The product can deliver reset artifacts through an enrolled recovery channel and validate them server-side.
  • The product needs safe expired-link, resend, support, session-cleanup, and notification states.

Avoid when

  • The user is merely signing in with a known current password or passkey.
  • The task is only choosing a new password inside an already trusted reset or account setup session.
  • The task is confirming ownership of a new email address during registration or profile editing.
  • The product cannot rate-limit reset requests, generate single-use expiring artifacts, or prevent token leakage.
  • The product uses passwordless recovery and no reusable password will be replaced.

Problem it prevents

Password reset must restore access for legitimate users who cannot authenticate while preventing account enumeration, token theft, replay, weak recovery channels, uncontrolled session continuation, and confusing dead ends.

Pattern anatomy

What a strong implementation has to make clear

User need

The user has forgotten the password, lost access to the authenticator, reached a failed-login route, or received a security prompt to reset a compromised password.

Pattern promise

Treat password reset as a recovery-token lifecycle: collect an identifier with neutral response, deliver a single-use expiring reset link or code through an enrolled channel, validate the reset session, hand off to secure new-password creation, clean up sessions and tokens, and notify the account after completion.

Required state

Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in.

Recovery path

Account enumeration through reset request copy, timing, status codes, resend behavior, or support routes.

Access contract

Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A forgot-password page asks for email, then always shows If an account uses this email, we sent reset instructions, with resend timing and a support route.
  • An expired reset link page explains the link can no longer be used and offers Request a new reset link without revealing whether the account exists.
  • A user enters their email, sees a neutral delivery confirmation, opens a time-limited link, creates a new password, chooses to sign out other sessions, and receives a reset notification.
  • A user opens an old reset link, sees that it expired, requests a fresh link, and continues without needing to re-enter unrelated profile data.
Weak implementation

Vague, hidden, hard to recover from

  • The reset page says No account found for one email and Reset email sent for another.
  • A reset link can be reused after the password changes and signs the user in automatically without a security notice.
  • A user mistypes their email and the form confirms the account does not exist, exposing account registration status.
  • A user changes the password but active stolen sessions remain valid and no account notification is sent.
UI guidance
  • Render password reset as a recovery journey with a neutral request form, reset delivery confirmation, token or code validation, expired and already-used link states, new-password handoff, session cleanup choices, and post-reset notification.
  • Keep password reset separate from login outcome handling and password creation: reset proves recovery-channel control and creates a trusted reset session; password creation handles the new secret inside that session.
UX guidance
  • Use password reset when a user cannot authenticate with the existing password and needs a safe route back into the account without exposing whether the account exists.
  • Help legitimate users recover by making the next step visible, preserving privacy with neutral copy, rate-limiting repeated requests, handling expired links cleanly, and explaining what happens to active sessions after the reset.
Implementation contract

What the implementation must handle

States

  • Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in.
  • Submitted state with account-neutral delivery confirmation, resend timing, channel hint, and support route.
  • Resend-limited state with wait time and no account-existence disclosure.
  • Token or code entry state that validates a reset artifact without exposing it in URLs, logs, analytics, or referrers.

Interaction

  • Submitting an identifier always leads to the same visible confirmation, regardless of whether an account exists.
  • The request form prevents duplicate submissions while pending but keeps status, resend, support, and sign-in routes understandable.
  • Resend and code-entry attempts use server-backed wait times and attempt limits rather than client-only counters.
  • Opening a reset link validates token freshness, account binding, request binding, and single-use status before showing the new-password form.

Accessibility

  • Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier.
  • Announce request submitted, resend wait, expired link, already-used link, and success states with text that does not expose account existence.
  • Keep resend, change identifier, request new link, support, and return-to-sign-in controls reachable by keyboard.
  • Do not make timed expiry or resend wait the only signal; provide persistent text and safe actions.

Review

  • Does any request, delivery, resend, support, timing, error, status code, redirect, or notification path reveal account existence?
  • How are token entropy, expiry, single-use behavior, account binding, request binding, and revocation verified?
  • What happens when the user mistypes the identifier, cannot access the recovery channel, opens an expired link, or reuses an old link?
  • Which active sessions, remembered devices, API tokens, app passwords, and recovery tokens survive a reset, and is that visible to the user?
Interactive lab

Inspect the states before you copy the pattern

Recover an account through a safe reset flow

Request a reset with neutral confirmation, inspect resend timing, expired and used-link recovery, enter a reset code, hand off to new-password setup, choose session cleanup, and compare account reveal, reusable token, no expiry, auto sign-in, emailed password, and dead-link failures.

Password reset
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in.

Keyboard / Access

Enter submits the reset request once and moves to the neutral confirmation state.

Avoid Generating

Confirming whether an email, username, phone number, or account exists.
Evidence trail

Source-backed claims behind this guidance

OWASP Forgot Password Cheat Sheet

OWASP Cheat Sheet Series - checked

OWASP supports neutral reset responses, delivery by email or other side channel, single-use expiring tokens, rate limiting, no automatic login, optional session invalidation, and notifications.

MDN HTML autocomplete password tokens

MDN Web Docs - checked

MDN supports autocomplete new-password semantics for the replacement password step and one-time-code semantics for short reset codes.

NIST SP 800-63B Passwords

National Institute of Standards and Technology - checked

NIST supports blocklist checks, password-manager and paste support, protected channels, hashing, and avoiding unsupported password rules during new-password setup.

Full agent/debug reference

Problem Context

  • The user has forgotten the password, lost access to the authenticator, reached a failed-login route, or received a security prompt to reset a compromised password.
  • The product may know an email, username, phone number, recovery email, administrator channel, or identity-proofing route, but the UI must avoid confirming account existence to unauthenticated users.
  • Reset delivery can fail because the identifier is mistyped, the user no longer controls the mailbox, messages are delayed, codes expire, links are already used, or rate limits are active.
  • Reset links and codes are authentication artifacts that must be protected from replay, guessing, logs, referrers, screenshots, analytics, and cross-account use.
  • After reset, active sessions, remembered devices, app passwords, API tokens, and security notifications may need explicit policy treatment.

Selection Rules

  • Choose password reset when an unauthenticated or partially authenticated user needs to regain account access by proving control of a recovery channel and setting a replacement password.
  • Use login when the user is submitting a current password or authenticator and the issue is the result of that verification attempt.
  • Use password creation for the new-password field and policy feedback after a reset link or code has already established a trusted reset session.
  • Use sign in for the entry page that offers password, passkey, SSO, magic-link, account creation, and forgot-password routes.
  • Use email address entry when collecting or editing a contact address; password reset must keep request confirmation neutral and should not reveal whether the address has an account.
  • Return the same visible request confirmation for known, unknown, locked, disabled, and unverified accounts unless the user is already in a safer authenticated support route.
  • Use server-side rate limiting, abuse monitoring, and consistent response timing for reset requests, resend actions, code attempts, and token validation.
  • Make reset links and codes single-use, time-limited, sufficiently random, account-bound, request-bound, and invalid after password change or successful use.
  • Handle expired, already-used, malformed, and mismatched reset artifacts as recoverable states with a request-new-link route rather than a dead end.
  • After successful reset, clear reset artifacts, send a notification, and apply the product policy for revoking other sessions, remembered devices, app passwords, and recovery tokens.

Required States

  • Request state with identifier input, neutral copy, rate-limit protection, and a route back to sign in.
  • Submitted state with account-neutral delivery confirmation, resend timing, channel hint, and support route.
  • Resend-limited state with wait time and no account-existence disclosure.
  • Token or code entry state that validates a reset artifact without exposing it in URLs, logs, analytics, or referrers.
  • Expired link or code state with request-new-link action.
  • Already-used or revoked link state with request-new-link action and security explanation.
  • Trusted reset-session state that hands off to password creation with new-password autocomplete and no old-password requirement.
  • Password-reset success state that explains sign-in, session revocation, and account notification outcomes.
  • Suspicious or support-required recovery state for high-risk accounts, inaccessible channels, or repeated abuse.
  • Post-reset notification state sent through the account's registered contact route.

Interaction Contract

  • Submitting an identifier always leads to the same visible confirmation, regardless of whether an account exists.
  • The request form prevents duplicate submissions while pending but keeps status, resend, support, and sign-in routes understandable.
  • Resend and code-entry attempts use server-backed wait times and attempt limits rather than client-only counters.
  • Opening a reset link validates token freshness, account binding, request binding, and single-use status before showing the new-password form.
  • Expired, already-used, revoked, or malformed artifacts never show raw token values and always offer a safe way to restart recovery.
  • The new-password step inherits password creation rules, then clears reset artifacts and follows the session-revocation policy.
  • Post-reset notification and audit records avoid exposing the new password, token, exact failure reason, or account-enumeration signals.

Implementation Checklist

  • Define eligible identifiers, enrolled recovery channels, delivery copy, token entropy, expiry window, single-use behavior, account binding, request binding, resend limits, code-attempt limits, and abuse-monitoring events with security owners.
  • Design neutral request confirmation, delayed delivery expectations, spam-folder advice, resend timing, wrong-email correction, support route, and return-to-sign-in route without exposing account existence.
  • Protect reset links and codes from leakage through logs, analytics, referrer headers, screenshots, browser history, support transcripts, URL previews, and third-party scripts.
  • Map expired, already-used, revoked, malformed, mismatched, too-many-requests, inaccessible-channel, and high-risk-account states to visible recovery actions.
  • Use the password creation pattern for new-password acceptance, blocklists, paste, show and hide, autocomplete new-password, and no emailed passwords.
  • After success, invalidate reset artifacts, notify the account, apply session and device revocation policy, clear stale failure states, and route users to sign in or a verified session according to policy.

Common Generated-UI Mistakes

  • Confirming whether an email, username, phone number, or account exists.
  • Using password reset questions, reminders, or emailed passwords as recovery.
  • Allowing reset tokens to be reused, guessed, shared across accounts, or used after expiry.
  • Displaying raw tokens or codes in logs, analytics, support tools, screenshots, or third-party referrers.
  • Dropping expired or already-used links on a blank error page.
  • Automatically signing the user in after reset when policy requires fresh login or session review.
  • Leaving stolen sessions, remembered devices, app passwords, or API tokens active after a high-risk reset.

Critique Questions

  • Does any request, delivery, resend, support, timing, error, status code, redirect, or notification path reveal account existence?
  • How are token entropy, expiry, single-use behavior, account binding, request binding, and revocation verified?
  • What happens when the user mistypes the identifier, cannot access the recovery channel, opens an expired link, or reuses an old link?
  • Which active sessions, remembered devices, API tokens, app passwords, and recovery tokens survive a reset, and is that visible to the user?
  • Where could the reset token, code, new password, or exact recovery failure reason leak?
Accessibility
  • Use a clear page heading such as Reset your password and avoid relying on placeholder text for the account identifier.
  • Announce request submitted, resend wait, expired link, already-used link, and success states with text that does not expose account existence.
  • Keep resend, change identifier, request new link, support, and return-to-sign-in controls reachable by keyboard.
  • Do not make timed expiry or resend wait the only signal; provide persistent text and safe actions.
  • Ensure reset codes are easy to copy, paste, and enter with native inputs and clear grouping when used.
  • Focus expired or used link pages on the recovery heading or first safe restart action.
Keyboard Behavior
  • Enter submits the reset request once and moves to the neutral confirmation state.
  • After delivery confirmation, Tab reaches resend timing, change identifier, support, and return-to-sign-in routes in a predictable order.
  • Reset code entry supports paste, deletion, selection, and correction without splitting focus into inaccessible traps.
  • Expired or already-used links move focus to the page heading or request-new-link action.
  • The new-password step follows password creation keyboard behavior and never requires retyping the old password.
  • Success moves focus to the sign-in, continue, or session-review action required by policy.
Variants
  • Email reset link
  • Short reset code
  • Recovery email reset
  • Phone recovery reset
  • Administrator-assisted reset
  • Expired reset link
  • Already-used reset link
  • High-risk account reset
  • Forced reset after compromise
  • Session revocation after reset

Verification

Last verified: