Research guide

Password Reset Test Cases: 25+ Scenarios With Examples

Testing a password reset flow is not one test; it is several surfaces with different risk profiles. Treat the reset journey as four surfaces: the request form where a customer enters an email, the emailed link and its token, the new-password form, and the account state after a successful reset, with a security and abuse layer across all of them. Most teams test only the happy path and stop. This checklist gives copyable cases for every surface, including the ones that become security incidents, and answers which parts a browser E2E tool can verify versus which need real mailbox or API access. Our automate password reset testing tutorial and the coded versus agentic password reset discussion cover the how.

By CueTest QA Team · Published 2026-08-09 · Updated 2026-09-02

Testing a password reset flow is not one test; it is several surfaces with different risk profiles. Treat the reset journey as four surfaces: the request form where a customer enters an email, the emailed link and its token, the new-password form, and the account state after a successful reset, with a security and abuse layer across all of them. Most teams test only the happy path and stop. This checklist gives copyable cases for every surface, including the ones that become security incidents, and answers which parts a browser E2E tool can verify versus which need real mailbox or API access. Our automate password reset testing tutorial and the coded versus agentic password reset discussion cover the how.

Read the reset journey as four surfaces

To a customer, a password reset is one flow; to an engineer it is four systems. The request form takes an email and must not leak which addresses have accounts. The emailed link carries a single-use, time-limited token bound to one account. The reset form must enforce the same password policy as signup and fail cleanly. The post-reset account state, old password dead, sessions handled per policy, MFA still applied, is where most "it worked in staging" surprises live. OWASP separates the request and reset stages for exactly this reason, and its Forgot Password Cheat Sheet is a useful reference throughout.

This flow deserves a permanent checklist because it is easy to skip: releases touch auth pages, email templates, shared forms, or the session library and nobody re-runs recovery. Our workflow story on the password reset regression shows how quietly that gap becomes an outage.

Request-form test cases

The request form is where a customer says "I cannot get in." Its core job is to start recovery without telling an attacker whether an email has an account.

• Valid registered email. Submit a known test account email and verify a confirmation screen appears with clear next steps ("We emailed you a link"). The submission must not be a silent POST with no visible state change.
• Unknown email, same response. Submit an address with no account and verify the confirmation message matches the registered-email case exactly, in text, tone, and timing, so the product does not enumerate which addresses have accounts.
• Malformed email. Submit values like user@, @domain.com, or user@@domain.com and verify a clear validation error without a server call.
• Empty field. Submit with the field blank and verify an inline validation error and that focus moves to the field.
• Whitespace and case normalization. Submit user@example.com (leading and trailing spaces) and USER@Example.COM and verify the account is found; confirm whether the product trims and lowercases before lookup.
• Double-submit and duplicate requests. Submit twice quickly and verify the second request is handled per policy, a cooldown message, a deduplicated email, or a disabled button, rather than a double send or an error state.
• Re-request throttling and cooldown. Attempt repeated submissions within a short window and verify rate limiting applies per account, with a clear message and a countdown or "try again later" state. This is both a UX and a security case.
• Email delivery latency display. Confirm the confirmation screen tells the customer to allow a few minutes and check spam, and that nothing implies the email was sent instantly if delivery is asynchronous.
• Disabled or cooldown state on the button. After a successful request, verify the submit button shows a disabled or cooldown state and cannot be spammed to generate mail.
• Email service failure. Simulate a disabled or failing email provider and verify the product surfaces a clear error state instead of silently hanging or claiming success.
• Cancel and return paths. Back, cancel, or "return to sign in" must exit the flow and land on the sign-in page without submitting.

Reset-link and token test cases

The token is the security boundary of the whole flow. These cases exist because a token bug is not a cosmetic issue; it is a session and account takeover vector. For sign-in and session basics that this layer depends on, the login E2E test cases guide is the companion reference.

• Valid link opens the reset form. Click the link from the mailbox and verify it opens the reset form for the correct account and does not require a second lookup.
• Single-use token. Complete a reset with the link, then click the same link again and verify it is rejected with a clear message and a path to request a new one.
• Token expiry window. Use a token near the end of its validity (for example a 30 to 60 minute window per your policy) and one past it, and verify expired tokens are rejected with a "link expired, request a new one" state.
• Tampered or invalid token. Modify the token, the account ID in the URL, or both, and verify rejection without leaking whether an account exists or whether the token was close to valid.
• Token bound to the wrong account. Request a reset for account A, then open that link while signed in as account B (or after swapping the account identifier) and verify the mismatch is rejected cleanly.
• Link opened after the password already changed. Complete a reset, then open a second valid link generated before the change and verify it is rejected in the documented state.
• Token generated after a password change. Verify that changing the password invalidates any tokens created earlier, so a pre-change link cannot be used later.
• Cross-tab and cross-device. Request a reset, then open the link in a different browser or device, and verify the flow behaves per policy, either allowing it or invalidating the first attempt.
• Clicking while logged in versus logged out. Open the link in a fresh session and in an active session, and verify each lands in the intended state without confusing the customer about which account is being reset.
• Destination and return path. Verify the link sends the customer to the correct reset destination and, after success, to the sign-in page or the originally intended return path rather than a dead end.
• Replay from history. Ensure a consumed token cannot be replayed from browser history, cache, or a shared mailbox.

New-password form test cases

The reset form must enforce the same password policy as signup, or customers will set a password that later fails validation elsewhere. Shared policy is also why the signup registration test cases list overlaps with this section.

• Policy-compliant password saves. Set a new password that meets the policy and verify a success state appears with a path to sign in.
• Confirm-password mismatch. Enter two different values and verify an inline error before submit and on submit, with focus or error association on the confirm field.
• Empty fields. Leave the new-password or confirm field empty and verify validation errors fire before a server request.
• Weak-password errors, client and server. Enter a password below minimum length or without required character classes and verify the client shows guidance, then confirm the server independently rejects an equally weak value submitted past the client (for example through a modified request).
• Password equal to the old password. Set the new password to the current one and verify behavior per policy: either rejected with a clear "choose a different password" message, or accepted with the policy explicitly documented. Do not let this state be ambiguous.
• Whitespace handling. Verify passwords are not silently trimmed in a way that surprises the customer, and that a value with accidental leading or trailing spaces is handled consistently at set time and at sign-in.
• Pasting. Confirm the browser allows pasting into both fields and that a pasted value with surrounding whitespace or a trailing newline is handled correctly.
• Browser autofill interference. Confirm autofill, password managers, and the browser's "suggest strong password" overlay do not corrupt the fields, pre-fill the wrong values, or leave stale text in the confirm field.
• Session and submit edge cases. Verify the reset button is disabled during submission, a double submit cannot create two active passwords, and an expired token used at submit shows the resend state rather than a half-success.

Post-reset account-state test cases

A reset is complete only when the customer can actually use the new password. OWASP recommends not auto-logging the user in after a reset and sending a notification email, but the exact session policy is yours; these cases pin down whatever you chose.

• New password works. After the reset, sign in with the new password and verify the dashboard loads.
• Old password no longer works. Attempt sign-in with the old password and verify it fails with a normal invalid-credentials error, not a confusing one.
• Active sessions invalidated or scoped. Verify existing sessions, on other tabs, browsers, and devices, are invalidated after the reset, or, if your policy keeps them, that the scope is documented and tested rather than accidental.
• Remember-me and refresh tokens revoked. Sign in with "remember me," perform a reset, and verify the persisted session or refresh token is rejected and the customer must sign in again.
• Concurrent mobile and web sessions. With an active session on a mobile device and a web browser, reset from one and verify the documented behavior on the other.
• MFA still applies. If the account uses MFA, verify the next sign-in after reset still requires the second factor and that the reset itself did not silently disable it.
• No half-recovered state. Confirm the account ends up in a fully usable state, new password works, no stale "reset in progress" flag blocks login, and the customer is not forced through a second reset.
• Notification email. Verify a password-change notification email is sent without the password in it and reveals nothing an attacker could use.

Security and abuse test cases

Some of these are browser-visible and some need API or log access, but they all belong in the release gate for anything touching auth. OWASP's Credential Stuffing Prevention Cheat Sheet frames the account-level protections that surround this flow.

• Rate limiting on request and reset endpoints. Verify limits apply per account and per IP on both the request endpoint and token validation, so abuse cannot flood a victim's mailbox or brute-force tokens.
• No preemptive lockout from forgot-password attacks. Verify that repeated forgot-password attempts against a known account do not lock the account, which would let an attacker cause denial of service against a real user.
• Brute-force resistance on tokens. Confirm reset tokens are long, random, and single-use so they cannot feasibly be guessed, and that repeated invalid token attempts are throttled.
• No user enumeration in any error copy. Verify request, token, and reset errors all use consistent copy and timing so an attacker cannot distinguish a real account, a live token, or a close-but-wrong value.
• HTTPS on every hop. Confirm the request, the emailed link, and the reset all use HTTPS, that the reset URL domain is validated or hard-coded, and that the email includes a referrer policy that prevents token leakage through outbound links.
• No token leakage in email headers or preheader. Check that the reset token appears only in the intended link or code and not in the subject, headers, tracking pixels, or the preheader text previewed in inboxes.
• Audit logging. Verify successful and failed resets are logged with enough context (account, timestamp, IP) for incident review, and that the logs do not store the token or password.
• Suspicious-activity handling. Define and verify what happens when a reset is followed by a new sign-in from an unfamiliar location or device, such as a notification or challenge, without blocking legitimate recovery.
• MFA and recovery interplay. If MFA recovery or backup codes exist, verify the reset flow cannot bypass them and that resetting a password does not silently reset security settings.

UX, copy, and accessibility checks

These checks decide whether a locked-out customer can actually finish, which is the point of the whole flow.

• Confirmation copy and next steps. Every state, email sent, email failed, link expired, link used, password changed, tells the customer what happened and what to do next.
• Resend path. Provide a visible, rate-limited "resend email" action and verify it triggers a new request without looking like a duplicate submission.
• Support link. Offer an obvious path to support or help on the failure states, because a customer who cannot recover will contact support.
• Success then redirect. After "password changed successfully," the customer should reach sign-in clearly, with the option to sign in and a note that the old password no longer works.
• Accessibility. Verify keyboard focus order moves logically, error messages are programmatically associated with their fields, and contrast on validation and success messages meets accessibility standards.
• Mobile viewport. Confirm the request form, the reset form, and the confirmation states render and are usable on a narrow mobile screen, since password recovery often happens on a phone.
• Empty and error state consistency. Confirm every error state keeps previously entered values where it makes sense and never silently clears the form on a validation failure.

Which checks belong in code versus a browser journey

No single tool covers every surface of a password reset. Token expiry, rate limits, mail content, and session invalidation are best asserted deterministically against the API and a real or test mailbox. What a browser journey adds is the visible states code cannot see: the confirmation screen a customer reads, the validation UI, the expired-link page, and a reset form that does not drift between releases. A coded check can assert the API rejected an expired token; only a live browser run proves a locked-out customer sees a clear next step and can finish recovery. The email verification testing guide covers the mailbox-side patterns, and our coded versus agentic password reset testing piece explains how to split a journey between deterministic assertions and a browser run.

Where the mailbox is out of reach, a browser tool can still reach the reset form through a seeded token, verify the form and its success state, and hand deterministic expiry and mail assertions to the coded suite. Keep token and rate-limit rules deterministic and cover the changing recovery interface with a browser journey. In a natural-language tool such as CueTest, the flow reads like "sign in as the test user, choose forgot password, submit the registered email, and confirm the reset instructions page appears," and a run returns the failed step, screenshot, and trace as evidence. This journey fits into the wider web app E2E testing checklist; phrasing guidance is in how to write good E2E test cases.

Master password-reset test checklist

FAQ

What are the most important password reset test cases?

The security-critical ones: a used token cannot be reused, an expired or tampered token is rejected without leaking account details, the request form does not reveal which emails have accounts, and after a reset the old password stops working while the new one works everywhere. A happy-path test alone will not catch any of these.

How long should a password reset link be valid?

There is no universal number; a common default is 30 to 60 minutes, and the right window is a policy decision balancing convenience against risk. OWASP's guidance is that the token be single-use and expire after an appropriate period. Whatever you choose, test the boundary, a token just inside and just past expiry, and document it.

Can I test a password reset flow with a browser E2E tool?

Partially, and the split matters. A browser journey can verify the request confirmation, the reset form, the expired-link page, and the post-reset sign-in because those are visible states. Token expiry, rate limits, and the actual email content need a real mailbox or API access. A common pattern is a browser journey for the interface plus deterministic checks for the token and mail rules, which our automate password reset testing tutorial shows.

Should resetting a password log out all other sessions?

That is a product policy, not a universal rule. The secure default is to invalidate existing sessions and remember-me tokens after a reset, and OWASP treats the change as sensitive. If your product deliberately keeps sessions, document and test that behavior on other devices and tabs.

When should I re-run the password reset checklist?

Run the full journey after any change to authentication pages, email templates, account settings, shared form components, the session library, or anything that touches password policy. It is a short, customer-critical path that is easy to skip when the release focus is elsewhere, which is exactly why the recurring regression matters.

Sources

• OWASP Cheat Sheet Series: Forgot Password Cheat Sheet
• OWASP Cheat Sheet Series: Credential Stuffing Prevention Cheat Sheet
• Playwright documentation: Authentication