Security controls
Sign-in, MFA and sessions
How staff sign in and how sessions are protected.
How to read status labels: In the pilot (v0.2.0, synthetic data) Simulated in the pilot Coming (Wave 2, rolling out) Designed, not yet built Open decision Not offered / no claim made Planned partner integration
C0112How do staff sign in to the pilot?
With a username and password. Passwords must be at least 12 characters (14 in the hospital preset), are checked against common-password and name lists, and must be changed at first sign-in. Privileged tiers also need a time-based one-time code.
C0113Is multi-factor authentication available?
Yes in the pilot: TOTP codes with recovery codes, on by default for privileged tiers T7, T8 and T9, with replay protection. Hardware-key and badge sign-in are designed, not built.
C0114Will hardware security keys be supported?
The design specifies phishing-resistant sign-in with a badge plus FIDO2 key touch, and no SMS or voice codes. WebAuthn is not built in the pilot.
C0115What happens after repeated wrong passwords?
The account locks after five failures in the pilot and a security alert is raised. Error messages are generic so usernames cannot be probed.
C0116Does the screen lock when a clinician walks away?
The pilot has an idle and manual lock screen. Timing values are configurable within floors. Badge-out locking is designed for the sealed terminal.
C0117Can a user see and end their sessions?
Yes: the pilot lists active sessions and lets users revoke them, and logout revokes the session on the server.
C0118Can two people share one login?
The design prevents it with one session per identity bound to terminal, badge and user, since shared credentials are a known habit in clinics.
C0119How are temporary passwords handled?
An administrator reset issues a one-time temporary password shown once, and the user must change it at first login.
C0120How are passwords stored?
Hashed with PBKDF2-SHA256 at 100,000 iterations in the pilot. The design target is Argon2id with a hardware-held pepper, which is an open item.
C0121Is there a breached-password check?
Not in the pilot. A local common-password list exists. An outbound breach check needs a network policy decision and is open.
C0122Is single sign-on available?
SSO is specified for the production design. The pilot does not offer it.
C0123How are session tokens protected?
Sessions use random 256-bit tokens stored as hashes on the server, expiring after a fixed period and revocable. Tokens sit in browser session storage, which the review lists as an accepted low risk.
C0124What happens to access when an employee leaves?
The design has expiring role assignments, recertification and revocation with audit. The pilot lets administrators disable a user immediately.
C0125Can privileged users be created by one administrator alone?
No. Creating or changing privileged roles needs two-person approval in the pilot.
C0126How are service accounts protected?
By certificate-based service identities with short lifetimes and narrow scopes; no human login. Designed, not built.