TL;DR: Healthcare zero trust fails when it inherits VPN-era assumptions, according to Appgate, because clinical access must balance identity, device posture, context, performance, and auditability across EHRs, imaging, telehealth, and third-party connections. Zero trust in this setting is less about branding and more about whether access decisions stay precise enough to support care without broad trust zones.
At a glance
What this is: This analysis says healthcare zero trust only works when access is identity-aware, context-aware, and tight enough to support clinical workflows without falling back to broad VPN trust zones.
Why it matters: IAM and security teams in healthcare need access models that protect patient data, control third-party connectivity, and preserve the responsiveness clinicians depend on.
Context
Healthcare access architecture is a security control and a care-delivery dependency at the same time. When clinicians, vendors, devices, and systems all need timely access to EHRs, imaging, and telehealth services, network-based trust models become too blunt for the operational reality.
The core governance gap is not zero trust itself but the assumption that location can stand in for trust. In healthcare, access needs to follow identity, device posture, and context while still preserving performance, auditability, and continuity for clinical work.
Third-party access, hybrid environments, and connected medical devices make that gap wider. The article argues that healthcare programmes should treat access as a precision problem, not a perimeter problem.
Key questions
Q: How can zero trust be applied in healthcare without disrupting care delivery?
A: Zero trust should be applied at the point of use, with policy that reflects clinical context rather than a generic deny-by-default posture. Healthcare teams should validate identity, device state, and access context when records are opened or actions are taken, so security checks fit the workflow instead of blocking it.
Q: Why do VPN-style access models create risk in healthcare?
A: VPN-style models usually trust a user once they are inside the network, which gives them broad reach that is too coarse for healthcare. That increases lateral movement risk and makes it harder to distinguish clinicians, vendors, and devices. Healthcare access needs precise authorization, not blanket internal trust.
Q: What are the signs that a healthcare zero trust programme is too broad?
A: Common warning signs are broad network reach after login, inconsistent treatment of third parties, and access paths that cannot be tied cleanly to a specific clinical system. If a user can move across multiple applications simply because they are connected, the architecture is behaving more like segmented VPN access than zero trust.
Q: How should teams govern third-party access in digital healthcare environments?
A: They should treat third-party identities like a governed lifecycle, not a temporary exception. That means defining scope before access is granted, reviewing active entitlements regularly, and revoking access as soon as the vendor need ends. External accounts should be monitored with the same rigor as employee access, especially in shared clinical systems.
Technical breakdown
Why VPN-style trust breaks in clinical environments
VPNs and network-segment trust models were designed for broad enterprise access, where authenticating once and then moving inside a trusted zone was acceptable. In healthcare, that assumption breaks because users, devices, and third parties operate across distributed clinical systems, remote work paths, and time-sensitive workflows. Once network location becomes the trust signal, the model cannot distinguish a clinician from a vendor technician or a compromised session moving laterally toward critical systems. The technical problem is not connectivity alone but the size of the implied trust boundary. When imaging, telehealth, and EHR access all depend on that boundary, the blast radius of a weak decision becomes operational, not just security-related.
Practical implication: move away from broad network access decisions and scope connectivity to the specific clinical resource being requested.
Identity, device posture, and context as access inputs
Zero Trust Architecture, as defined by NIST SP 800-207, replaces implicit trust with continuous evaluation of identity and context. In healthcare, that means the access broker should consider who is connecting, what device they are using, where the request originates, and whether the device posture is acceptable. This matters because healthcare access is dynamic: roles change, vendors rotate, and endpoints drift in health or compliance state. A static permission model cannot express those changes safely. The article's central technical point is that clinical access decisions need to be evaluated continuously, not only at initial login, if organisations want both security and usable care delivery.
Practical implication: tie access policy to identity and context signals that can change during the session, not just at authentication time.
Direct routing versus cloud-routed ZTNA
Routing choice affects more than network design. Cloud-routed ZTNA can insert external hops that add latency and dependency, which is risky when applications are performance-sensitive and clinicians need predictable response times. Direct routing reduces that extra path and keeps traffic flow closer to the authorised resource, which better suits imaging, telehealth, and other real-time healthcare workloads. The technical trade-off is not security versus speed in the abstract. It is whether the access control path itself becomes a bottleneck or a reliability risk. For healthcare, the architecture has to lower exposure without turning secure access into another point of operational friction.
Practical implication: evaluate whether your routing model preserves clinical responsiveness before extending zero trust to time-sensitive systems.
NHI Mgmt Group analysis
VPN-era trust assumptions are the wrong foundation for healthcare access. Healthcare networks now mix internal staff, remote clinicians, vendors, cloud applications, and connected devices, so a location-based trust model cannot represent the real risk boundary. The governance failure is assuming that authenticated network presence is enough to justify broad access. Practitioners should treat clinical access as a scoped entitlement problem, not a network membership problem.
Healthcare zero trust is an identity governance issue as much as a network design issue. The article's strongest signal is that identity, context, and device posture must jointly determine access outcomes. That aligns with NIST SP 800-207 and with the practical reality that roles and device conditions change continuously in healthcare operations. The implication is that access policies need enough granularity to handle clinicians, contractors, and third parties differently without slowing care.
Third-party access without narrow scoping remains one of the largest governance gaps in healthcare. External providers and equipment vendors are necessary participants in modern care delivery, but open-ended remote access creates visibility and offboarding problems. This is a classic identity lifecycle issue, not just a connectivity one. The programme question is whether third-party access can be audited, reduced, and revoked with the same discipline as internal access.
Identity-aware access becomes a patient-safety control when performance matters. The article makes clear that access controls in healthcare cannot be judged only on prevention. They also have to preserve responsiveness for EHRs, imaging, and telehealth, because delayed access can affect care delivery. That means architects should judge zero trust by whether it reduces exposure without introducing a new operational bottleneck.
Clinical zero trust needs a named design principle: precision access boundary. The useful concept here is not generic least privilege but a precision access boundary, where every policy decision is tied to the exact resource, context, and current trust signal needed for care. Broad trust zones are too coarse for healthcare. The practitioner conclusion is to make the access boundary visible, narrow, and continuously evaluated.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Read next: Zero Trust Identity Guide
What this signals
Precision access boundaries: healthcare zero trust succeeds when policy boundaries match actual clinical use, not flat network segments. That means access review, offboarding, and visibility need to follow the resource being protected rather than the zone a user happens to sit in.
If a programme still treats vendor access as a VPN problem, it will keep over-granting privilege to protect uptime. The better model is context-aware entitlements with enough granularity to preserve both clinical responsiveness and governance evidence.
The strongest zero trust programmes in healthcare will be the ones that can prove who reached which clinical system, under what context, without turning care delivery into a series of broad exceptions.
For practitioners
- Replace broad VPN trust with scoped clinical access Map clinician, vendor, and device access to the specific EHR, imaging, telehealth, or device resource required, and remove network-wide entitlements wherever possible.
- Use identity and context as policy inputs Require role, device posture, and request context to influence every access decision so that a user approved in one circumstance is not automatically trusted in another.
- Constrain third-party connectivity to auditable paths Give external providers only the access needed for the task, log each session, and ensure offboarding removes the path as well as the account.
- Test routing against clinical performance Measure latency, resilience, and application responsiveness for time-sensitive workflows before committing to a cloud-routed or direct-routed access pattern.
- Integrate access controls with the wider security stack Connect identity, endpoint, and SIEM telemetry so policy enforcement and investigation have a consistent view across hybrid healthcare environments.
Key takeaways
- Healthcare zero trust breaks down when it inherits VPN-era trust assumptions instead of using identity and context as the basis for access.
- The operational risk is not only exposure, but also delayed or degraded access to systems that clinicians need in real time.
- The right control shift is toward narrow, auditable connectivity that protects patient data without sacrificing clinical performance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Policy Engine and Policy Administrator — Policy Engine and Policy Administrator | The article is built around continuous, context-aware zero trust access decisions in healthcare. |
| Recommendation — Apply policy-driven authorization that evaluates identity, device posture, and context before granting healthcare access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on narrowing and governing entitlements for clinicians, vendors, and systems. |
| Recommendation — Scope entitlements to the specific clinical resource and keep them auditable across the access lifecycle. | ||
| CIS Controls v8 | CIS-5 — Account Management | Third-party accounts and changing access relationships are central to the healthcare access problem described. |
| Recommendation — Review and revoke third-party accounts so vendor access never outlives its clinical purpose. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article repeatedly argues for tight scoping instead of broad network trust zones. |
| Recommendation — Enforce least privilege at the application and session level rather than through network-wide access. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Healthcare access to clinical systems and vendors requires controlled privileged access rights. |
| Recommendation — Define and review privileged access rights for clinical systems on a strict need-to-use basis. | ||
Key terms
- Identity-Aware Access: Identity-aware access is an authorization model that evaluates who or what is making a request, what it is trying to reach, and under what context. It replaces broad, persistent trust with request-level decisions. In agentic environments, it is the control that can contain a deceived agent before it reaches enterprise systems.
- Direct-Routed ZTNA: A zero trust access pattern where users and devices connect directly to authorized resources rather than detouring through a cloud relay. In healthcare, it matters because latency and routing stability can affect EHR, imaging, and telehealth performance.
- Precision access boundary: A narrowly defined control boundary that ties access to the exact system, context, and purpose needed for the task. In healthcare, it replaces broad network zones with a more auditable and operationally realistic way to protect clinical resources.
- Third-Party Access Lifecycle: Third-party access lifecycle is the full sequence of granting, using, reviewing, and removing external access to internal systems. It matters because supplier credentials and remote sessions often outlive the business need, creating governance gaps that are difficult to detect without explicit offboarding and review.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org