HealthOS Multi-Factor Authentication Use Cases

This page describes the planned public multi-factor authentication use-case documentation for MVS HealthOS v1.0.0. It is published as a pre-attestation transparency page while native MFA UI exposure and login challenge behavior are present in source but still require runtime evidence capture and Product/Legal/Compliance approval.

This page must not be read as a certification, compliance, mandatory-MFA, or WCAG conformance statement. Final public copy will be approved only after the v1.0.0 evidence package proves the implemented behavior.

Product and Scope

• Product: MVS HealthOS.
• Version: v1.0.0.
• Primary d(13) path: native HealthOS TOTP through Better Auth.
• Supplemental path: MVS-controlled identity provider MFA, such as an approved Okta policy, only if selected and proven for the claimed HealthOS user population.
• Excluded from MVS d(13): DoseSpot MFA and EPCS workflows. DoseSpot is outside the MVS d(13) evidence boundary because DoseSpot is pursuing its own Drummond certification.
• Current enforcement posture: optional and self-service unless mandatory tenant, organization, or identity-provider enforcement is later built, configured, and proven.

Supported Use Cases Under Review

Native TOTP Authenticator App

HealthOS is being remediated to use Better Auth TOTP as the primary native MFA path. The intended user flow is:

1. A credential user signs in to HealthOS.
2. The user opens account security settings.
3. The user starts two-factor setup and confirms their password.
4. HealthOS displays a QR code or manual secret for an authenticator app.
5. The user submits a current one-time code.
6. HealthOS records the user as MFA-enabled.
7. On a later password sign-in, the user is challenged for a TOTP code before app access.

Evidence still needed before final copy approval:

• Native HealthOS account UI showing the TOTP enrollment control.
• Successful enrollment from a disposable fake-tenant user.
• Login challenge before app access for an enrolled user.
• Invalid-code rejection.
• Redacted database proof of MFA-enabled state and factor record shape.
• Log or audit evidence for MFA enrollment, challenge, invalid-code, success, and disable events, or an approved gap statement.

MVS-Controlled IdP MFA

An MVS-controlled identity provider can supplement the native HealthOS TOTP path only when MVS proves the configured MFA policy, assigned user population, login flow, and logs for the documented HealthOS boundary. Source configuration alone is not enough.

This page does not currently claim that an IdP path is the primary d(13) evidence path.

Passkeys and WebAuthn

Passkeys/WebAuthn are not included in the current d(13) claim on this page. They may be documented later only if Product/Security intentionally includes them and runtime evidence proves registration, login, recovery, and storage behavior for the documented HealthOS scope.

Current Enforcement Statement

The native HealthOS TOTP path is currently documented as optional and self-service. Source now mounts the UI path, but a fake-tenant runtime test must still prove that users can enroll MFA for their own account.

This page does not state that MFA is mandatory for all HealthOS users. Mandatory enforcement would require additional implemented behavior or an IdP policy, plus runtime evidence that users cannot bypass the requirement.

Authentication and Authorization Notes

MFA augments primary credential authentication. The intended sign-in flow for an enrolled user is password authentication followed by a TOTP challenge before the user reaches protected HealthOS app routes.

The final evidence package must prove:

• An unenrolled disposable user can reach the enrollment control.
• An enrolled disposable user is challenged before protected app access.
• An invalid code is rejected without granting app access.
• A valid code completes the sign-in flow.
• Disable or recovery behavior requires an approved authentication step and does not expose secrets in retained evidence.

Recovery Notes

Backup-code and account-recovery behavior remains pending final implementation evidence. Final public copy will state only behavior that has been proven in HealthOS v1.0.0.

Evidence still needed:

• Whether Better Auth backup codes are generated and exposed in the HealthOS UI.
• Whether backup codes can be used for recovery.
• How backup codes or support recovery are stored, displayed, redacted, and audited.
• How support-assisted recovery is approved, if support recovery is part of the final behavior.

Relied-Upon Software Notes

Expected relied-upon software for the native path includes Better Auth for TOTP generation, verification, and MFA state management. If an MVS-controlled IdP path is included later, that IdP and its policy evidence must also be listed in the final RUS worksheet.

DoseSpot is not relied upon for MVS d(13) evidence.

The final RUS list is an external Product/Legal/Compliance approval item. This page does not finalize RUS scope.

Evidence and Update Process

This page will be updated when the v1.0.0 evidence package has:

• Screenshots or video of native HealthOS TOTP enrollment using a disposable fake-tenant user.
• Screenshots or video of sign-in challenge, invalid-code rejection, and successful verification.
• Redacted database proof showing MFA-enabled state and factor records without exposing secrets.
• Log or audit evidence for MFA events, or an approved gap statement.
• Final decision on whether passkeys, platform-admin MFA, or IdP MFA are included, supplemental, or out of scope.
• Product/Legal/Compliance approval of final public wording.

Publication Status

Status: pre-attestation transparency page. Final d(13) language is pending implementation evidence and owner approval.