Your account

User story

As a registered user, I want to add and manage a second sign-in factor so access to my account and assigned work has the required protection.

Draft requirements for review · Updated 2026-10-19

What the app should do

  • For this Registered user review, MFA enrollment is optional for the base account; professional status or paid membership does not make this a staff account.
  • Offer authenticator-app MFA to customers and require it before privileged Moderator, Editor, Commercial or Platform-administrator work. Professional identity alone is not a staff responsibility.
  • Provide setup, code confirmation, sign-in challenge, invalid/expired code, cancellation, reauthentication and lost-factor recovery states using actual local provider factors for synthetic accounts.
  • Enrollment is not complete until a valid challenge is confirmed; a client flag, email verification or role preview cannot satisfy MFA. Backend enforcement must check authenticated assurance and trusted current assignment on every protected operation.
  • Require recent authentication and the existing factor for normal replacement/removal. A privileged account cannot disable MFA and continue privileged work; lost-factor cases use reviewed D080 recovery without an automatic bypass.
  • Protect enrollment secrets and any provider-supported recovery material. Do not invent a working backup-code mechanism unsupported by the chosen provider; the local demo can show a clearly labeled support recovery state.
  • The shared Sign-in & security section links this existing MFA outcome without weakening factor/real-staff requirements. Dummy Home pass-through remains distinct from protected operations; editor/navigation work never creates or removes factors.

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. Under Two-step verification select Connect authenticator. The feature starts at Protect your account.; a staff-entry challenge may open this screen directly.

Feature checks start here

Protect my account with two-step verification

Connected in dev; full acceptance remains In progress. Real authenticator setup/challenge/removal screens replace synthetic controls, and protected staff operations require genuine MFA. Dummy Home review skips setup and is not factor-verification evidence. Provider checks pass; real tester factor changes require tester handoff.

  1. 03Review Protect your account., Connect authenticator, Cannot access your authenticator? and Return to my account. Enrollment changes a real local credential; the tester completes authenticator setup and code entry themselves.
  2. 04For an enrolled test account sign out/in and complete its actual second-factor challenge, then open the permitted protected workspace.
  3. 05Protected staff-operation MFA cannot be skipped by selecting a demo role; the dedicated dummy Home-review exception conveys no such permission. Cancellation, factor removal, expired/revoked assurance and lost-factor support require dedicated review setup; no synthetic factor-completion button exists.

Backend work for this feature

Backend development authorized · Dev only

What needs to be supported

  • Use provider-managed MFA enrollment/challenge/unenrollment and assurance claims; keep secrets private and validate the current user and factor ownership server-side.
  • Combine trusted scoped staff assignments from D103 with required assurance on protected database/server actions. An assigned role without MFA is insufficient; MFA without assignment is insufficient.
  • Deny self-assignment, forged role/AAL claims, cross-scope operation, expired/revoked factor and client-only enrollment. Audit factor/assignment decisions without secret values.
  • Define supported replacement/lost-factor recovery with D080 and provider capabilities. A local bootstrap uses synthetic fixtures in an isolated environment, not a public staff-grant endpoint.

How to verify in dev

  1. Test optional member and mandatory staff variants using separate password-only and MFA-verified sessions; reject direct privileged operations below the required assurance.
  2. Test user/factor/assignment ownership, scope boundaries, revocation and lost-factor cases; prove no self-grant or recovery bypass.

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 only fictional account fixtures and dummy credentials. No real password, factor secret, card or recipient data in the frontend review.
  • UI2 owns frontend; HOL - Backend owns local schema/auth/API/policy/tests. Hosted migrations, public enrollment, outgoing email/payment and deployment remain outside this authorization.
  • HOL-D057 · HOL-D057

    Reviewed local environment/migrations and isolated synthetic fixtures; hosted promotion remains separate.

Connected stories