Your account
HOL-D087Story implementation: In progress

Change my sign-in email

account · Proposed launch phase 1

Start from Home

Review as Registered user

User story

As a registered member, I want to change my sign-in email so I can keep account access at my current address.

Draft requirements for review · Updated 2026-10-19

What the app should do

  • Use my own Member account security; professional/org context does not create another login. Optional MFA must be satisfied when enabled.
  • Change my own sign-in email only. Password changes are D101, sessions/devices D102 and forgotten-password recovery D086.
  • Require current-owner recent authentication and required/enabled MFA; verify the replacement address using genuine local captured provider messages.
  • Show pending, invalid/expired/reused, cancellation, stale/concurrent and confirmed outcomes. Keep the old usable sign-in identity until confirmation is complete.
  • Preserve account ID, saved data, membership and professional/org/staff assignments. Account email is independent of public profile names and organization contact fields.
  • Connect the normal dev form to the actual local backend; remove fake email-change/verification responses after successful connected acceptance.
  • The Sign-in & security settings section links this existing email-change outcome for the same account. Navigation alone changes neither selected Home nor provider recent-auth/confirmation policy; existing security limitations stay explicit.

What to check in the demo

Follow these steps from the role’s landing page through navigation and feature checks.

Review asStart here: Home

Begin on the free Member Home. For a local example use Sign in → Try a demo account → Alex Morgan → Open account, then choose Member in the account/workspace menu if a remembered workspace opens. This is a genuine local account; no paid access is supplied.

Navigation from sign-in

  1. 01Open the fictional Registered user account through the connected sign-in service. Seeded Home review opens directly. Real HOL staff access and protected actions require an authenticator check.
  2. 02From the account’s Home open the account/workspace menu → Account security. The feature starts at Confirm it’s you. and the Change email section; these are sections on one page.

Feature checks start here

Change my sign-in email

Connected in dev; full acceptance remains In progress. The actual email-change form and current-password reauthentication are connected. Both addresses confirm through the provider; browser handoff/pending-state checks and the known recent-authentication provider limit remain open.

  1. 03On Account security confirm the current password under Confirm it’s you. and use Confirm current password. The tester performs credential entry and any required authenticator check.
  2. 04Under Change email enter the new fictional address and choose Request email change. Keep using the current email until the actual provider confirmations for both addresses are completed.
  3. 05Compare retained profile, saved work, membership and workspace access after the tester completes the change. Pending/expired/cancelled cases and the known provider recent-authentication limit remain open checks.

Backend work for this feature

Backend development authorized · Dev only

What needs to be supported

  • Use provider-managed sign-in email change for the authenticated owner; require recent authentication and existing required MFA. Public display name and organization contact email remain separate.
  • Verify the replacement address, use the supported current/new-address confirmation messages through local email capture, and handle pending/expired/reused/cancelled/concurrent transitions. Preserve the old usable identity until provider confirmation conditions are met.
  • Keep stable account ID, membership, profile, professional labels and organization/staff assignments. Never derive new grants or public profile names from the changed email; retain safe event audit without secrets.
  • Use the actual local adapter in the normal dev app; remove fake success/email-verification controls for this outcome after connected checks pass.

How to verify in dev

  1. Start an email change on two synthetic sessions; inspect real local captured confirmations, expire/replay/cancel links and verify stable account identity and safe pending behavior.
  2. Test stale authentication, wrong required factor and another-account request; prove old/new sign-in behavior and no new entitlements after the confirmed change.

Before this can work

  • Begin on the free Member Home. For a local example use Sign in → Try a demo account → Alex Morgan → Open account, then choose Member in the account/workspace menu if a remembered workspace opens. This is a genuine local account; no paid access is supplied.
  • Use my own verified local synthetic account and its currently assigned scope; satisfy required MFA without a preview bypass.
  • Use your own dedicated local test account with known credentials for password-entry/change checks. The pass-through demo chooser does not reveal or supply the seeded account password.

Connected stories