Why open source zero trust access for healthcare starts with the EHR and PACS front end
For most hospital IT and security leaders, the first zero trust question is not which overlay network to buy but how to stop a site-to-site VPN from exposing the whole clinical network to an imaging vendor or a remote clinician. The practical answer is to publish only the EHR and PACS front ends to named identities and managed devices, and to keep the control plane inside the organization's own environment. In healthcare, every connection must tie back to a unique user because the HIPAA Security Rule requires unique user identification, person or entity authentication, transmission security and audit controls for systems that hold electronic protected health information (ePHI), as set out in 45 CFR 164.312. A flat VPN tunnel makes that tracing difficult, and the enforcement record shows regulators treat it as a gap. France's CNIL fined Hopital Prive de la Loire EUR 500,000 under GDPR in September 2026 after finding that external access to its patient record system lacked VPN and multi-factor authentication and ignored the care team's need to know.
On platforms, the short answer for most healthcare organizations is to use NetBird or Pomerium for app access. NetBird suits staff and vendor laptops that need network-level reach to a defined set of servers, while Pomerium suits browser-based access to EHR and PACS web front ends, with per-route policies and access logs for each request. Pick the identity source before either tool: Keycloak, ZITADEL or authentik can federate with the hospital's directory, enforce multi-factor authentication and issue the group claims that drive access rules. Confirm with each vendor whether the features you need, such as device posture checks or SSH session recording, are included in the self-hosted edition or only in a paid tier, because the published feature split differs by product and plan.
Keeping the control plane inside the hospital's environment matters because the coordination, policy and log data describe who reaches which clinical system and when. With Pomerium Zero, the cluster still runs in the customer's environment while Pomerium hosts the control plane, so application traffic stays local but policy metadata does not. A fully self-hosted NetBird deployment keeps management, signal, relay and identity components on infrastructure the hospital controls, and its documentation makes the operator responsible for backups and upgrades. Before a pilot, ask the implementation partner to document which component holds which data, where relays sit for remote clinics, and how the business associate terms under 45 CFR 164.314 cover any vendor that operates a component.
Which HIPAA and related requirements shape the access design
This table maps the HIPAA technical safeguards, the business associate flow-down rules and the CNIL finding on external access to specific design choices for a ZTNA deployment. Read each row as a requirement, then the build consequence and the evidence an assessor or regulator will ask to see. The main takeaway is that identity, per-route policy and logging decide most of the compliance outcome, while the tunnel technology matters less.
| Requirement | What it asks for | What it means for the build |
|---|---|---|
| Unique user identification (45 CFR 164.312(a)(2)(i)) | Each person accessing ePHI systems is assigned a unique user identifier that is tracked. | Issue one named identity per clinician, locum and vendor technician through the identity provider. Ban shared VPN or gateway accounts and map every ZTNA session to a single user. |
| Automatic logoff and emergency access (164.312(a)(2)) | Automatic logoff is addressable. Emergency access procedure is required. | Set idle session timeouts in the proxy or overlay client. Define a break-glass access path with its own logging and review, since clinical access cannot stop during an outage. |
| Audit controls (164.312(b)) | Record and examine activity in systems that contain ePHI. | Enable access logs and audit events in the ZTNA control plane and forward them to the SIEM. Confirm which logs your edition exports, such as access logs in Pomerium Zero or activity and traffic events in NetBird's Team and Business plans. |
| Person or entity authentication (164.312(d)) | Verify that a person or entity seeking access is who they claim to be. | Require SSO with MFA at the identity provider for every route to an EHR or PACS front end. Add device posture checks so that unmanaged endpoints do not pass on a valid password alone. |
| Transmission security (164.312(e)(1)) | Guard ePHI sent over electronic networks against unauthorized access, with integrity controls and encryption. | Use mTLS or WireGuard-encrypted tunnels end to end between clinician devices and the apps. Confirm where TLS terminates, especially if a relay or cloud control plane handles traffic. |
| Encryption specifications (164.312(a)(2)(iv), (e)(2)(ii)) | Encryption and decryption of ePHI and encryption during transmission are addressable, meaning you document a decision if you do not implement them. | Document the encryption choice for each route in the access design. If a route is not encrypted, record the reason and the compensating control in the risk analysis. |
| Business associate flow-down (45 CFR 164.314(a)(2)(i)) | Business associate contracts require the vendor to comply with the Security Rule, flow terms to subcontractors handling ePHI and report security incidents. | Imaging vendors, remote support firms and any contractor reaching PACS or EHR through ZTNA need a business associate agreement before access is granted. Include who operates the relay, control plane and log store, and whether those subcontractors touch ePHI. |
| External access without VPN or MFA (CNIL, Hopital Prive de la Loire, 3 September 2026) | The CNIL fined the hospital EUR 500,000 under GDPR Articles 32 and 34 for external access without VPN or MFA and access control that ignored the care team's need to know. | Treat external access as a regulated path with MFA, encrypted connections and per-role policies tied to care team membership. Document the need-to-know rule in group policy so that the access grant itself is auditable. |
| No HIPAA certification (HHS FAQ 2003) | No Security Rule standard requires certification, and HHS enforces through complaints, compliance reviews and audits. | Do not describe the ZTNA design as HIPAA certified. Keep a written risk analysis, access rules, logs and vendor agreements that a regulator or auditor can examine. |
Which open source platforms fit healthcare access patterns
Healthcare access splits into a few distinct patterns: clinicians reaching EHR and PACS web front ends, managed clinical laptops, connected clinic networks and identity for all of it. No single open-source component covers every pattern, so the choice starts with which access path each group of users needs and which license and edition limits apply to it.
Pomerium for clinical web front ends
Pomerium is an identity and context-aware reverse proxy that gives clinicians browser access to internal web applications without a client on the device, which suits EHR and PACS web front ends used from home or from a vendor site. Its Core is Apache-2.0 and runs in your environment. Confirm which EHR and PACS front ends work cleanly behind a proxy, how session timeouts interact with clinical workflows, and which features your edition includes, since directory sync, Rego policies and session management are reserved for Enterprise.
NetBird for clinician laptops
NetBird combines a WireGuard overlay with central access policies, SSO groups and posture checks, so it fits clinician laptops that need reach to non-web systems such as SSH hosts, file shares or modality networks. Device posture checks and traffic logging sit in the Business tier, not the lower tiers. The control plane directories are licensed under AGPLv3, which matters if you modify and host them for staff. Ask the vendor to confirm which checks run on which operating systems.
Connected clinic routes
Satellite clinics and imaging sites often need a stable route to a central network without a hardware VPN appliance at every location. NetBird routes to external networks and runs clients on routers and NAS devices such as OPNsense, pfSense and Synology, which can act as clinic gateways. Test the route design with your clinical network team, because routing a whole clinic subnet widens reach compared with per-application access. Confirm which gateway hardware your sites run and how its clients receive updates.
Keycloak as the identity provider
Keycloak supports OpenID Connect, SAML 2.0, MFA-capable federation and Active Directory user federation, which makes it a common identity layer in front of both a proxy and an overlay. Clinical staff, contractors and vendor accounts can be separated into groups that map to care team access. Confirm that your MFA method meets the HIPAA unique user identification and person authentication expectations, and plan for clustering and backup of the identity store because it becomes a single point of access failure.
authentik or ZITADEL as alternatives
authentik and ZITADEL are alternatives to Keycloak when the team prefers a lighter administration model or needs passkeys and multi-tenancy for external groups. authentik is MIT except its enterprise directory, and ZITADEL is AGPL-3.0 with SAML 2.0, SCIM and passkeys listed in its README. Check which directory connectors your existing Active Directory or EHR accounts need, and confirm the license terms that apply to any enterprise features you plan to use before choosing.
Headscale or OpenZiti for specialized overlays
Headscale is an open-source coordination server for Tailscale clients, and OpenZiti is an overlay that lets services dial out without inbound ports. Either can suit device-to-device needs such as imaging vendors pushing to a modality network or clinical engineers reaching medical device segments, where an overlay is more natural than a browser proxy. Confirm each option's client support on your device fleet, its posture integrations, and how it meets your audit and logging requirements before adopting it alongside NetBird or Pomerium.
How the design changes for remote clinicians, imaging vendors and connected clinics
Remote clinicians, such as hospitalists on call, telehealth physicians and clinicians working from home, need the EHR front end and a limited set of clinical tools from managed laptops. Their identity should come from the workforce identity provider that already governs the EHR account, so that disabling a user in one place removes access everywhere. Each person should have a unique identity, which the HIPAA Security Rule requires under unique user identification in 45 CFR 164.312. The access design should follow the care team's need to know, not the whole hospital network.
- Identity source: Use the workforce identity provider (for example, Keycloak, authentik or your existing directory) with MFA enforced for every session, and map clinical roles to access groups.
- Device posture: Require company-managed laptops with disk encryption, screen lock and current OS patches before the route opens. Confirm which posture signals your overlay or proxy can read on your operating systems.
- Route scope: Publish the EHR web front end and specific clinical applications as individual routes, not a subnet. Block direct access to database tiers and file shares.
- Audit logging: Record who connected, from which device, to which route, and when the session ended. Send these logs to your SIEM so audit controls can examine ePHI access.
Before go-live, confirm with your EHR vendor which remote access methods it supports and whether its own audit log can be correlated with ZTNA session records.
Imaging vendors and PACS support engineers often need to view studies, check modality connections or troubleshoot viewers. Their access is governed by a business associate contract under 45 CFR 164.314(a)(2)(i), which requires the vendor to comply with the Security Rule, flow the same terms to subcontractors that handle ePHI, and report security incidents. Identity should be vendor-specific and sponsored by a named hospital owner, not a shared support account. The design should reach the PACS viewer or a single support host, never the imaging archive network.
- Identity source: Create named external identities in a separate realm or group, sponsored by an internal owner, with MFA and an expiry date tied to the support contract.
- Device posture: Accept vendor devices only if they meet a minimum baseline you define, or use a browser-based route so no vendor device joins your network. Confirm what posture data you can collect from unmanaged devices.
- Route scope: Publish only the viewer URL or a named support host. Keep modality, archive and DICOM networks unreachable from vendor identities.
- Audit logging: Retain per-request or per-session logs with vendor identity, route and time, and keep them available for the review your business associate terms require.
Before signing, confirm the vendor's own subcontractor chain, incident reporting timelines in the contract, and whether the vendor's staff are covered by the same MFA rules.
Connected clinics, such as satellite imaging centers, outpatient sites and specialty clinics, need routes back to hospital systems like the EHR, lab interfaces and the PACS. The traditional approach is a site-to-site VPN that exposes the whole clinic subnet to the hospital. An overlay network with routes to specific internal networks lets the clinic reach named services while keeping its own devices segmented. Clinic devices such as printers, workstations and imaging modalities should not share the same access policy as clinical staff.
- Identity source: Authenticate clinic staff individually through the workforce identity provider, and treat the clinic router or gateway as a managed device with its own identity.
- Device posture: Require the gateway to run current firmware and to be inventoried. Use device approval or posture checks where the overlay product supports them.
- Route scope: Publish specific hospital services as routes to the clinic group. Keep modality and medical device networks in their own segment, and do not route them to the hospital core.
- Audit logging: Log gateway connections and route usage centrally. Plan for clinic connectivity loss, since offline behavior and relay placement determine what continues to work.
Before deployment, confirm whether the overlay supports the routing and DNS pattern your clinics need, and where relay and control plane components will run.
How a healthcare ZTNA rollout moves app by app
This sequence moves clinician, imaging vendor and clinic access from site-to-site VPNs to identity-based access one application at a time, so each EHR or PACS route is tested and approved before the old path is removed.
Scope the ePHI systems and user populations
The privacy or compliance lead and the application owners list every system that creates, receives, maintains or transmits ePHI, including EHR front ends, PACS viewers, file shares and remote desktop hosts. Clinical operations, the security team and imaging vendor contacts then confirm which user groups (employed clinicians, traveling staff, connected clinics, vendor engineers) need each system. The output is an access matrix that maps each application to its users, device types, network paths and the HIPAA safeguards it supports. The step is done when the business owner of each system has signed the matrix.
Confirm the identity provider and MFA method
The identity team confirms which directory holds clinician and vendor accounts, whether a self-hosted option such as Keycloak or a platform already in use will act as the identity provider, and which multi-factor method each group will use. Phishing-resistant options should be evaluated for privileged and vendor accounts. The team also records how unique user identification will be enforced, since each clinician and vendor engineer must have an individual account and no shared logins. The output is a written identity design with account naming rules, MFA methods per user group and a decision on how group membership will drive access policies. The step is done when the identity owner and the security lead have approved it.
Stand up a non-production control plane
The platform team deploys the chosen ZTNA components, such as a Pomerium Core cluster or a NetBird control plane, in a non-production environment inside the organization's own infrastructure. They configure the identity provider connection, TLS certificates, logging destination and admin roles, then record the versions and configuration in a change record. For NetBird self-hosting, the team should confirm the ports, domain and backup approach in the vendor's quickstart before building. The output is a running test environment with documented configuration and a rollback plan. The step is done when administrators can sign in and the logs reach the team's log store.
Test routes and policies against the access matrix
The security engineers and application owners create test routes for each application in the access matrix and write the policies that tie each route to identity provider groups. They test allowed and denied users, expired sessions, lost MFA devices and access from unmanaged devices, and confirm that each request appears in the audit log with the user identity. Any mismatch between the matrix and the policy set is corrected before the next phase. The output is a tested policy set with a test report and a record of the failed cases and fixes. The step is done when every matrix row has a passing test.
Pilot with one clinical group and one imaging vendor
The rollout team selects one clinical group, such as a single department using the EHR front end, and one imaging vendor that needs PACS access. Both pilot users sign in through the new path while the VPN remains available as a fallback. The team gathers feedback on login steps, application performance, clinical workflow interruptions and vendor support tasks, and it reviews the audit trail with the privacy officer. The output is a pilot report listing issues, owner decisions and any changes to policies or device requirements. The step is done when the pilot group confirms that its daily work can be completed and the privacy officer accepts the audit records.
Cut over each application while the VPN stays in place
Applications move to the new access path in batches, starting with those that carry the lowest clinical risk and the clearest user groups. For each application, the team updates the DNS or client configuration, communicates the change to users, and keeps the existing VPN route active for a rollback period agreed with the application owner. Each cutover is recorded in a change record with the approval, test evidence, affected users and rollback steps. The output is a per-application change log showing which systems are on the new path and which still depend on the VPN. The step is done when the owner confirms the application is working and no emergency rollback is open.
Retire site-to-site tunnels and close the evidence file
After every application on a site has been cut over and the rollback window has closed, the network team removes the site-to-site tunnels and the VPN access rules that are no longer needed. They update the network diagram, firewall rules and asset inventory, and they archive the access matrix, policy tests, pilot report and change records in the compliance evidence repository. Compliance staff should confirm with their auditors which records they expect to see for access control and audit controls. The output is a retired tunnel list, updated network documentation and an evidence package. The step is done when the network diagram matches the live configuration and the compliance lead accepts the package.
Evidence a privacy or security reviewer asks for
This table lists the evidence artifacts a privacy or security reviewer typically requests for remote access to EHR and PACS front ends, which component produces each one, and what to confirm before the review. Read it as a checklist of what the access stack can export, not as proof of compliance. DeployOpen prepares this evidence, but auditors and certification bodies assess it, and HIPAA has no certification.
| Evidence artifact | Produced by | What the reviewer checks |
|---|---|---|
| Unique user identifiers | Identity provider (for example Keycloak, Entra ID or Okta) | Each clinician, imaging vendor and contractor has one account, with no shared logins for EHR or PACS access |
| Route and policy exports | Pomerium policy configuration or NetBird groups and access rules | Which roles reach which EHR or PACS front end, and whether the rules follow the care team's need to know |
| Access and audit logs | Pomerium access logs or NetBird activity and traffic event logs | Who connected, when, to which application, and whether logs are retained and reviewed |
| MFA enrollment records | Identity provider MFA settings and enrollment reports | Every remote account has a second factor enrolled before its first access to patient systems |
| Device posture results | NetBird posture checks or MDM and EDR signals fed into policy | Clinical laptops meet the required state (for example, OS patch level and disk encryption) before access is granted |
| Transport encryption configuration | WireGuard overlay, TLS certificates on the proxy, and relay settings | Traffic between clinician devices, the proxy or overlay and the application is encrypted, with certificate ownership documented |
| Business associate agreements | Contracts held by the covered entity and each vendor with remote access | Imaging vendors and other remote parties with ePHI access have agreements covering the Security Rule and incident reporting |
| Control mapping to the Security Rule | Written mapping prepared with the implementation partner | Each access and audit element links to the relevant technical safeguard in 45 CFR 164.312, for review by the covered entity's assessor |
What buyers ask before hiring help on healthcare ZTNA
What drives the effort and cost of a healthcare ZTNA project?
The biggest drivers are how many EHR and PACS front ends you publish, how many outside vendors need access, and how much work the identity provider integration takes. Each route needs an owner, a policy and testing, so the route count sets the scope. Logging retention and clinical downtime windows also matter, because the logs must be kept for the period your policies require and changes often have to be scheduled around clinic hours. Ask any partner for a quote that lists routes, vendor groups, identity integrations, log storage, and the cutover window as separate line items, with what is one-time and what recurs (licenses, hosting, upgrades and support).
How long does a pilot take before clinicians can use it?
A pilot length depends on the scope agreed in writing, not on a standard number. A typical pilot covers one application, a small clinician group and one vendor, and it needs the identity provider, device posture decisions and a clinical sign-off before any real patient workflow moves. Ask a partner to show the pilot milestones, the dependencies on your identity team and the acceptance criteria, and to name which steps can run in parallel. Any duration you are given should be tied to a written scope and to the readiness of your own teams.
What does our hospital team need to provide for the project?
Three groups of people are needed from day one. Application owners for the EHR and PACS front ends must confirm which routes, roles and user groups should exist. Identity administrators must provide the directory, group structure, MFA method and the identity provider configuration. Clinical leaders must sign off on who needs which access and on the downtime plan. Without these decisions the project stalls at policy design, so ask a partner to list the named roles and decision points in the statement of work before work starts.
Can our internal team run a healthcare ZTNA platform without a partner?
Yes, many teams run open-source access platforms in-house, but the question is whether the team has steady capacity for patching, upgrades, backups, logging and incident response on the access path. Self-hosted tools like NetBird and Pomerium document that the operator handles backups, upgrades and scaling, and that work recurs. Assess your staff on identity engineering, network routing, certificate handling and clinical application knowledge, and decide whether you need a fixed-scope build, a retainer for ongoing support, or full internal ownership.
What does the proposed HHS Security Rule revision mean for the design?
HHS proposed a major Security Rule revision on 6 January 2025, and as of October 2026 no final rule has been published. The Unified Agenda projects final action for July 2027, so the timing and final text are uncertain. Current requirements still apply, including unique user identification, audit controls, person or entity authentication and transmission security. Design the access layer to meet today's standards and keep identity, logging and encryption choices flexible enough to absorb changes. Ask a partner how they track the rulemaking and what the change process looks like in a fixed-scope engagement.
How should penalty ranges shape the business case for healthcare ZTNA?
The HIPAA civil money penalty table is inflation-adjusted, and for penalties assessed on or after 28 January 2026 the range runs from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294, according to 45 CFR 102.3. The range shows that the exposure is high, but actual outcomes depend on the facts of each case. A stronger business case focuses on the controls the rule requires, such as unique user identification, audit logs and encrypted transmission, and on the cost of an incident. Ask any partner to map the project to those controls, and remember that no HIPAA certification exists, so evidence must come from your own records and independent assessments.
What should we check about vendor access and audit logs for PACS and EHR?
Check that each vendor has a named account, that access is limited to the routes it needs, and that every session is recorded with a user identity, time and destination. Confirm where logs are stored, who can read them, and how long they are kept, since the HIPAA audit control standard requires systems containing ePHI to record and examine activity. Also confirm the edition features you need, because some logging, directory sync and posture integrations are limited to enterprise tiers in certain products. Verify these points with the vendor and the platform documentation before committing.
Questions to ask an implementation partner for healthcare access
Start with clinical application experience. Ask the partner which EHR front ends and PACS viewers they have routed through an identity-aware proxy or overlay before, and how they handled the parts that break under a proxy: long-lived imaging sessions, large DICOM and web viewer downloads, WebSocket traffic, and vendor-hosted imaging viewers that expect direct network paths. Ask for a written list of which applications they would expose through browser-based access first and which they would leave on existing paths until a later phase. A partner who cannot name the viewer protocols involved has not done this work.
Ask how the partner handles its own obligations. If they will touch systems that hold ePHI, the business associate terms under 45 CFR 164.314(a)(2)(i) should cover their work, including their subcontractors, and their incident reporting duties to you. Ask where their engineers access your environment from, which of their staff hold administrative credentials for the control plane, and how those accounts are logged and reviewed. Ask for the name of the document that will govern this relationship and confirm it is signed before any access is granted. Ask the same questions about any managed service the partner plans to run for you.
Ask where the control plane and relays will run, and who can read traffic and logs at each point. Require a diagram that shows each component (identity provider, controller, relay, proxy, logging pipeline), its hosting location and its administrators. Ask how break-glass access is designed: which named roles can open emergency access, how that access is time-limited and approved, how it is recorded, and how it is reviewed after use. Ask how logs are retained, exported to your SIEM and protected from alteration, and how the partner will test failover when a clinic loses its link to the head office. The answers should be tested in your environment, not only described in a proposal. Confirm the retention period and export format with your compliance lead before you sign.
How DeployOpen scopes and runs healthcare zero trust access
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For healthcare zero trust access, that means the access design, control plane and evidence stay under the organization's control, with work agreed in a written, fixed scope before it starts.
How we scope
- Inventory which EHR and PACS front ends, imaging vendor portals and clinic systems move off site-to-site VPNs first.
- Map clinical roles to identity provider groups and document the need-to-know rules each application needs.
- Agree in writing how clinical laptops are checked for posture, and which devices are excluded or handled separately.
How we build
- Deploy the chosen access platform, such as Pomerium, NetBird or another option agreed in scope, in the client's own cloud account, data center or network.
- Configure per-route policies tied to the organization's identity provider, with MFA enforced for every access path.
- Test access paths, failure behavior and logging against the written scope, including transmission encryption in each path.
How we hand over
- Document the architecture, policy inventory, routing, data flows and the location of every component holding session or access data.
- Provide access logs and audit configuration mapped to the unique user identification and audit control expectations for ePHI systems.
- Train the internal platform and security team to run onboarding, offboarding and policy changes without DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
- Upgrades, backups and scaling for self-hosted components are documented and handled under the agreed support terms.
- Evidence for compliance assessments is prepared for the client's own auditors, who issue any reports or certifications.
