Change an email address safely: verify both inboxes and end every session

Changing an account email address is not a one-field profile update when that address is part of sign-in or recovery. It is a sensitive credential change. The secure default is to verify control of the current inbox and the new inbox, update dependent records in one controlled operation and revoke existing sessions.

Treating the flow this seriously protects people from a stolen session becoming a permanent account takeover. It also protects the product from quieter failures: a typo that locks someone out, a stale invitation attached to the old address or a duplicate account created by an ambiguous journey.

Key takeaways

• Verify the existing address and the replacement address. Each proof answers a different risk.
• Return neutral responses. Do not reveal whether an entered new address belongs to an account.
• Serialise the workflow. Send limits and attempt counters must survive parallel requests.
• Invalidate sessions after completion. A credential change should not leave an old device trusted.
• Do not merge accounts automatically. Keep histories and permissions separate unless there is a reviewed, explicit migration path.

Verify both inboxes for different reasons

OWASP recommends re-authentication for sensitive features and advises using generic responses where different errors could reveal account information. Its Authentication Cheat Sheet is a useful baseline for the whole flow.

Keep the response neutral

A form that says “that address already has an account” creates an account-enumeration endpoint. The person changing their address should see the same neutral result whether the destination is free, blocked by a business rule or already associated with another account. Handle the operational difference privately, after the user has proved the address or through a separate notification.

This protects more than a credential list. Account membership can be sensitive context. Neutral language also gives the team freedom to change internal policies without exposing their rules through the interface.

Protect the codes and the workflow from races

Short-lived, single-use codes need attempt limits, resend limits and a bounded journey timeout. Store code verifiers rather than the raw code, and compare them server-side. The browser should never receive a stored verifier or be trusted to decide whether it has remaining attempts.

A read-then-write implementation can lose these controls when multiple requests arrive at once. Use a database transaction, row lock or per-account lease so each request observes the state written by the previous one. Reject or safely queue a concurrent request according to the journey you have designed. Do not let every request independently believe it is the first.

Inventory every place the old address exists

The account record is usually the easy update. Audit every dependent copy and decide its policy before shipping: pending invitations, billing contacts, notification preferences, linked identity-provider records, user-entered contacts and search indexes may each need a different answer.

Do not blindly replace every matching string. A contact field could intentionally contain a parent, finance colleague or shared mailbox. Update records only when you can prove they represent the account credential, and use a transaction or durable reconciliation process for the rest.

End sessions, then enforce the end

Session revocation is necessary after a credential change, but access tokens already issued may remain usable until expiry depending on the identity system. OWASP’s session-management guidance recommends renewing sessions after re-authentication and credential changes. Design the server or API to reject a revoked session promptly, not only the browser to clear a cookie.

Clear the current browser session as part of the completed action, notify other active clients through their normal session checks and ensure every protected request independently recognises revocation. A friendly sign-out screen is not enough if an old token can still perform a sensitive API call.

Keep account merging separate

A new email may already belong to another account. Automatically merging looks convenient but can combine unrelated histories, permissions and billing relationships. It is difficult to reverse and dangerous to infer. Keep the accounts distinct and offer a separate, explicit transfer process only where the product can verify authority and explain the result.

A secure email-change checklist

1. Map the credential and every dependent copy. Decide an update policy for each before implementation.
2. Verify both inboxes. Use short-lived, server-checked proof and notify the prior address.
3. Use generic external responses. Never turn the form into an account lookup tool.
4. Make counter updates atomic. Test parallel attempts, resends and confirmation requests.
5. Revoke sessions at completion. Ensure APIs enforce revocation, not only the interface.
6. Keep merging out of the happy path. Make data transfers separate, reviewable operations.

Design credential changes as security journeys

The safest account settings are not the ones with the fewest screens. They are the ones that make every proof, limit and consequence explicit. A careful email-change flow gives a legitimate person a clear route forward while making an attacker’s brief access much less useful.