Your account
HOL-D101Story implementation: In progress

Change my password

account · Proposed launch phase 1

Start from Home

Review as Registered user

User story

As a registered member, I want to change my password while signed in so I can keep control of my account.

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.
  • Open Account security → Change password for my own signed-in account. Forgotten-password reset remains D086 and sign-in email changes remain D087.
  • Require recent authentication/current credentials and any required existing MFA; enforce the already selected password policy using the local managed provider.
  • Handle wrong current password, invalid new password, stale/expired authentication, cancel/retry and success without retaining secrets in app storage or logs.
  • After change, prove the new password signs in and the old one fails. Apply and verify the selected session-revocation behavior through D102; clearly report its actual effective result.
  • Keep account ID, public/professional identity, org access, saved data and membership unchanged. Organization ownership grants no authority to change another person’s password.
  • The shared Sign-in & security section links this existing password-change outcome with the same provider recent-auth and peer-session semantics. A profile save is not a credential change; navigation preserves current identity/Home.

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 account/workspace menu → Account security. The feature starts at Confirm it’s you. and Change password on that same page.

Feature checks start here

Change my password

Connected in dev; full acceptance remains In progress. The password form uses real reauthentication, manual email-code entry and separate password-change/other-device results. Backend positives pass; credential-entry handoff and the provider current-password enforcement gap remain open.

  1. 03At Account security the tester confirms Current password with Confirm current password, then enters New password and Confirm new password under Change password.
  2. 04If requested use Request an email security code, find the actual local message and enter Email security code · if requested. Select Update password; read password-change and other-session results separately.
  3. 05The tester must perform credential entry/submission. Afterwards verify new-password sign-in, old-password rejection and retained personal/workspace data with a dedicated account. The known provider current-password enforcement limit is not passed by inspecting the form.

Backend work for this feature

Backend development authorized · Dev only

What needs to be supported

  • Use the provider’s signed-in password update with current-owner/recent-auth and enabled/required-factor checks. Do not mix this with forgotten-password recovery.
  • Enforce the selected password policy and neutral failure states at the trusted boundary; never persist plaintext passwords or credential hashes in public/application data.
  • Prove new credentials work, old credentials fail and other-account requests cannot change them. Apply the explicit D102 session handling and report verified revocation behavior.
  • Connect the ordinary dev password-change form to the actual local backend; remove synthetic-success controls after replacement passes.

How to verify in dev

  1. In the ordinary dev UI, reject wrong current password, stale auth, invalid new password and missing required MFA; then perform a real update and test old/new credentials independently.
  2. Test another user attempting the update and inspect D102 effects in a second real session, with unchanged account/profile/org/staff state.

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