Verify an email change before moving account recovery
Treat email changes as sensitive identity transitions. Define pending state, reauthentication, address confirmation, notifications, and concurrent-change behavior.
An email address may control login, password recovery, notifications, or all three. Before reviewing a change form, list the uses of the address. A change that only updates a contact label has a different consequence from moving the account's recovery channel.
OWASP describes registered-email change procedures, including reauthentication and confirmation. Choose a process appropriate to the account's authentication factors. Keep the proposed address pending until the required checks complete.
Write the pending-change record
Bind a request to the account, proposed address, creation time, required proofs, and an expiry. The confirmation must approve that exact proposal, not whichever address happens to be stored when the link is opened.
| Event | Account behavior to define | Negative test |
|---|---|---|
| New address proposed | Retain current recovery authority | Session alone cannot bypass required reauthentication |
| Confirmation received | Validate the specific pending request | Proof for an older address cannot approve a newer one |
| Request expires | Leave current address unchanged | Late link cannot complete the change |
| Second change requested | Cancel or version the first proposal | Two requests cannot cross-confirm |
Record which existing factors must be used. A security question is not a substitute for a stronger factor already bound to the account.
Test delivery and identity separately
Use two controlled inboxes and a synthetic account. Confirm that the proposed address receives the intended proof request and that the current address receives the required notification or confirmation under your policy. Mail delivery alone does not prove that the change was authorized.
Check that expired, already-used, and mismatched confirmation records leave the active address unchanged. Include address uniqueness and case-handling behavior according to your identity system. Do not silently merge two accounts because their normalized email strings match.
Protect recovery and audit continuity
After completion, test login and recovery against the documented active address. Decide how existing sessions and pending password-reset requests are affected. Keep a minimal audit record of the change without exposing confirmation tokens or unnecessary email history to general logs.
Define a separate process for users who cannot access the current inbox. Do not weaken the ordinary flow with an undocumented support bypass. The final review artifact should show the exact proposal, required proofs, single completed transition, and resulting recovery behavior. That evidence makes the identity change understandable without treating a successful form submission as sufficient authorization.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.
Sources
- OWASP Authentication Cheat SheetAccessed