A customer portal can have an attractive reset screen while leaving old recovery links usable. Before approving the recovery feature, agree what creates a token, what invalidates it and what evidence confirms a completed reset. This is separate from making the login form easy to use.
Primary evidence and claim boundaries
OWASP advises cryptographically secure, user-linked, expiring single-use recovery tokens, consistent account-existence responses and no account change before a valid token. Primary reference · Read 17 October 2026.
Filled acceptance example
Synthetic teaching scenario, not a client case, provider integration test or business result. Scroll the example table on narrow screens.
| Synthetic request | Declared test policy | Expected result |
|---|---|---|
| TokenT1 for userU1; issued 10:00 | Example expiry 10:15; now 10:10 | Valid forU1 once |
| T1 after completed reset | Used flag recorded | Reject replay |
| T2 at 10:15 | Expiry reached | Reject; offer new request flow |
| T3 forU1 submitted forU2 | Account binding mismatch | Reject without revealing account details |
Practical handover procedure
- Have the security owner choose the lifetime, abuse controls, delivery channel and session handling. Fifteen minutes here is an example policy, not an OWASP mandated duration.
- Use dummy accounts and synthetic token references in acceptance records. Test expiry boundaries, cross-account use, replay and unknown-email responses without logging usable tokens.
- Verify the password change and token consumption as one safe transaction. Confirm notification and existing-session treatment against the agreed policy, separately from email delivery.
Interpret the outcome
T1 is valid once, not until somebody manually deletes a row. The acceptance evidence is the state transition and the denied second attempt; merely reaching a “reset complete” page proves less. A failed email does not justify relaxing identity checks or sending a usable link through public support.
Acceptance decision
Approve only after authorised tests show token binding, atomic consumption, expiry and a documented post-reset session policy. Retain redacted results, never token secrets.
Limits and unverified work
No reset, message, credential collection or real account action occurred. This is a supplier brief, not a complete authentication implementation or security certification.
Download the filled bilingual acceptance record — Contains these inputs, steps, expectations and limits. This is a teaching record, not an executable integration.