# Treat a Primary Email Change as an Identity Migration > Use fresh authentication, two-address notifications, pending state, uniqueness handling, and recovery for primary email changes. Canonical URL: https://www.devobs.io/articles/secure-primary-email-change/ By: Sofia Reyes Published: 2025-05-25T13:45:42.364Z Updated: 2026-09-05 Section: Identity A primary email change moves login and recovery authority, so handle it as a stateful identity migration. Require recent authentication, verify the new address, notify the old address, preserve a bounded cancellation path, and decide separately when the new value becomes a login identifier and recovery destination. ## Separate request, proof, and activation Create a pending change containing identity ID, old address, normalized new address, requester session, issue time, expiry, and one-time verification state. Do not overwrite the active email when the user types a new value. Send a confirmation to the new address and an alert to the old one. The alert should explain the request and offer a protected response path without exposing account data. OWASP's [Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) calls for reauthentication before changing sensitive account information and includes a dedicated process for registered-email changes. Fresh proof matters because an unlocked browser or stolen session may be enough to request the change. Match the proof strength to the account and risk; do not let possession of the already-compromised session satisfy every step. Choose activation semantics explicitly. One defensible flow keeps the old email active until the new address is verified, then switches login and recovery together and sends a completion notice to both. Higher-risk products can require confirmation from both addresses. When the old address is unavailable, route the user through account recovery with stronger evidence rather than quietly weakening the normal path. ## Preserve identity independently of email Use an immutable internal subject ID for ownership, audit logs, relationships, and foreign keys. Email is a mutable identifier. Changing it must not create a new person or rewrite historical actor IDs. Normalize addresses consistently before uniqueness checks, but avoid provider-specific transformations such as removing dots unless the provider contract guarantees their equivalence. Reserve the new address atomically during activation. Two identities can request the same address concurrently; only one may win. Return a response that limits account enumeration, and record the conflict for support without revealing the other identity. Expired and cancelled changes release their reservation. Decide whether an old address may be reused immediately or enters a cooldown to reduce takeover and audit ambiguity. Ory Kratos is an API-first identity and user-management system with account-management flows and a custom user-interface option. The [Ory settings-flow documentation](https://www.ory.com/docs/kratos/self-service/flows/user-settings) is the implementation reference when that system owns the account update. Ory Network provides the managed path; self-hosted Ory Kratos is a separate deployment choice. The application still needs an explicit notification, rollback, and uniqueness policy. ## Contain a compromised change After activation, rotate or revoke sessions according to risk. At minimum, mark sessions with the identity revision and require reauthentication for sensitive actions. For suspected compromise, revoke other sessions, recovery codes, and pending changes, then guide the owner through recovery. Do not send a rollback link that alone grants account control; require appropriate authentication or recovery proof. Audit request, verification, cancellation, activation, address hashes or protected values, session, IP and device context according to privacy policy. Never log verification tokens. Rate-limit requests and resends by identity, destination, and network signal. A new request should supersede older pending changes so links cannot race. ## Test the state machine Test stolen session, expired token, repeated click, two simultaneous new addresses, uniqueness collision, email changed after MFA enrollment, old-address loss, account recovery during a pending change, and completion in two tabs. Assert login and recovery behavior at every state, not only the profile value. The next step is to diagram the current email-change states and identify the exact moment login and recovery authority move. Review by 2026-12-05 or when identity or recovery policy changes. ## Source references - -