Multi-Factor Authentication (MFA)

Attestation: YES — the Retinex EHR product supports multi-factor authentication (MFA) and administrator-initiated MFA reset for any user.

1. Regulatory Reference

45 CFR §170.315(d)(13) — Multi-factor Authentication. The technology must support the authentication, through multiple elements, of the user’s identity with the use of industry-recognized standards.

Retinex Health attests YES to this criterion. This page is the public-facing developer documentation published with the product on the ONC Certified Health IT Product List (CHPL).

2. Summary of Support

Retinex implements MFA using Time-based One-Time Passwords (TOTP) as specified in IETF RFC 6238, with secret provisioning per RFC 4226 (HOTP) and the otpauth:// URI format documented by the Google Authenticator project. TOTP is an industry-recognized standard and is interoperable with any RFC 6238-compliant authenticator app (Google Authenticator, Microsoft Authenticator, Authy, 1Password, Duo Mobile, etc.).

MFA is supported for every user account in the product, regardless of role. Administrators can reset a user’s MFA enrollment from the User Management admin panel without engaging the developer or support staff.

3. Authentication Factors

Successful sign-in requires both factors. A valid password alone does not establish an authenticated session — the server marks the session mfaVerified = false until the TOTP code is verified, and all protected API routes reject requests that do not carry an MFA-verified session.

4. Standards and Algorithms

5. End-User Enrollment Flow

1. The user signs in with email and password.
2. If the account has no enrolled MFA secret, the user is presented with the MFA setup screen.
3. The server generates a fresh 160-bit Base32 secret, persists it to the user record, and returns an otpauth:// QR code.
4. The user scans the QR code with any RFC 6238 authenticator app.
5. The user enters the 6-digit code shown by the app. The server verifies it against the stored secret (±30 s window).
6. On successful verification, the server sets mfaEnabled = true on the user record and marks the session mfaVerified = true.
7. On every subsequent sign-in, the user is required to enter a fresh 6-digit code after the password step before any protected resource is accessible.

6. Administrator-Initiated MFA Reset

A user may lose access to their authenticator app (lost or replaced phone, app uninstalled, factory reset, etc.). Retinex provides an in-product admin workflow so that an authorized administrator can clear the user’s MFA enrollment and force re-enrollment on the next sign-in — for any user in the organization.

Who can perform the reset

Reset is restricted by RBAC to users holding the admin role (or any role granted the users:reset-mfa permission). The action is gated by the standard JWT guard and the admin-controller authorization check. Non-admin users do not see the Reset MFA control in the UI and receive 403 Forbidden if they call the underlying API directly.

Admin panel — step-by-step

1. Sign in to Retinex as an administrator (password + MFA).
2. Open User Management from the main navigation.
3. Locate the user with the search bar (first name, last name, or email) or from the personnel list.
4. Click the user row to open the Edit User screen.
5. In the Security actions section, click Reset MFA.
6. Confirm the action. The admin panel displays a success toast: “MFA reset — user will re-enroll on next login.”
7. The user’s mfaSecret is cleared and mfaEnabled is set to false. The existing authenticator entry for Retinex stops working immediately.
8. On next sign-in, the user is routed to the MFA setup screen and must enroll a new authenticator before they can access any protected resource.

Why self-service reset is intentionally not offered

Allowing a user to reset their own second factor using only the first factor (password) would collapse MFA back to single-factor authentication. Reset is therefore an out-of-band action performed by a trusted administrator after the user’s identity has been re-established through the organization’s normal help-desk procedures (phone call to a known number, in-person visit, or verified email exchange).

7. Audit Logging

Every MFA-related event is recorded by the audit microservice with actor user ID, target user ID (when different), source IP, user agent, timestamp, and outcome:

• MFA setup initiated / completed
• MFA verification success / failure (including invalid-code attempts)
• Administrator MFA reset (logged at WARN on the auth service and as a privileged-action audit record)
• Administrator password reset
• Account enable / disable (lock / unlock)

Audit records are immutable, append-only, and retrievable through the audit microservice for the organization’s compliance reviews.

8. Coverage

There are no user populations within Retinex that are exempt from MFA. Any human user with a Retinex account uses the flows described above.

9. Limitations / Out of Scope

• Patient-facing portal accounts are administered separately from clinician accounts and are out of scope for §170.315(d)(13), which addresses the certified Health IT product’s user authentication.
• SMS/email-delivered one-time codes are not used as a second factor, consistent with NIST SP 800-63B guidance discouraging SMS as a restricted authenticator.
• Hardware-token (FIDO2 / WebAuthn) enrollment is on the roadmap but is not required for §170.315(d)(13) attestation; TOTP satisfies the criterion.

10. MFA Use Cases

The scenarios below describe how MFA is actually exercised by users and administrators across the product. They are the developer-supplied use cases referenced by Retinex’s “YES” attestation to §170.315(d)(13). The two-factor model and standards are described in §3 Authentication Factors and §4 Standards and Algorithms; out-of-scope items are listed in §9 Limitations.

11. Change Log

Support

For questions about Retinex Health’s MFA implementation or technical support requests, contact support@retinex.ai.