Why open source MFA for healthcare needs a clinical-first design
Health providers and business associates with shared clinical workstations, remote EHR access and dozens of vendor logins face pressure to add MFA without slowing patient care. Self-hosted MFA on privacyIDEA or Keycloak can cover these paths from inside the organization's own network, so authentication decisions, token records and audit logs stay under local control. The design question is not whether to add a second factor, but which login paths get it first and how a clinician re-authenticates in seconds during a shift. The current HIPAA Security Rule sets no MFA mandate. The January 2025 proposed rule would add one, but it was not final as of October 2026, so confirm its status before you cite it in a board paper. The obligation that applies today is narrower: unique user identification and person or entity authentication under 45 CFR 164.312, which requires procedures to verify that a person seeking access to ePHI is the one claimed. Enforcement is already concrete. OCR's Warby Parker penalty followed credential stuffing against customer accounts, and France's CNIL fined a hospital EUR 500,000 in September 2026 after finding external access to its patient record system lacked VPN and multi-factor authentication. Both cases point to remote and password-only paths as the first place to close. For most healthcare designs, privacyIDEA fits best where token variety and clinical workstation integrations matter, since it covers hardware tokens, smartcards, push and OTP, a PAM module for Linux, a Windows credential provider and RADIUS for VPNs. Keycloak fits where federation and single sign-on sit in front of the EHR and other web applications, reading identities from Active Directory through LDAP federation. Many hospitals will use both: Keycloak as the broker and privacyIDEA as the second-factor engine. Ask your EHR vendor which login flows it supports for federated sign-on and whether shared workstation sessions can be locked and resumed without a full re-enrollment.
Which HIPAA and related requirements shape the MFA design
This table maps each HIPAA Security Rule provision and related regulation to what it means for a self-hosted MFA build in a hospital network. Read each row as a design input: the requirement, what it asks for, and the design decision it forces. The main takeaway is that shared workstations and emergency access must be designed on purpose, because the rule requires both and no current standard lets MFA be skipped quietly.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| 45 CFR 164.312(d), person or entity authentication | Procedures to verify that a person or entity seeking access to ePHI is the one claimed | Every clinical and vendor login to EHR or ePHI systems needs a verifiable second factor or equivalent proof, with the verification method documented |
| 45 CFR 164.312(a)(2)(i), unique user identification | A required implementation specification that assigns each user a unique name or number | Shared clinical workstations need per-user identities with MFA tied to the individual, not to a generic ward login |
| 45 CFR 164.312(a)(2)(ii), emergency access procedure | A required procedure for obtaining necessary ePHI during an emergency | Break-glass accounts must work when the MFA server is unreachable, and their use must be logged, reviewed and tested before go-live |
| 45 CFR 164.308(a)(5)(ii)(D), password management | Current rule sets no minimum password length, complexity or change interval | Password rules cannot replace MFA under the current text, but the January 2025 proposed rule would require MFA; confirm the final rule status before design freeze |
| 45 CFR 164.314(a), business associate flow-down | Business associate contracts must require Security Rule compliance and incident reporting, and flow the same terms to subcontractors handling ePHI | Vendor remote logins and any hosted MFA or support provider need contract terms covering MFA, logs and incident notice |
| 45 CFR 164.312(b), audit controls | Hardware, software and procedural mechanisms that record and examine activity in systems with ePHI | Log every MFA success, failure, enrollment and token change, and forward them to the monitoring platform for review |
| NIS2 Annex I, health sector | Lists healthcare providers and medical device manufacturers among high-criticality sectors for EU operations | EU hospital and vendor networks should confirm national transposition duties and which MFA and logging controls the regulator will expect |
| GDPR Articles 32 and 34, security and breach notice | Appropriate technical measures for security of processing, and notice to affected persons after certain breaches | The CNIL fine on a French hospital cited missing VPN and MFA for external access and access control ignoring the care team's need to know; scope MFA to those paths first |
How clinical workflows change token and login choices
Clinicians on shared workstations sign in and out many times per shift, often with badges or tap-to-sign-in devices, so the second factor must not add friction at every handoff. Authentication must still identify the person behind each session, which is why unique user identification matters as much as the factor itself.
- Token choice: Confirm whether badge logons can be combined with a privacyIDEA token, and whether smartcard or PIV-style credentials are already issued to clinical staff. privacyIDEA supports PIV and x509 smartcards and FIDO2 keys, but the Windows credential provider and badge reader must be tested together.
- Push versus OTP: Push notifications need the privacyIDEA Authenticator app on a phone, which many clinicians may not carry on the floor. Standard TOTP and HOTP work with apps such as Google Authenticator, so an OTP fallback is usually required.
- Offline behavior: Decide what happens when a laptop or workstation cannot reach the MFA server. Offline logon design is a separate decision and should be settled before rollout.
- Enrollment: Plan enrollment at the shift level, not one user at a time, and confirm how tokens are issued and revoked when staff change roles.
Confirm with the EHR vendor which client applications support session reuse, how a second sign-in is treated when a session is already open, and whether the EHR accepts MFA results passed from an external identity provider.
Remote access to an EHR from home, a satellite clinic or a physician's own network is the environment the CNIL case in Europe focused on, where external access lacked VPN and multi-factor authentication. Here the second factor protects a network path and an application login at the same time, so the choice of integration point matters.
- Integration point: privacyIDEA covers VPNs through RADIUS and web applications through its REST API, while Keycloak can front browser-based EHR portals through OpenID Connect or SAML 2.0. Choose one primary path per application rather than stacking both on the same login.
- Token type: Push is convenient for remote staff with phones, but OTP through a standard authenticator app avoids dependence on a specific app. FIDO2 keys and passkeys are supported by privacyIDEA and Keycloak and suit staff who need a phishing-resistant option.
- Fallback: Remote staff need a documented path when a phone is lost or a key is forgotten. Define who can reset a token and how identity is verified before a reset.
- Logging: Keep MFA events alongside VPN and EHR session logs so access can be reconstructed for a given clinician and time.
Confirm with the EHR vendor whether it supports remote access through a published gateway, which session timeout applies, and how it handles a re-prompt after an MFA challenge.
Vendors, device maintainers and contractors often need access to clinical systems but are not workforce members in the directory. The MFA design has to reach identities outside the hospital's main store while keeping accountability clear, so each external account needs its own identity and token.
- User stores: privacyIDEA can read users from LDAP, SQL, SCIM and HTTP resolvers, so external identities can be kept in a separate store with its own enrollment rules. Keycloak can federate LDAP and Active Directory and broker external identity providers.
- Token type: Vendors often work from managed or unmanaged laptops, so OTP through a standard app or a hardware token that is issued and returned is usually easier to control than a phone push tied to a personal device.
- Token lifecycle: Define an expiry date for every vendor token and a process for revocation when a contract ends. Imported hardware seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats can support token issuance when hardware is supplied.
- Separation: Keep vendor accounts in a distinct realm or resolver so policies and reporting can differ from workforce accounts.
Confirm with each vendor whether its remote support tool supports a second factor at the point of login, and whether it needs a service account that cannot use MFA. Business associate terms under 45 CFR 164.314 should cover how vendors handle security incidents.
Emergency access is the scenario where the MFA service itself may be unavailable, and where a poor design locks clinicians out during care. The Security Rule requires an emergency access procedure as a required implementation specification, so the MFA design must work with that procedure rather than around it.
- Break-glass accounts: Keep a small number of emergency accounts with documented controls, monitored use and a defined review after each use. Confirm how these accounts are excluded from MFA and how their use is logged.
- High availability: Keycloak documents clustered designs that require a synchronously replicated database, and privacyIDEA deployments should be planned with redundancy. Availability targets should be stated in the contract, not assumed.
- Offline options: Decide in advance whether cached logons, hardware OTP tokens that work without a network path, or FIDO2 keys verified locally are acceptable for downtime. Each option changes what is logged and what can be verified later.
- Testing: Rehearse the downtime path with clinical leads before go-live.
Confirm with the EHR vendor how it behaves when the identity provider is unreachable, whether it supports a local emergency login, and how it records that login for later review.
Which open source platforms fit hospital MFA and why
Hospital MFA usually has to cover shared workstations, remote EHR access and vendor logins at once, and no single product covers every path equally well. The cards below compare the platforms by the job they do best, so the choice can follow from the access paths your clinical and vendor workflows actually use.
privacyIDEA as the MFA engine
privacyIDEA is a self-hosted MFA server that covers the widest set of second factors in this group, including FIDO2 and WebAuthn, PIV and x509 smartcards, push, TOTP and HOTP. It integrates with a PAM module for Linux, a Windows credential provider, RADIUS for VPNs and a REST API for web applications, so one policy can cover several entry points. Check how each integration behaves when the server is unreachable, since clinical workstations cannot wait on a timeout. It is licensed under AGPLv3 and installs with pip or on Ubuntu and RHEL-family systems.
Keycloak as the identity broker
Keycloak fits hospitals that need one login service in front of many applications, using OpenID Connect and SAML 2.0 with LDAP and Active Directory federation. It can broker identities from existing directories and can pair with privacyIDEA as an identity provider plugin, which keeps second-factor enrollment separate from application logic. Its high availability designs require a synchronously replicated database, so plan the database tier before the application tier. It is Apache-2.0 licensed and supports PostgreSQL 14 to 18 among other production databases.
Operator upgrade control in Keycloak
Running Keycloak on Kubernetes through its Operator gives you declarative realms and clients, but clinical systems need planned change windows. The Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Also decide whether database schema migration runs automatically at startup or is applied by your database team as SQL, since the upgrade guide suggests manual migration for large deployments. Confirm both settings with your change board before go-live.
ZITADEL for passkey-first logins
ZITADEL lists SSO, MFA, passkeys through FIDO2 and WebAuthn, SAML 2.0, SCIM and multi-tenancy in its README, which makes it worth evaluating where a hospital wants passkeys for clinicians and a multi-tenant model for affiliated groups or contractors. It is licensed under AGPL-3.0. Confirm its fit against your existing directories, its clinical workstation login path and its support model before treating it as a peer to Keycloak. Ask a partner to test it against your device and badge flows.
authentik and FreeIPA for specific cases
authentik is MIT licensed except its enterprise directory, so confirm which features your hospital would need from that separate license. FreeIPA is a fit where the directory itself is the core of the design, especially for Linux identity and OTP on servers, and it can sit beside privacyIDEA rather than replace it. Neither is a default choice for hospital MFA, so evaluate them against a written list of workflows rather than a general preference. Ask which features are in each edition before scoping.
Ory for custom application flows
Ory Kratos handles identity and user management, and Ory Hydra provides an OAuth 2.0 and OpenID Connect server, both under Apache-2.0. They suit a hospital that is building its own patient or partner portal and wants to control every login screen and flow in code. For staff access to a commercial EHR or vendor portal, a packaged server with built-in second factors is usually the simpler path. Plan the engineering effort for any custom flows as an ongoing cost, not a one-time task.
Deployment patterns for hospital networks
Hospital MFA sits between clinical workstations, VPN concentrators and directories, so a failure in the MFA tier can stop care. The cards below cover where the MFA nodes sit, how they stay available, what happens when they are unreachable, how identity sources connect, and how vendor access is kept apart from workforce access.
Place MFA nodes in a segmented zone
Run privacyIDEA or Keycloak nodes in a dedicated server zone that workstations, VPN concentrators and the directory can reach on the required ports, and nothing else can reach. Keep the admin interface on a separate management network. Document every flow the MFA tier needs, including RADIUS or OIDC callbacks, so network teams can confirm each rule before go-live. Ask the platform owner which ports and protocols each integration uses.
Use Keycloak multi-cluster designs
Keycloak documents a single cluster that can span availability zones and a multi-cluster design (v2) that does not need an external Infinispan cluster. Both supported designs require a synchronously replicated database, so the database tier usually drives the cost and the failover plan. Confirm with your architect how a site loss is handled and how often failover is tested. The deprecated v1 design should not be chosen for new builds.
Plan fallback when MFA is unreachable
Decide before go-live what a clinician sees if the MFA service or RADIUS path is down. Options include a second MFA node on a different network path, cached offline logons for workstations, and a break-glass procedure with named approvers and logging. Each option carries a security trade-off that the CISO and clinical leads should sign off. Test the fallback path during a planned change window, not during an incident.
Connect to hospital directories
privacyIDEA reads users through LDAP and Active Directory resolvers, and Keycloak supports LDAP and Active Directory user federation. Map which directory is the source of truth for clinical staff, contractors and service accounts, and confirm how disabled or departed users are reflected in the MFA tier. Use read-only bind accounts with the least rights needed. Check how directory outages affect logins before relying on a cached copy.
Separate vendor access paths
Vendor logins to EHR and medical device support tools should not share the workforce VPN path or the same policy set. Give vendors their own realm or client, separate enrollment, time-bound accounts and session logging. Confirm how the business associate contract covers vendor MFA and incident reporting. Review vendor access paths on a fixed schedule, since these accounts are often the least monitored.
How a hospital rollout moves from pilot to clinical coverage
The sequence starts with mapping login paths and clinical workflows, proves the MFA platform on administrative and remote access, and only then reaches shared clinical workstations and vendor accounts. Each phase closes with a written output that clinical and security leads approve. The timing depends on the scope of each phase and should be agreed in writing before work starts.
Map login paths and clinical workflows
Clinical leads, security leads and the identity team inventory every place a person signs in: EHR access from inside the network, remote access, email, administrative consoles, shared workstations, badge or kiosk logins and vendor portals. For each path, they record the user population, the clinical task it supports and the time-critical steps that a second factor could interrupt. The output is a signed login inventory with a proposed coverage order and a list of workflows that need special handling, such as emergency access. The step is done when clinical and security leads agree the inventory in writing.
Pilot MFA on administrative and remote access
The team deploys the MFA platform, such as privacyIDEA or Keycloak, in a non-production environment, connects it to the directory and then enables it for a small group of administrative accounts and remote access users. Token types are tested against the hospital's approved authenticator options, and failover behavior is tested by simulating an MFA service outage. The output is a pilot report covering enrollment success, failed logins, help desk tickets and audit log completeness. The step closes when the pilot report is reviewed and the go or hold decision is recorded.
Prepare enrollment and help desk operations
Before wider rollout, the team writes enrollment procedures, identity verification steps for token issuance, recovery and lost-token processes, and scripts for common help desk cases. Help desk staff run through these procedures in a training session, and a break-glass path for emergency access is documented and tested. The output is an approved runbook and a set of support materials that clinical managers can share with staff. The step is complete when the help desk has handled test cases from start to finish without escalation to engineering.
Roll out shared clinical workstation access
The team applies the MFA policy to clinical workstations in staged groups, starting with units where login paths are well understood. Re-authentication rules are tuned with clinical leads, including how long a session stays active after a badge tap or a short lock, and where a second factor is required for each application. Logs are reviewed for login delays, repeated prompts and lockouts after each group. The output is a tuned policy per unit and a record of changes approved by clinical leads. The step is complete when each group runs for a stable period without unresolved clinical complaints.
Extend coverage to vendor and business associate access
The team inventories vendor accounts that reach clinical or administrative systems, including remote support, device maintenance and billing partners. Each account is either moved behind MFA, routed through a controlled access path, or documented with a reason and a compensating control. Business associate agreements are checked to confirm that vendors must comply with the Security Rule and report security incidents, as required by 45 CFR 164.314(a)(2)(i). The output is a vendor access register with MFA status and owner for each account. The step is complete when every vendor account has a recorded status approved by the security lead.
Report, review and tune coverage
Once coverage reaches clinical and vendor paths, the team sets up recurring reports for enrollment rates, failed and successful authentications, unusual access patterns and audit log retention. Access and MFA configuration are reviewed on a schedule agreed with the hospital, and changes go through the same approval path as the initial rollout. The output is a reporting pack and a review calendar that the compliance and security leads own. The step closes when the first review cycle is complete and its findings are logged with owners and due dates.
Evidence auditors and regulators ask for from MFA logs and configuration
This table maps each evidence type an assessor is likely to request for a healthcare MFA deployment to the component that produces it. Use it to plan log retention and configuration exports before an audit, not after. DeployOpen prepares this evidence for your review, but it does not issue attestations, and HIPAA has no certification that an entity can obtain.
| Evidence | What it shows | Produced by |
|---|---|---|
| Unique user identification records | Each workforce member maps to one account, with no shared logins on clinical workstations or EHR sessions | Directory or user store (Active Directory, LDAP, FreeIPA) and privacyIDEA user ID resolver configuration |
| Authentication and MFA enrollment records | Which token types each user registered, when, and who approved any recovery or token replacement | privacyIDEA token database and enrollment audit entries, or Keycloak credential and event records |
| Audit logs of authentication events | Successful and failed logins, MFA challenges, lockouts and access to ePHI systems, with timestamps and user IDs | privacyIDEA audit log, Keycloak event logs, and forwarding to a SIEM such as Wazuh for review |
| Emergency access and automatic logoff settings | Break-glass account procedure and session timeout values for shared or kiosk workstations | Keycloak or PAM realm and client session settings, Windows or Linux logon policy exports |
| Risk analysis inputs covering authentication | Which login paths reach ePHI, which lack MFA, and how each gap was ranked and tracked | Organization's risk analysis register, populated from directory, VPN and EHR access configuration exports |
| Business associate contract terms | Vendor logins to the EHR or other ePHI systems are covered by written terms requiring Security Rule compliance and incident reporting | Legal and procurement records under 45 CFR 164.314, maintained by the covered entity, not by the MFA software |
| Configuration baselines and change records | The approved state of MFA servers, policies and integrations, and a dated record of every change and who approved it | Version-controlled configuration, change tickets, and Keycloak Operator or deployment manifests kept under change control |
What do hospitals ask before self-hosting MFA?
What drives the cost of self-hosting MFA in a hospital?
The main cost drivers are directory size, the number of systems that need a second factor, token logistics, clinical workflow testing and high availability. Directory size and system count set the integration and enrollment effort: each VPN, Windows or Linux fleet, EHR access path and vendor login is its own configuration and test. Token logistics add hardware cost and handling if you choose hardware keys or OTP tokens. Clinical workflow testing takes time because shared workstations and login-and-logout patterns must work for staff on shifts. High availability adds servers and a synchronously replicated database if the identity store must survive a single failure. Ask any quote to itemize each of these components separately, so you can see what is one-time and what is ongoing.
Which MFA costs are one-time and which recur?
One-time costs usually include design, integration of each system, initial enrollment, clinical workflow testing and documentation. Recurring costs usually include server and database hosting, patching and upgrades, support subscriptions, help desk handling for lost or replaced tokens, and periodic access reviews. Keycloak, for example, plans four minor releases a year, so the upgrade and regression testing effort recurs even though the software is free to use. Privacyidea's Enterprise Edition is available from NetKnights if you need a commercial support tier, which is a recurring license decision. Ask the quote to separate these lines so your finance team can budget the first year and later years differently.
Can a hospital IT team run self-hosted MFA alone?
Some hospitals can, but it depends on staff time, identity skills and how many systems are in scope. A small internal team can often run a single product such as privacyIDEA or Keycloak once the design is settled, but the first deployment touches the directory, VPN, Windows logon, Linux access and EHR-facing applications at the same time. The team also needs to handle failover, upgrades and emergency access procedures, which are easy to neglect when staff are stretched. Many hospitals split the work: the internal team owns clinical and directory decisions, while a partner plans, implements, documents and supports the platform inside your own infrastructure under a written, fixed scope. DeployOpen works this way, and the division of duties should be written into the statement of work.
How long does a hospital MFA deployment take?
No duration applies to every hospital, so treat any timeline as valid only once it is written into a scope agreed before work starts. The length depends on the number of systems, the state of the user directory, how many token types are chosen and how much clinical workflow testing is required. Phased rollouts are common: remote access and vendor logins are often sequenced before shared workstation logon, because the workflows differ and carry different risk. Ask for milestones tied to specific systems, the testing each milestone requires, and which tasks depend on clinical staff availability. A timeline that does not list these dependencies is not yet a plan you can hold a partner to.
What do clinical and IT staff need to contribute?
Clinical staff need to provide workflow input, test login and re-authentication on real shift patterns, and confirm which access paths are used in patient care. IT staff need to supply directory access, network paths to the MFA servers, firewall and VPN changes, and change windows for Windows and Linux logon changes. Privacy and compliance staff should review which users, logs and access decisions are recorded, because the HIPAA Security Rule at 45 CFR 164.312 requires unique user identification, person or entity authentication and audit controls for systems containing ePHI. Agree these responsibilities in writing so that testing and sign-off do not stall the rollout.
Can shared workstations and emergency access be supported safely?
Yes, but the design must be explicit, tested and documented. Shared workstations need session-aware re-authentication so clinicians can move between devices without repeated long enrollment steps, and the rules for logoff and lock must be agreed with clinical leaders. The HIPAA Security Rule lists unique user identification and an emergency access procedure as required implementation specifications, and automatic logoff as addressable, so emergency access and logoff behavior must be designed, not left as defaults. Ask for a written break-glass procedure, the accounts that bypass MFA, how those accounts are monitored and how the procedure is tested. Confirm the exact behavior of any chosen product in your environment with the vendor before committing to the design.
Questions to ask an implementation partner before a healthcare MFA project
Start with clinical workflow testing, because a second factor that works in the lab can still fail at the bedside. Ask the partner how they will test MFA against the actual clinical paths: badge-tap or proximity login on shared workstations, handoffs between nurses on the same device, medication administration and order entry flows, and sessions that time out during a procedure. Ask who signs off on those test results, whether clinical staff from your organization will run the tests, and how many workstation models and thin-client or virtual desktop configurations are covered. Ask for the test scripts before the build starts, not after.
Next, press on shared workstation and emergency access design. Ask how the partner will handle break-glass access so that a clinician can reach a record during an emergency when the MFA server or a token is unavailable, and how that access is logged and reviewed afterward. Ask which privacyIDEA or Keycloak settings will carry the workstation policy, for example session lifetime, re-authentication intervals and what happens to a Windows or Linux logon that cannot reach the token server. Confirm that the design keeps the HIPAA unique user identification requirement intact on shared devices, and ask how they will test that a second clinician cannot inherit the first clinician's session. Ask for the exact configuration they propose to hand over, not a general description of the approach.
Finally, ask about vendor and business associate access, EHR integration experience and the support model. Vendor logins and remote access by third parties need the same second factor as staff, so ask how the partner will enrol external users, separate their identities from workforce accounts and remove them when the contract ends. Ask for named, verifiable experience integrating privacyIDEA or Keycloak with the EHR, its portal or its identity provider, and confirm specifics in writing rather than accepting general claims. Ask how upgrades to Keycloak and privacyIDEA will be handled, including the Keycloak Operator approval mode and database schema migration plan, the rollback path, and the evidence pack delivered at each change. Finally, confirm in the written scope what is out of scope, including EHR vendor changes, clinical sign-off and any audit report, which DeployOpen does not issue.
