10 Mobile App Password Reset Flow Examples

01. Recovery entry

Ask for the smallest identifier needed to begin recovery.

A reset request should feel familiar even when the user is stressed or unsure which account they used.

Symmetry: AI Gym Workout Log opens this decision with “Change Password” and keeps “Confirm your email address” in the same state. Opal: Screen Time Control uses “Cancel” with “Opal” visible nearby. Looking at both recorded screens makes the tradeoff concrete: the entry screen works best when the account identifier, action, and next delivery step are obvious without revealing account existence. These are interface observations, not a claim that either treatment performs better.

Pre-fill a remembered email only when the user or platform selected it, and let the person change it. Use persistent field labels and the correct keyboard. The response after submission should be the same for existing and unknown accounts when enumeration is a risk, while still offering practical help for spelling mistakes and provider-based accounts.

Submit the request idempotently and rate-limit by destination, account, device, and network risk. Return a challenge reference and a neutral confirmation. Do not expose user IDs, recovery tokens, or account state to the client.

02. Authenticated change

Separate “change password” from “forgot password.”

A signed-in user replacing a known credential is not the same as someone proving account ownership from outside.

EVA AI Soulmate opens this decision with “Reset password” and keeps “Email” in the same state. DaVinci - Image Generator AI uses “Set a new password” with “Your new password must be different to previously used password.” visible nearby. Looking at both recorded screens makes the tradeoff concrete: current-password and email-confirmation screens show how products add assurance before a sensitive account change. These are interface observations, not a claim that either treatment performs better.

Label the route according to the actual task. Change password can ask for the current credential and new credential in one place, while Forgot password should move into recovery. For high-risk accounts, use recent authentication or step-up verification rather than assuming an old session is enough.

The backend should verify the current session age, authentication method, risk signals, and current credential where required. A social-only account may need a different path instead of inventing a password state that does not exist.

03. New credential

Show password requirements before rejection.

Users should know the rule set while composing a credential, not after submitting it twice.

Align: The Human Design App opens this decision with “Change Password” and keeps “Existing Password” in the same state. ShutEye®: Sleep Tracker, Sound uses “Reset password” with “Email” visible nearby. Looking at both recorded screens makes the tradeoff concrete: new-password forms become easier to review when current, new, and confirmation fields are distinctly labeled and visibility controls behave consistently. These are interface observations, not a claim that either treatment performs better.

Put the essential requirements near the first new-password field and update them accessibly as the user types. Allow password managers and generated passwords. Avoid arbitrary composition rules that encourage predictable substitutions; favor sufficient length, breached-password checks, and clear feedback aligned with the identity system.

Use secure text fields with correct autofill semantics for new passwords. Validate on the server, compare confirmation locally, keep visibility toggles independent, and never send password strength or content to product analytics.

04. Reset delivery

Set expectations for links, codes, expiry, and resend.

“Check your email” is incomplete when users do not know the destination, delay, or next recovery route.

Muscle Monster Workout Planner opens this decision with “Set Password” and keeps “[email protected]” in the same state. Hallow: Prayer & Meditation uses “Reset Password” with “Update your password by sending a reset link to the associated email account.” visible nearby. Looking at both recorded screens makes the tradeoff concrete: request screens that name the channel and purpose make the off-app transition easier to resume. These are interface observations, not a claim that either treatment performs better.

Show a safely masked destination, expected arrival, spam guidance, and a resend control with an honest cooldown. A link should open the app into the same reset challenge, survive installation or browser fallback where supported, and clearly explain expiry. A code flow needs the same entry and recovery rigor as any OTP screen.

Issue single-use, short-lived tokens bound to the account action and redirect allowlist. Invalidate old tokens after a successful reset or replacement challenge. Protect deep links against token leakage in logs, referrers, analytics, and screenshots.

05. Completion and return

Confirm the change and resolve the user’s sessions.

The final state should answer whether the password changed, where the user is signed in, and what happens next.

memoryOS: Memory Games opens this decision with “Change password” and keeps “You will be sent a link with instructions on” in the same state. JustStretch | Flex & Mobility uses “Set Password” with “Email Address” visible nearby. Looking at both recorded screens makes the tradeoff concrete: confirmation is valuable when it closes the security loop and provides one deliberate route back to access. These are interface observations, not a claim that either treatment performs better.

Say that the password was updated without repeating sensitive information. Explain whether other devices were signed out and provide a way to report an unexpected change. If login is still required, return with the identifier preserved. If the session remains valid, resume the account or task that initiated the change.

Rotate relevant tokens, revoke or retain sessions according to policy, notify the account through an independent channel, and audit the event securely. Consume the reset token exactly once and prevent back navigation from resubmitting the completed change.

Implementation

Treat recovery as an identity protocol with a visible beginning and end.

Every screen should correspond to a server-enforced challenge state.

Define separate intents for unauthenticated reset, authenticated change, forced reset, compromised credential, and provider-managed account. Each intent needs its own assurance level, token lifetime, retry limits, session behavior, notification, and return destination.

Use generic request responses where necessary, but keep client states precise after the user possesses a valid challenge. Handle expired links, used links, mismatched devices, canceled provider steps, offline submission, password-manager insertion, and app-to-browser handoff without losing the intended account action.

Model the page as explicit states rather than a single happy-path mockup. Include initial, loading, success, empty, partial, offline, permission-denied, validation, and server-error states where they apply. Preserve the user’s context across each transition, prevent duplicate submissions, and keep recovery close to the failed action.

Accessibility is part of the interaction contract. Test Dynamic Type, VoiceOver, keyboard focus, switch control, contrast, reduced motion, localization, right-to-left layouts, and touch targets. A visually compact pattern is not finished until the task remains understandable without color, animation, or perfect connectivity.

Measurement

Measure recovered access and security outcomes together.

A reset request is not success until the intended person safely regains the account.

Track recovery entry, valid identifier format, neutral request acceptance, delivery latency, link or code opening, challenge validation, new-password submission, categorized rejection, completion, subsequent sign-in, and successful return. Keep raw identifiers, tokens, and password material out of analytics.

Segment abandonment by request, delivery, challenge, credential, and return stages. Review resend volume, expired-token rate, password-manager use where measurable without sensitive capture, account-lock support contacts, compromised-account reports, suspicious request bursts, and session-revocation failures.

Review qualitative evidence beside the event data. Watch moderated sessions, support conversations, replayed failures, accessibility testing, and open-ended feedback for confusion that a funnel cannot name. Define guardrails before release so an increase in one completion metric does not hide more accidental actions, privacy concerns, refunds, support work, or abandoned downstream tasks.

Review checklist

Review password recovery under realistic pressure.

Test the path from every locked-out and authenticated entry point.

Include provider accounts, unknown identifiers, expired links, new devices, active sessions, and poor connectivity.

• ✓The screen names the user’s current task in plain language.
• ✓One primary action is visually dominant and accurately labeled.
• ✓Secondary actions remain available without competing with the main decision.
• ✓Input, selection, loading, success, and failure states are designed before implementation.
• ✓Back and close behavior preserve the context that brought the user here.
• ✓Errors explain a recovery action and never erase valid work unnecessarily.
• ✓Sensitive information is minimized in both the interface and analytics.
• ✓Large text and screen readers preserve the intended reading and focus order.
• ✓Slow, offline, interrupted, and duplicated actions have deliberate outcomes.
• ✓Analytics measure completion of the user’s real task, not only button taps.
• ✓The pattern is tested inside the full journey, not as an isolated screenshot.
• ✓Recorded examples are used as references, then adapted to the product’s own constraints.

Related design decisions

Link recovery to sign-in and verification.

Account access patterns should share language and return behavior.

Comparemobile app login screen examplesso recovery returns to the correct account context.

UseOTP verification screen exampleswhen reset ownership is confirmed by a short code.

Reviewmobile app privacy settings examplesfor adjacent account data and security controls.