Changing account email safely in MENA SaaS

An employee changes the email address on a business account. The settings page calls it a profile edit, but that address may also receive password-reset links and identify the user at sign-in. A mistake can lock out the employee. A stolen session can turn the same feature into an account takeover.

For Arabic-English SaaS products serving MENA businesses, email changes need a defined handover between the current address and its replacement. This guide proposes a workflow for application-managed accounts, with separate treatment for enterprise identity providers. It covers an authenticated user changing an address, not a person who has already lost every way to sign in.

Cover: original SultanByte artwork showing a pending email change passing through verification before activation.

Decide what the address controls

Inventory every use of the email field before changing it. A notification destination, a sign-in alias and a recovery address may share one value today without having the same security requirements. An invoice recipient might be a team mailbox that should never become the account owner's recovery channel.

Keep the application's stable account identifier independent of the address. In the proposed design, changing email does not create a new principal, transfer workspace ownership or merge accounts. Existing membership remains attached to the same principal. Requests to move ownership to another employee belong in a separate administrative workflow.

Consider a consultant with access to a Saudi customer workspace and a UAE customer workspace. Changing the consultant's account email should not add access to either customer's other workspaces. Nor should a new corporate domain automatically establish employment or authorisation. Record those decisions against the relevant customer organisation.

Define the authority for federated users too. If an enterprise directory owns the sign-in identity, decide whether the application exposes a separate contact address or directs users back to that directory. Do not offer a local edit that appears to replace an upstream identity attribute but is overwritten at the next login.

Require evidence before staging the change

OWASP's authentication guidance distinguishes two email-change paths. For users with MFA, it recommends MFA verification, a pending address, notification to the current mailbox and confirmation at the new one. Its password-only path adds current-password verification and confirmation at both addresses.

That distinction is useful when reviewing a product's existing flow. A valid session cookie is not the same evidence as a fresh authentication challenge. Do not let a generic profile-update endpoint bypass the stronger email-change route by accepting an email property.

For this proposed workflow, bind recent authentication to the pending change, including its proposed destination. If the destination changes, discard the earlier approval and start again. Use the application's established request-protection controls for the authenticated mutation; hiding the field or requiring POST is not sufficient protection by itself.

Write down what happens when the user cannot access the current mailbox. If the configured policy requires its confirmation, that user needs a recovery route, not a support agent ticking a verification flag. The policy should explain what alternative evidence is acceptable and which actions remain restricted during recovery.

Keep the current address active while the replacement is pending

Treat the proposed destination as pending data. Show the current address separately, explain where each message was sent and say which step remains. A delivery success event must not activate the replacement: it does not prove that the intended person completed verification.

Provider behaviour is configuration-dependent. Amazon Cognito documents a verification-before-update setting. When enabled for the attribute, the original value remains usable until the new value is verified. The API setting is AttributesRequireVerificationBeforeUpdate. AWS also documents how an administrative update marking an attribute verified can bypass the ordinary verification step.

Supabase's updateUser reference describes a different default: email updates send confirmation links to both the current and new addresses. Disabling Secure email change changes that to confirmation at the new address only. The method requires a signed-in user; its documentation does not make every surrounding application policy automatic.

These are product contracts, not interchangeable recipes. For Cognito, inspect the user pool's attribute and alias configuration. For Supabase, inspect the project's email settings. In both cases, test the actual deployment with a mistyped destination and an inaccessible old mailbox before writing the support instructions.

Do not weaken verification simply because a test account cannot complete the flow. Fix the test setup or use the approved recovery path. Keep administrative credentials out of browser code, and review which backend operations can mark addresses verified without mailbox confirmation.

Original infographic: SultanByte. Proposed workflow informed by OWASP, Amazon Cognito and Supabase documentation, November 2026. Provider settings differ; the diagram is a design aid, not a security certification.

Bind verification to one pending operation

For an application-owned implementation, create a pending-change record rather than scattering flags across the user profile. Suggested fields are the stable account ID, current email version, proposed address, required proof types, expiry, authentication evidence and operation state. Store token digests separately from the messages that deliver the redeemable tokens.

OWASP's password-reset guidance recommends cryptographically random, securely stored, expiring, single-use tokens. Those properties are useful design inputs here too, although an email change is a different operation from resetting a password. Keep full verification URLs out of request logs, analytics and support screenshots.

Give each proof a specific purpose. A token sent to the new address proves control of that destination for this pending change. It must not confirm another address, reset a password or approve a different account's request. Do not use the new-mailbox token as a substitute for the required current-account authentication.

Choose explicit replacement semantics. In this design, editing the proposed address supersedes the pending operation and invalidates its proofs. Resending replaces the affected proof token, so an earlier message cannot complete that step. Explain that users should use the latest message, and rate-limit requests and resends without preventing ordinary correction of a typo.

Require an explicit confirmation interaction rather than making a link preview complete the change. Test the mailbox clients and security scanners used by pilot customers. A scanner visit should not leave the employee staring at a completed operation they never approved.

Make activation and recovery different operations

At activation, the proposed application-owned transaction checks that the operation is still pending, unexpired and based on the current email version. It requires the configured proofs, enforces the address-uniqueness policy, updates the account and consumes the operation together. A concurrent cancellation or second email change must use the same concurrency protocol.

Enforce uniqueness at the final write, not just when the user types the address. Two accounts can pass an earlier availability check before either commits. Reject a collision without merging accounts or revealing the other account's profile.

If the identity provider owns the address, a local database transaction cannot make the provider's mutation atomic. Track the request and reconcile the provider's authoritative result. Keep dependent application state pending until that result is known; a timeout is not proof that the provider rejected the change.

After activation, notify through the established safe channels and make the security consequences explicit. Define how existing sessions, reset links and cached email claims are handled. Test that policy against the token model you use: changing a profile field does not by itself establish that every previously issued credential has stopped working.

An unexpected-change report should start containment and investigation. It should not automatically restore the old address, which may itself have been abandoned or compromised. Recovery must use independent evidence under the account's recovery policy. SultanByte's passkey recovery guide covers the broader loss-of-access problem.

Make the Arabic review screen precise

OWASP's email-validation guidance recommends preserving the original address and documenting a consistent comparison policy. It cautions against provider-specific rewrites and careless treatment of internationalised local parts. Apply the same policy at registration, change, sign-in and recovery rather than letting each endpoint invent its own normalisation.

On the authenticated review screen, show the current and proposed addresses with distinct labels. Keep the full destination inspectable. Truncating both to the same prefix makes it hard to notice a mistaken domain or mailbox suffix. Public error pages should not reveal account details merely because someone guessed an address.

For Arabic UI, isolate embedded addresses and organisation names from surrounding instructions. W3C's bidirectional-text guidance explains tight wrapping with dir when direction is known, and dir="auto" or bdi for dynamic content. Keep display-direction markup separate from the stored identifier.

Test the confirmation email as well as the web page. A correctly rendered input is insufficient if punctuation moves in the message or the destination becomes unreadable on a phone. Provide equivalent Arabic and English explanations for pending, expired, superseded and completed changes. Switching language must not restart the security operation or alter its destination.

A release test pack for the whole handover

Use synthetic accounts and record the resulting account state, not only the success toast. The following are proposed acceptance tests, not measured results:

• Start with a valid but stale session. Require the configured fresh authentication before a pending change can proceed.
• Mistype the new mailbox. Verify that the current sign-in route remains usable under the chosen pending-update policy.
• Change the destination after receiving a link. Require the old proof to fail without affecting the replacement operation.
• Submit confirmation twice and race it against cancellation. Require one durable outcome that the user can recover after a lost response.
• Attempt the same destination from two accounts. Require collision handling without an account merge.
• Report an unexpected completed change. Verify containment and recovery without blindly reactivating an old mailbox.
• Repeat the journey in Arabic and English, including a narrow screen, keyboard navigation and the wrong account already signed in.

Product owners should approve the old-mailbox and recovery policies before rollout. Engineers should demonstrate the provider configuration, proof binding and activation behaviour. Support should be able to distinguish an undelivered message from an expired request or a completed change. Release when those teams can explain which address controls access at every stage.