What do security teams get wrong about segmentation in healthcare?

Why This Matters for Security Teams

In healthcare, segmentation is often sold as a containment answer for ransomware, lateral movement, and unsafe device exposure. The problem is that hospitals are not clean enterprise networks: they contain clinical devices, legacy systems, vendor remote access, shared workstations, and application-to-application flows that were never designed for strict network boundaries. When teams reduce segmentation to subnetting, they miss the governance layer that decides which identities, services, and devices are allowed to talk.

That gap matters because healthcare attack paths often exploit trusted pathways rather than obvious perimeter failures. The NIST Cybersecurity Framework 2.0 emphasizes outcome-based risk management rather than a single control mechanism, which is a better fit for mixed clinical environments. NHIMG’s Ultimate Guide to NHIs also shows why this matters operationally: 97% of NHIs carry excessive privileges, which expands the number of implicit trust paths segmentation is supposed to constrain.

In practice, many security teams discover segmentation gaps only after an incident reveals that trusted device-to-device or service-to-service paths were never documented, let alone governed.

How It Works in Practice

Effective healthcare segmentation starts with traffic and identity discovery, not with a redesign of every VLAN. Teams need to map east-west communication between medical devices, clinical applications, directory services, authentication services, backup systems, and third-party support channels. That map should distinguish stable business flows from unnecessary trust paths, because clinical uptime depends on preserving the former while removing the latter. Current guidance suggests treating this as a control governance problem as much as a network architecture problem.

In mature environments, segmentation policy is expressed in terms that operations can maintain: device class, application role, identity, privilege level, and approved destination. That is where NHIs become central. Service accounts, API keys, device certificates, orchestration tools, and remote vendor credentials often sit on the critical path between systems. If those identities are over-privileged or poorly rotated, the segmentation boundary becomes porous even when the network is technically divided. The industry is still converging on the best way to model this across legacy biomedical systems, so there is no universal standard for this yet.

• Inventory assets and identities together, including unmanaged and vendor-managed pathways.
• Define policy around required clinical flows, not around abstract network zones.
• Constrain service accounts and device credentials to the minimum destinations they actually need.
• Validate rules against failover, patching, telemetry, and life-safety workflows before enforcement.

For teams building an identity-aware approach, NHIMG’s research on The State of Non-Human Identity Security reinforces a key point: visibility and privilege control are often the real blockers, not the lack of segmentation hardware. These controls tend to break down when legacy clinical devices require vendor exceptions because the exception process becomes the de facto policy model.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance stronger containment against clinical continuity, device uptime, and supportability. That tradeoff is especially sharp in healthcare, where life-safety workflows and regulated equipment can make rigid network rules impractical.

One common edge case is unmanaged or partially managed medical equipment that cannot support modern agents, network posture checks, or frequent credential rotation. Another is third-party support access, where vendor VPNs or jump hosts may be allowed broad reach simply to keep maintenance efficient. A third is shared infrastructure such as imaging, lab, and pharmacy systems, where over-segmentation can create outages that clinicians quickly work around. In these cases, current guidance suggests layering compensating controls such as strong authentication, jump-box mediation, session logging, and time-bound access instead of assuming segmentation alone is sufficient.

There is also a growing identity intersection with agentic automation in healthcare operations. If autonomous tools are used for patching, inventory, alert triage, or workflow orchestration, their machine identities must be treated as privileged participants in the trust model. Segmentation that ignores those identities may look strong on paper but still leave high-value pathways open. The practical test is not whether the network is divided, but whether an attacker or misused automation can move from one clinical trust zone to another without detection.

For that reason, security teams should align segmentation design with NIST Cybersecurity Framework 2.0 and treat exceptions as controlled, reviewable risk decisions rather than permanent convenience settings.

Related resources from NHI Mgmt Group

• What do security teams get wrong about healthcare chatbot governance?
• What do security teams get wrong about non-human identities in healthcare?
• What do security teams get wrong about access compliance in healthcare?
• What do security teams get wrong about privileged access in healthcare and similar sectors?