Changing an account’s email address can change who receives password resets, login links, and security alerts. An email change security assessment verifies that the legitimate account holder authorizes the change and that an unconfirmed address does not gain unintended control.
Treat the email field according to its role in the product. A billing contact used only for receipts has different consequences from the address used to recover the account, even if both appear on the same settings page.
Which business functions depend on the email address?
Trace sign-in, password reset, account recovery, organization membership, and security notifications. Identify which functions use the current address and which consult a pending replacement address.
For an illustrative scheduling service, a customer can change their contact address while future appointment reminders are queued. The assessment should distinguish delivery preferences from the account’s recovery identity. Write down when each should change so the team can test a precise state transition.
What should authorize an email change?
OWASP’s authentication guidance describes reauthentication, pending changes, and confirmation or notification steps appropriate to the account’s authentication setup. Possession of an already-open browser session should not automatically settle every sensitive identity change.
For the scheduling example, define the required recent authentication and the evidence used to confirm the new destination. Decide how the process works for customers who signed in through an identity provider and do not have a local password.
How do you test the pending-change state?
Use a synthetic account and two mailboxes owned by the assessment team. Start a change without completing confirmation. Check which address receives a test reset, which address appears as verified, and whether the customer can still sign in through the intended method.
Begin a second change to a third controlled address, then revisit the first confirmation link. The application should apply its documented rule for superseded requests. Record the active pending request and final account address, rather than judging only the message displayed in the browser.
Also test expiry and replay after a completed change. Use the same account throughout so the evidence follows one comprehensible lifecycle.
What happens to old recovery links and sessions?
Create a test recovery request before the email change and examine its behavior afterward within the authorized environment. Decide whether the old request remains valid under the product’s policy and whether it could reverse the new owner’s control.
Review notification delivery to the previous address and the route for reporting an unexpected change. A notification that arrives after every recovery path has moved may still be useful, but it is not the same control as preventing the unauthorized change.
For queued reminders, verify the intended destination separately. Avoid treating a delayed informational email as proof that account recovery is still attached to the old address.
How should support-assisted changes be assessed?
Rehearse the procedure with designated staff and a synthetic account. Record the proof required, the staff role permitted to make the change, and the audit event. Do not ask staff to bypass the policy on a real customer account.
Check that the support route produces the intended pending or completed state and notifications. A secure self-service screen leaves a gap if a separate staff interface silently skips the same business requirement.
For a Ceron assessment, the deliverable should include the state sequence, tested recovery behavior, and retest of the corrected path. Password reset reviews and support impersonation controls cover related account powers. The scheduling service is illustrative.
