Password recovery is often the first interaction a returning customer has with a portal. If it is unclear, they may submit the request repeatedly, abandon the task or contact staff with sensitive information. Design the whole journey from the forgotten password link to a successful sign-in. Include expired links, mistyped addresses and customers who have changed jobs since their last visit.
Explain what happens after the request
Imagine a customer returning to a Perth equipment service portal after several months. They enter an email address and need a clear next step. OWASP recommends consistent responses whether or not an account exists, which helps avoid exposing account membership. The page can still explain that instructions will arrive if the address is associated with an account, suggest checking the spelling and provide a route for further help. Avoid showing a technical success message that leaves the customer unsure whether to wait, refresh or submit again.
Treat the link as a temporary credential
OWASP's reset guidance calls for reset tokens to be single use and to expire after an appropriate period. Use the authentication platform's supported implementation rather than inventing an ad hoc code process. The customer-facing screen should explain an expired or already-used link and offer a fresh request. It should not expose internal token details. After a successful reset, provide a deliberate path back to sign-in and the original task. Decide how existing sessions are handled and make the relevant security behaviour clear to the implementation team.
Separate account recovery from email changes
A customer who no longer has access to their email presents a different problem from someone who forgot a password. Staff should not simply replace the address because a caller knows the business name or an old order number. Define an identity-checking and escalation process proportionate to the account's access. Keep support instructions practical: what information staff may request, what they must not request and who can make the final change. Never ask customers to send their password to support, even as part of troubleshooting.
Test beyond the happy path
Run a fictional customer's reset journey with a delayed email, an expired link, a second reset request and a changed email address. Observe what the customer is told at every point. Before launch, confirm:
- The request response avoids revealing whether an account exists.
- Expired or reused links lead to an understandable next action.
- Support has a separate process for lost access to the registered address.
- The customer can return to the work that prompted the sign-in attempt.