Zero Trust for Healthcare: 200 Clinics Without a Hub

TL;DR

Healthcare networks have unusual properties — hundreds of distributed clinics, decades-old medical devices that cannot run modern agents, a strict compliance regime under HIPAA, and clinical workflows where downtime means real harm. Traditional hub-and-spoke VPN architectures struggle with all of these. Zero Trust architecture, correctly applied, handles them better by eliminating the central hub, placing legacy devices behind authenticated enclaves, mapping access policy to clinical roles, and producing the audit logs HIPAA auditors expect. This post is a healthcare-specific reading of Zero Trust architecture, with concrete patterns for multi-site clinics, legacy device integration, and clinical workstation policy.

Who this is for

CIOs and CISOs at health systems, hospitals, and distributed clinic networks. Compliance officers working through HIPAA and related state regulations. Architects designing or modernising healthcare network infrastructure. Assumes familiarity with basic healthcare IT and with HIPAA fundamentals.

Table of contents

1. Why healthcare is unusual
2. The 200-clinic architecture problem
3. Mesh ZTNA instead of hub-and-spoke
4. Legacy medical devices in an enclave
5. Clinical workstation policy
6. ePHI flow and audit logging
7. EHR integration patterns
8. HIPAA mapping
9. High availability and clinical uptime
10. Implementation sequence for a health system

1. Why healthcare is unusual

Five properties distinguish healthcare networks from typical enterprise networks.

1.1 Distributed clinical sites

A regional health system operates dozens to hundreds of clinics. Each has its own internet connection, its own local devices, and its own operating hours. Clinics vary in size from single-practitioner offices to multi-floor outpatient surgery centres.

1.2 Legacy medical devices

Imaging equipment, infusion pumps, patient monitors, and laboratory analysers often run OSes that are years out of support. Vendor firmware locks prevent modifications. Regulatory approvals (FDA 510(k), CE marking) attach to specific configurations; changing the OS patch level may void the certification.

1.3 Clinical workflow priorities

A radiologist waiting for an image during a stroke protocol cannot tolerate latency. A nurse trying to administer medication cannot tolerate a login failure. Network architecture must support workflows where seconds matter.

1.4 HIPAA and related regulations

All patient-related traffic is regulated. HIPAA Security Rule technical safeguards apply. State laws add further requirements (California’s CMIA, Texas’ medical privacy act, others). Breach notification timelines are tight.

1.5 Mergers and acquisitions

Health systems grow by acquisition. Each acquired clinic brings its own network, directory, and devices. Integration takes years. The “target state architecture” accommodates heterogeneity as a permanent feature, not a transient state.

2. The 200-clinic architecture problem

A typical mid-sized regional health system has:

• Central data centre with EHR, PACS, HR, and supporting systems.
• Cloud resources for new applications, often multi-region.
• 200 clinics with varying sizes and connectivity.
• Shared support functions (billing, IT, call centre) that need access to all sites.
• Third-party partners for imaging, laboratory, and specialty services.
• Remote clinicians working from home offices.

Traditional pattern: MPLS-based hub-and-spoke, every clinic homing to the central data centre via site-to-site VPN. All inter-clinic traffic hairpins through the hub. Remote users VPN into the hub. The hub is the bottleneck, the single point of failure, and the scaling limit.

As clinics expand to cloud-resident applications (EHR-as-SaaS, cloud imaging), the hairpin becomes painful: a clinic in another state accesses a cloud app by traversing the MPLS to the central data centre, then going back out to the cloud. Latency-sensitive workflows suffer.

3. Mesh ZTNA instead of hub-and-spoke

Mesh Zero Trust architecture eliminates the forced hub for clinic-to-clinic, clinic-to-cloud, and clinic-to-remote-clinician flows. Each path is a direct peer-to-peer encrypted tunnel, authorised per session by identity and device posture, subject to central policy.

Specifically:

• A clinic-based nurse accessing the EHR in the cloud takes a direct tunnel from the nurse’s workstation to the cloud EHR gateway — not through the central data centre.
• A remote radiologist reading imaging from clinic A has a direct tunnel from home to clinic A’s PACS — not through a central hub.
• Two clinics coordinating a patient transfer exchange data directly — not via hub.

The central data centre retains its role for specific on-premise systems (central EHR if still on-prem, data warehouses, backup). It is no longer a mandatory transit hop for every other flow.

The coordination plane is central (see our WireGuard mesh post for how this works), but the data plane is distributed. Availability of the coordination plane matters for new tunnel establishment; existing tunnels continue to work if the coordination plane briefly degrades.

4. Legacy medical devices in an enclave

Medical devices that cannot run modern agents live in enclaves behind an authenticated gateway.

Pattern:

• Each clinic has a ZTNA gateway appliance (physical or virtual).
• Legacy medical devices connect to the clinic’s local network behind the gateway.
• The gateway establishes its own tunnel to the coordination plane.
• External access to the medical devices is brokered through the gateway per ZTNA policy.
• The medical devices themselves run unchanged.

This pattern handles the FDA-approval immutability requirement (devices are not modified), satisfies the HIPAA Security Rule access control requirement (authorised gateway access only), and provides auditable per-access logs.

Alternative patterns where an agent can run on the device (newer medical IoT, workstations running the device’s vendor client software) are also supported — agent on the workstation, policy that only allows the workstation to reach the specific device.

5. Clinical workstation policy

Policy for clinical workstations differs from general employee policy because of uptime requirements.

Typical clinical workstation policy:

• Longer session validity. 12-hour sessions for clinicians on shift, not 1-hour sessions that require reauthentication during a procedure.
• Remediate, not deny on minor posture issues. If the workstation falls behind on OS patches, warn and schedule patching, do not block EHR access mid-shift.
• Step-down access on major posture issues. If EDR crashes, restrict to read-only EHR and emergency call functions; do not lock the clinician out.
• Break-glass procedures. Documented emergency access paths for known patient-safety scenarios, with after-the-fact audit review.
• Shared workstations. Many clinical workstations are shared by multiple nurses or physicians during a shift. SSO with short idle timeout, badge-tap re-authentication, and fast user switching.

These are policy choices made in awareness of clinical reality. A ZTNA product that offers a single “deny” response to posture failure is a bad fit; one that supports graded responses is the right tool.

6. ePHI flow and audit logging

Every tunnel carrying ePHI-adjacent traffic is logged. The audit log captures:

• User identity (the clinician, the patient-matching if applicable).
• Device identity and current posture score.
• Source and destination (resource accessed).
• Action (view, modify, download, print).
• Timestamp.
• Kex mode (hybrid post-quantum or classical).
• Policy rule matched.

Logs are exported to the health system’s SIEM. Retention is commonly six years, matching HIPAA’s general retention guidance.

For a Breach Notification Rule investigation, the logs answer the auditor’s questions. Without adequate per-session logging, the 60-day notification requirement is impractical — you cannot notify about what you cannot reconstruct.

7. EHR integration patterns

Three patterns for integrating a ZTNA deployment with an EHR.

7.1 EHR as a protected resource

The EHR is treated as any other internal application. Users tunnel to the EHR gateway; policy governs who can reach it and from what posture. The EHR’s own authentication (SAML, OIDC) handles user-level authorisation inside the application.

7.2 SSO integration

The ZTNA identity (bound to the corporate IdP) carries through to the EHR via SAML or OIDC. A clinician who authenticated to the ZTNA with phishing-resistant MFA does not re-authenticate with a password to the EHR. Reduces friction; maintains audit trail.

7.3 Audit log integration

The EHR’s audit log and the ZTNA’s audit log are ingested into the same SIEM with a common user identifier. A HIPAA audit query (“who accessed patient X’s record last Tuesday”) can correlate network-level and application-level access records.

Enterprise EHR products (Epic, Cerner now Oracle Health, MEDITECH) support these integration patterns. Smaller EHRs vary; validate the specific integration before committing.

8. HIPAA mapping

How ZTNA features map to HIPAA Security Rule technical safeguards (see our HIPAA post for the full breakdown).

Security Rule section	ZTNA feature
§164.312(a) Access control — unique user ID	SSO-bound peer identity
§164.312(a) Emergency access	Break-glass procedure, audit-logged
§164.312(a) Automatic logoff	Configurable idle timeout per policy
§164.312(a) Encryption (addressable)	WireGuard + hybrid PQ by default
§164.312(b) Audit controls	Per-session log export to SIEM
§164.312(c) Integrity	Tunnel AEAD authentication
§164.312(d) Authentication	SSO + MFA, continuous posture
§164.312(e) Transmission security	Encrypted tunnels, PQ-hybrid default

The deployment is a partial answer to HIPAA compliance. Organisational controls — policies, training, incident response, BAAs — remain the organisation’s responsibility.

9. High availability and clinical uptime

Clinical systems must stay up. Design patterns that support this:

9.1 Data-plane independence from control plane

Existing tunnels continue to carry traffic even if the coordination plane is unreachable. New tunnels cannot be established during a coordination-plane outage, but ongoing clinical sessions are not interrupted.

9.2 Multi-region coordination

The coordination plane runs in multiple regions. A region failure does not take the coordination plane down.

9.3 Local-path preference

Clinic workstations preferentially use the clinic’s local PACS, local printer, local lab analyser. ZTNA policy permits these local-to-local flows without routing through any cloud coordination. A clinic’s internet going down does not affect its internal operations.

9.4 Offline grace period

Devices cache their last-known valid policy and can operate for a configured grace period (commonly 24 hours) if the coordination plane is unreachable. After the grace period, the device must re-authenticate. Sized to cover a typical outage.

9.5 Emergency mode

Documented emergency mode where posture checks are relaxed and break-glass credentials work. Triggered manually by the on-call security officer. After-the-fact audit review is mandatory.

10. Implementation sequence for a health system

Sixteen steps, sequenced. Typical duration 9-18 months for a 200-clinic health system.

1. Clinical stakeholder engagement. CMIO, nursing leadership, security. Align on workflow constraints.
2. Identity consolidation. Single IdP, SCIM to clinical systems.
3. Device inventory. Every workstation, every medical device, every IoT device.
4. Pilot site selection. One clinic, 30-50 staff. Willing participants.
5. Deploy ZTNA product. Mesh or proxy model based on architectural fit.
6. Integrate IdP and MFA. FIDO2 on administrative accounts.
7. Enrol pilot devices. Workstations and clinical IoT.
8. Build pilot policy. Clinical role-based ACLs. Start permissive.
9. Run pilot for 60-90 days. Collect friction reports. Adjust.
10. SIEM and log integration. Ingest ZTNA logs.
11. HIPAA documentation update. Risk analysis, policies, procedures refreshed.
12. Phased rollout. Clinic by clinic or region by region. 10-20 sites per month after pilot.
13. Legacy device enclaves. Gateway appliances at each clinic.
14. EHR integration. SSO, audit correlation.
15. Decommission legacy VPN. After each site’s cutover plus 30 days.
16. Operations handover. Document runbooks, train clinical IT staff.

Sequence can be adjusted for local realities; order of items 2-10 and 11-13 matters.

Further reading

• HHS HIPAA home.
• NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule.
• NIST SP 800-207 — Zero Trust Architecture.
• HHS, “Cybersecurity Performance Goals” for healthcare.
• Joint Commission, healthcare-specific standards.

Related reading on this blog

• HIPAA-Compliant VPN in 2026
• What Is ZTNA?
• Device Posture Checks That Actually Work
• WireGuard Mesh Network

Try QuickZTNA

QuickZTNA Workforce tier includes healthcare-specific features: BAA on request, mesh architecture for distributed clinics, enclave gateway for legacy medical devices, graded posture policy for clinical workstations, and HIPAA-aligned audit logging. Contact sales for a healthcare evaluation brief.