Log each step of the reset flow as an event: request received, message sent, token used, password changed, sessions revoked and notice sent. Include account, source and outcome. Never log the token, the new password or the reset URL. Alert on bursts of requests and resets followed by unusual sign ins.
Why recovery is a target
Account recovery is an alternative way in. An attacker who cannot guess a password may try to hijack the reset path instead. The flow often involves email, tokens and fallbacks that get less testing than the main login.
What OWASP says about the flow
The OWASP Forgot Password Cheat Sheet does not give logging guidance, so use it for the behaviour you will be logging. It says to return the same message whether or not an account exists, keep timing uniform, rate limit per account, and generate tokens with a secure random generator, tied to one user, with an expiry. Tokens must be invalidated after use, and outstanding links should be invalidated after a successful recovery. It also says to email the user when the password has been reset, without including the password, and to ask whether to invalidate all sessions or do it automatically.
Each of those behaviours is a point where an event is useful.
Events to record
| Step | Event | Fields |
|---|---|---|
| Request | reset_requested | Account if it exists, source, whether the account was found, request ID |
| Delivery | reset_message_sent | Channel, account |
| Token check | reset_token_valid or reset_token_invalid | Account, source, reason such as expired or reused |
| Completion | password_changed | Account, source, method reset |
| Cleanup | sessions_revoked, reset_links_invalidated | Account, count |
| Notice | user_notified | Channel, account |
| Failure | reset_rate_limited | Account, source |
The user facing message stays uniform, but your internal event should say whether the account existed. That distinction is invisible to the requester and valuable to you.
What never to log
The reset token, the reset URL, the new password and the old password. If the token reaches a log, anyone with log access can take over the account until it expires. OWASP recommends invalidation after use and an expiry, which limits the damage, but prevention is better. Also avoid logging the full email address in the open if you can use an account ID.
Alert rules
- Many reset requests for one account from different sources.
- One source requesting resets for many accounts.
- Many invalid token attempts, which suggests token guessing.
- A reset followed within minutes by a sign in from a new device and a change to email or MFA settings.
- A reset on a privileged account.
The last two are the strongest. Route them to a person and consider forcing step up verification.
For the sign in side, see authentication events to log.
Quick check
Should the user see whether the account exists?
No. Show the same message either way, and record the real result in your internal log only.
Do I need to log the email we send?
Log that it was sent, with channel and time, but not the link or code inside it.
Safeguard checks the dependencies that sit behind authentication libraries. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
