Healthcare access controls are failing under clinical workloads

At a glance

What this is: This is an analysis of why legacy network access models break down in healthcare and why identity-centric access is being framed as the better fit for clinical operations.

Why it matters: It matters because IAM and security teams supporting healthcare must balance least privilege, auditability, and low latency across clinician, vendor, and system access without creating care-delaying bottlenecks.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Appgate's analysis of healthcare access architecture and ZTNA

Context

Healthcare access is an identity and governance problem as much as a networking problem. Clinicians, specialists, vendors, and connected devices need access that is precise, fast, and continuously valid, yet many environments still depend on segmentation and remote access models built for a simpler perimeter.

The result is a mismatch between operational reality and control design. In healthcare, delays and over-broad trust do not just weaken security. They can affect diagnostics, treatment workflows, auditability, and patient care continuity.

Key questions

Q: How should healthcare organisations reduce VPN overreach without slowing clinical access?

A: They should replace broad network entry with direct, identity-driven access to specific clinical applications and systems. That preserves performance for imaging and real-time workflows while shrinking the post-authentication trust zone. The key is to enforce least privilege at the application layer, not to let a VPN grant access to the wider network.

Q: Why do network-based segmentation models struggle in modern healthcare environments?

A: They struggle because clinical access is now distributed across cloud EHRs, vendors, remote staff, and connected devices, while firewall rules still assume relatively fixed network boundaries. That creates brittle policy trees, audit gaps, and misconfiguration risk. Network location is too coarse to express the identity and context needed for care delivery.

Q: What breaks when healthcare access is routed through centralized VPN or cloud-brokered paths?

A: Two things break at once. Security teams get broader trust than most users need, and clinicians can experience latency or throughput issues that affect imaging, monitoring, and other time-sensitive work. In healthcare, a routing choice that degrades performance can become a governance issue because it affects both exposure and continuity of care.

Q: Who is accountable when access controls affect patient care workflows?

A: Accountability sits with the teams that design, approve, and operate the access architecture, not just the network team or the app owner. In healthcare, the relevant governance question is whether the control can prove least privilege, auditability, and acceptable performance together. If it cannot, the architecture has to be revisited before it becomes an operational liability.

Technical breakdown

Why firewall segmentation becomes fragile in healthcare

Firewall segmentation works when systems and access patterns are relatively static. Healthcare is the opposite: hospital networks, cloud-hosted EHR platforms, imaging systems, vendors, and IoMT devices change constantly, so rule sets accumulate and become hard to validate. The problem is not just scale. Network boundaries do not express role, context, or care urgency well enough to support modern clinical operations. When access is mapped to IP ranges and VLANs instead of identity and application intent, teams inherit brittle policy trees that are difficult to audit and easy to misconfigure.

Practical implication: reassess any segmentation model that still depends on network location as a proxy for trust.

How VPN trust expands clinical exposure

VPNs extend a user into the network after authentication, which creates a broad trust zone that is often larger than the user’s actual job requirement. In healthcare, that model is especially risky because clinician access, third-party support, and imaging workflows need different privilege scopes. VPN concentration also adds throughput and latency constraints that can slow image transfer and other performance-sensitive activity. The security issue and the operational issue are the same problem expressed differently: excessive trust at the network layer and too much dependence on centralized access paths.

Practical implication: limit broad network access paths where identity can be enforced closer to the application.

Why cloud-routed ZTNA can still create bottlenecks

Zero Trust Network Access is often presented as a cleaner alternative to VPNs, but architecture matters. Cloud-brokered routing can insert third-party hops between the clinician and the resource, which may be acceptable for some applications and problematic for latency-sensitive ones like imaging or real-time monitoring. In healthcare, that extra dependency affects not only performance but resilience planning and incident response. A trust model that improves security on paper can still fail operationally if it adds uncontrolled routing, external chokepoints, or data-path uncertainty.

Practical implication: validate ZTNA latency and routing decisions against the clinical systems that cannot tolerate added hops.

NHI Mgmt Group analysis

Clinical access is no longer safely governed as a network problem. Healthcare environments now rely on cloud EHRs, remote workflows, third-party providers, and connected devices, which means network boundaries no longer describe who should reach what. Access governance has to follow identity, context, and application need, not perimeter assumptions. The practitioner takeaway is that access policy must be built for care delivery patterns, not inherited from legacy segmentation.

Identity-driven access exposes the weakness in broad trust zones. VPN and flat-network models assume the authenticated user can safely enter a large internal space and self-limit from there. In healthcare, that assumption breaks because privileged clinical systems, vendor support paths, and imaging platforms do not share the same risk profile. The implication is that broad post-authentication reach should be treated as a governance defect, not merely an infrastructure convenience.

Direct access changes the control question from where a user connects to what a user can actually reach. That shift matters because access precision is the only way to reduce exposure without adding clinical friction. It also aligns better with audit expectations, since controls can record who accessed which resource under what conditions. Practitioners should treat application-level enforcement as the baseline, not an advanced option.

Healthcare access architecture now sits at the intersection of security and continuity of care. Controls that degrade throughput or add routing dependencies can become operational risks even when they improve theoretical segmentation. That is why access governance in healthcare has to be evaluated through availability, latency, and auditability together. The practitioner implication is clear: if a control slows diagnosis or support workflows, it is not fit for clinical use.

Resource visibility and overexposure remain the underlying risk multiplier. When access paths are too visible and too broadly trusted, reconnaissance and lateral movement become easier regardless of the nominal control label. For healthcare teams, the practical conclusion is that cloaking sensitive resources and enforcing least privilege are not separate projects; they are one access governance problem.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For a broader lens on breach patterns, see 52 NHI Breaches Analysis for 52 real-world cases and root cause themes.

What this signals

Access architecture will increasingly be judged on whether it supports care continuity as well as security outcomes. Healthcare teams can no longer treat latency, availability, and auditability as separate concerns. If a control protects the environment but disrupts clinical work, it will struggle to survive operational review.

Third-party access needs tighter governance than most healthcare programmes currently apply. With 92% of organisations exposing NHIs to third parties, the boundary between internal access and external support is already too porous, and healthcare vendor relationships can magnify that problem quickly.

Direct, identity-centric controls are becoming the practical way to reduce over-broad trust without rebuilding the network around every application. The near-term programme signal is clear: inventory access paths, isolate high-sensitivity workflows, and align policy enforcement with the systems clinicians actually use.

For practitioners

• Map access by clinical role and resource type Replace network-centric trust assumptions with an inventory of who needs access to which EHR, imaging, vendor, and IoMT systems under which conditions. Use that map to identify every broad network path that is carrying more privilege than the workflow requires.
• Test latency against care-critical workflows Measure access performance for imaging transfer, telehealth, and real-time monitoring before approving any routing design. A control that adds delay or jitter to those workflows should be treated as an operational risk, not just a technical preference.
• Reduce post-authentication network reach Eliminate broad network placement after login and move toward direct access to authorized applications and systems only. The aim is to preserve clinical usability while preventing authenticated users from traversing unrelated parts of the environment.
• Audit third-party and vendor access separately Treat vendor connectivity as a distinct governance path with stricter scoping, logging, and review than internal staff access. Healthcare environments often inherit hidden exposure from support relationships, especially when access is rarely recertified.
• Log and review access decisions continuously Ensure every access decision is policy-driven, recorded, and easy to correlate with patient-facing systems and support activity. That gives compliance teams usable evidence and helps security teams distinguish normal clinical access from anomalous movement.

Key takeaways

• Healthcare access control fails when network boundaries are asked to do identity work they were never designed to do.
• The operational risk is not theoretical: VPN overreach, firewall sprawl, and routed intermediaries can all affect clinical performance and exposure.
• Identity-driven access is the most defensible path when security, auditability, and patient care must all be preserved at the same time.

Key terms

• Identity-centric access: An access model that grants connectivity based on verified identity, device posture, and context rather than network location. It narrows exposure by connecting users and systems directly to the resources they are authorised to use, instead of extending trust across a large internal segment.
• Cloud-routed ZTNA: A zero trust access pattern where traffic passes through cloud-brokered infrastructure before reaching the target resource. It can improve policy enforcement, but it may also introduce latency, routing dependencies, and resilience concerns for performance-sensitive environments such as healthcare.
• Post-authentication trust zone: The set of resources a user can reach after successful authentication. In legacy VPN designs, this zone is often much broader than the person’s actual role requires, which creates unnecessary exposure and makes lateral movement easier if credentials are compromised.
• Resource cloaking: A control pattern that hides protected applications and systems from unauthorised users so they cannot be easily discovered or probed. It reduces reconnaissance and shrinks attack surface by making reachable resources visible only to identities with valid policy permission.

What's in the full article

Appgate's full analysis covers the operational detail this post intentionally leaves for the source:

• A deeper breakdown of direct-routed access design for clinical systems and why routing choices affect throughput.
• Implementation detail on dynamic, risk-based least privilege for identity and device context.
• Operational discussion of resource cloaking and how it limits reconnaissance in distributed healthcare environments.
• Audit and logging considerations for healthcare compliance and incident response readiness.

👉 Appgate's full post covers direct access design, clinical performance tradeoffs, and audit considerations.

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 or identity security programme, it is worth exploring.