Changing a Customer's Login Email: A Profile Edit or an Account-Security Workflow?
Treat a change to a customer's registered login email as a separate account-security workflow, not an ordinary contact-field edit. Specify how the person proves control of the account, how the new address is confirmed, what the old address receives and when the change becomes effective. The form should make it clear that requesting a change is not the same as completing it.
This guide concerns a signed-in customer changing the registered address. Forgotten passwords, lost multifactor authentication and recovery after losing access to a mailbox require separate procedures. It is not a complete security specification or a promise that these checks prevent every attack.
Decide what “email address” means in your app
A portal may have a login address, an address for invoice delivery and a contact address on a customer record. Before drawing the form, decide whether those are one field or deliberately separate fields. Write down which of them this action changes.
For example, a hypothetical customer might want invoices sent to an accounts department without giving that department ownership of the login. That is a delivery-preference decision, not necessarily a change of account identity. Do not force both changes together merely because the first database design used one column.
If sign-in is managed by an external identity provider, ask the developer which system owns the registered address and which changes your portal can actually perform. Do not promise a local edit will change an identity maintained elsewhere.
Use a pending state rather than changing the field immediately
The OWASP Authentication Cheat Sheet recommends checking that the authentication cookie or token is valid, explaining the process, taking a proposed address that meets system rules and storing it as a pending change. Its recommended identity checks and messages differ depending on whether multifactor authentication is enabled.
Translate that into a customer-facing requirement: show the current registered address separately from the proposed replacement and say what still needs to happen. “Confirmation requested” must not look like “Your login email has changed.” Agree which address remains usable during the pending period and demonstrate it; this guide does not assume a particular product's behaviour.
Also decide what happens if a customer starts a second change before completing the first. A reasonable design is to supersede the earlier request and explain that only the latest request can be completed. That is a proposed requirement, not an assertion that OWASP mandates that exact rule.
Do not combine OWASP's two confirmation paths into one shortcut
For accounts with multifactor authentication enabled, OWASP's recommended process uses MFA to verify identity, sends a notification to the current address and requires confirmation at the proposed new address. The notification to the current address includes a way to report unexpected activity.
For accounts without MFA, its recommended process asks for the current password and requires separate confirmations at both the current and proposed addresses. Do not describe the old-address message as notification-only in this branch.
These are OWASP recommendations, not a legal rule or proof that every provider uses them. Ask the developer to document the chosen flow and explain deviations. A customer-facing message should identify which steps apply to that customer's account without exposing sensitive implementation details.
The same section recommends time-limited nonces for the process. Require the developer to specify and test the lifetime of each confirmation link. Do not invent a universal expiry duration from this guidance.
Give incomplete and unexpected requests a defined ending
Agree what happens when the customer mistypes the new address, never receives its message, lets a link expire or no longer wants the change. A pending request should have a clear status and an agreed route to cancel or start again. Expired or superseded links should not silently switch the address later.
The old-address warning also needs an operational owner. Decide where an unexpected-change report goes, what the recipient sees and how staff respond without asking the customer to send passwords or confirmation links. This is a support process to design, not an email address to put in the interface and forget.
If the customer cannot access the current mailbox, do not tell staff to tick its confirmation step manually. Use a separately approved recovery procedure. OWASP also warns that help-desk staff should follow prescribed processes and recognise social-engineering attempts. A convincing explanation from a caller is not a substitute for the agreed identity checks.
Ask for an end-to-end demonstration
Use test accounts and mailboxes controlled for the test, not live customer accounts. No single demonstration proves the whole system secure, but these proposed checks make the agreed flow observable:
- An invalid or absent session cannot start the change through either the interface or a direct request.
- The required MFA or current-password check occurs for the chosen branch.
- The proposed address appears as pending rather than silently replacing the current one.
- The current-address message is a notification in the MFA branch, but requires confirmation in the non-MFA branch, following the documented design.
- The new-address confirmation alone cannot complete a non-MFA change that still needs old-address confirmation.
- Expired, cancelled and superseded requests cannot complete the change.
- The final state clearly identifies the registered address and matches the agreed sign-in behaviour.
- Staff have an agreed response to unexpected activity and lost-mailbox cases, without an informal bypass.
Record the actual chosen behaviour in your app acceptance criteria. Also ask what happens to other signed-in sessions and connected systems when the change completes. Those consequences need explicit decisions; the narrow source section cited here does not settle them.
Scope decisions before commissioning
Can the same form change the invoice address too?
Only if that is intentional and clearly explained. Keep the concepts separate in the specification even if the interface offers both actions.
Does a password reset also change the registered email?
Do not assume so. Resetting a password and changing the account's registered address are different workflows. Specify both if both are needed.
What if the authentication provider already offers this feature?
Ask for its actual supported flow to be demonstrated, including pending states, messages and recovery boundaries. Avoid commissioning a parallel local feature that appears to change the address while the authoritative identity remains unchanged. You can discuss the integration boundary through business-app development.
Source and limits
OWASP Authentication Cheat Sheet, “Changing A User's Registered Email Address”: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#changing-a-users-registered-email-address. The source supports the distinct MFA and non-MFA recommendations, pending storage, time-limited nonces and staff process guidance. Field separation, superseding requests, interface wording and the proposed demonstrations are commissioning advice, not claims of tested implementation.