Understand password recovery requests
Customer App owns a password-recovery request form for an email address. It does not own the screen that consumes a recovery link or sets a new password. Submitting the request therefore cannot prove that an account exists, a message was queued or delivered, a link is valid, a password changed, or sessions were revoked.
The safe public result is enumeration-neutral: after a syntactically acceptable request, show the same generic accepted state whether or not an account matches. This is a required contract, not a claim that every deployed response currently has identical content or timing.
Request-form states
| Visible state | Safe interpretation |
|---|---|
| Blank request | No recovery request has been submitted |
| Local input error | The form rejected the input shape before an accepted request state |
| Challenge required or unavailable | An optional anti-abuse provider step is unresolved; no account lookup or delivery outcome follows |
| Submitting | A request may be in flight; do not repeat it |
| Generic accepted | The app accepted the request for processing without revealing whether an account matches |
| Generic unavailable or error | Recovery state is unknown; no account-existence, queue, delivery, or reset conclusion follows |
A disabled control, changed label, toast, Back action, or navigation change is local presentation. It is not an authoritative recovery receipt.
Keep recovery stages separate
| Stage | Owner/boundary | What the prior stage does not prove |
|---|---|---|
| Local form validation | Customer App | That the request is authorized or accepted |
| Optional anti-abuse challenge | Challenge provider and server policy | That an account exists or the server accepted the request |
| Request acceptance and throttling | Recovery service | That account lookup matched or a message was queued |
| Account lookup | Identity service | That the result may be disclosed or that mail was sent |
| Message queue | Recovery/mail service | Delivery to an inbox |
| Delivery | Mail provider and recipient system | That the recipient opened it or the link is valid |
| Recovery link | Recovery service and approved origin | That it is current, unused, intended for this session, or safe to open |
| Password reset | Reset experience and identity service | That every active session or older recovery capability was revoked |
| Session revocation | Identity/session service | Logout on every device or provider cleanup unless explicitly confirmed |
The app's generic accepted state must not be changed into “account found,” “message sent,” “delivered,” or “password reset.”
Account privacy and throttling
Existing, missing, disabled, or rate-limited account inputs must not produce distinguishable public content, timing, retry guidance, or challenge behavior that reveals account existence. Throttling should happen before costly mail or plugin work and should preserve the same generic public acknowledgement.
Do not use another person's address, a sequence of guessed addresses, or repeated submissions to diagnose recovery. An accepted response is deliberately not an account lookup tool.
Link origin, expiry, and replay
A recovery link is a sensitive, single-purpose capability. Only an approved, canonical application origin may create its destination. Request-supplied or forwarded origin information is not authority.
The link must be short-lived, single-use, bound to the intended recovery operation, stored safely, and consumed atomically with password change and the defined session-revocation policy. If origin, expiry, prior use, concurrency, account generation, or revocation cannot be established, treat the link as invalid or the outcome as unknown.
Customer App provides no current reset-link or new-password procedure in this guide. Never copy, inspect, modify, forward, or reuse a recovery link or code for troubleshooting.
Unknown and partial outcomes
| Situation | Safe interpretation |
|---|---|
| Submit remains busy or the app closes | Request acceptance is unknown; do not repeat automatically |
| Generic accepted appears but no message arrives | Account match, queue, delivery, filtering, and timing remain undisclosed |
| More than one message appears | Do not compare or try multiple links; use only an approved current recovery process |
| A link opens an error or unexpected destination | Do not enter a password or identity data; leave the surface |
| A reset screen reports success but sign-in state is unchanged | Password, link consumption, and session revocation can settle separately |
| An older session stays active | Do not infer whether the password changed or whether revocation is pending/unsupported |
| Account/project changes during recovery | Discard the previous context; late results must not enter the new generation |
Unknown recovery outcomes require a status/support policy defined by the identity owner. They do not authorize automatic request, link, reset, or logout replay.
Troubleshoot safely
- Confirm that you are using the intended Customer App and an approved sign-in entry, without inspecting or copying its internal address.
- Submit no real account information for documentation or testing.
- Do not repeatedly request recovery to test throttling or delivery.
- Do not share screenshots of the request, message, link, code, reset screen, account state, or provider error.
- Treat challenge, queue, delivery, link, reset, and session state as separate.
- If a link destination is unexpected, leave it and use an approved support or security channel without forwarding the link.
Accessibility and privacy
Email input, local validation, challenge, Submit, busy, generic accepted, generic unavailable, Back, and unknown states need distinct semantic names, roles, values, disabled/busy state, announcements, and predictable focus. Generic acceptance must not be weakened by screen-reader-only text or different focus behavior that reveals account existence.
Large text, keyboard navigation, safe areas, and iOS/Android Back behavior must not hide errors or cause duplicate submission. Recovery values and provider errors must not enter accessibility labels, logs, screenshots, clipboard, or diagnostics. These are verification requirements, not a claim of current accessibility, privacy, delivery, or identity certification.
Recertification triggers
Revalidate this reference after changes to request form fields, validation, challenge configuration/server binding, generic response/timing, throttling, account lookup, mail queue/provider, canonical origin, link format/storage/ expiry/consumption, reset experience, password update, session revocation, plugins, navigation, logging, or accessibility.
Related guides: Log in · Verify your account · Account settings · Understand privacy and consent · Understand invalid-link behavior