Subscribe to the Non-Human & AI Identity Journal

Why does microsegmentation matter for unpatchable medical devices?

Unpatchable devices need compensating controls because the normal fix cycle does not exist. Microsegmentation reduces the blast radius of compromise by limiting lateral movement around those devices, which is especially important when the endpoint cannot run an agent or be safely reconfigured. In practice, it becomes the main containment layer.

Why This Matters for Security Teams

Unpatchable medical devices turn a routine vulnerability problem into a containment problem. If the device cannot accept agents, firmware updates, or frequent reconfiguration, security teams must assume exposure will persist and design the network so compromise does not spread. microsegmentation matters because it constrains what the device can talk to, who can reach it, and which services can be reached from adjacent systems. That is consistent with the least-privilege direction in the NIST Cybersecurity Framework 2.0 and with the operational lessons NHIMG highlights in its Ultimate Guide to NHIs, where poor visibility and weak governance are recurring drivers of compromise.

The practical risk is not just device failure. Medical devices often sit inside mixed trust zones with imaging systems, nurse stations, identity services, and remote support paths. Once one endpoint is compromised, attackers may pivot to adjacent clinical systems, credentials, or management networks. Current guidance suggests treating unpatchable assets as high-value containment anchors rather than normal endpoints. In practice, many security teams discover the need for segmentation only after a vendor access path or flat VLAN has already enabled lateral movement.

How It Works in Practice

Microsegmentation applies policy at a finer level than traditional network zoning. Instead of trusting every host on a subnet, teams define explicit allow rules for the exact medical device, the management station, the protocol, and the destination service. That may be done with host-based controls, software-defined networking, or identity-aware network policy, but the goal is the same: reduce east-west movement and make every connection intentional.

A workable design usually starts with four questions:

  • What clinical function does the device need to perform?
  • Which servers, protocols, and ports are strictly required?
  • Which administrative paths are used for vendor support or maintenance?
  • What should be blocked by default, including peer-to-peer traffic?

From an identity perspective, unpatchable devices often depend on shared credentials, service accounts, or remote service tooling, which is why NHIMG’s research on credential leakage and lifecycle gaps is relevant. The GitHub Personal Account Breach and the SpotBugs Token GitHub Supply Chain Attack both underline a simple point: once trusted credentials or update paths are exposed, lateral access becomes the real problem. For this reason, microsegmentation should be paired with strict vendor access brokering, short-lived credentials where possible, logging of every management session, and continuous validation against the asset inventory.

The operational value is strongest when rules are built around clinical workflow, not just IP addresses. Teams should map the device to its controllers, backup systems, log collectors, and update sources, then test whether the device still functions when all other traffic is denied. This guidance tends to break down in legacy hospital networks that rely on shared subnets, broadcast discovery, or unmanaged third-party maintenance channels because those dependencies are difficult to enumerate and easy to overlook.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance containment against uptime, vendor support, and biomedical engineering constraints. That tradeoff is real in healthcare because some devices use legacy protocols, hard-coded destinations, or support models that were never designed for modern zero trust controls. Best practice is evolving, not universal, for how far to push microsegmentation when patient safety and vendor warranties are both in scope.

A few edge cases matter:

  • Some devices cannot tolerate active scanning or endpoint agents, so network policy becomes the only safe control surface.
  • Some environments need temporary exceptions for maintenance windows, but those exceptions should be time-bound and audited.
  • Segmentation is weaker if identity is not bound to access, because static IP allowlists can be bypassed by misrouted or reused infrastructure.
  • Clinical failover paths may require separate rules for backup imaging, telemetry, or medication systems, which should be documented before enforcement.

For governance, the important point is that segmentation is not a substitute for asset lifecycle management, but it is often the best compensating control when patching is impossible. Under NIST Cybersecurity Framework 2.0, it fits naturally alongside asset visibility, access control, and protective technology. In healthcare, the hardest cases are devices embedded in vendor-managed enclaves, because exceptions multiply quickly and policy drift quietly recreates the flat network you were trying to eliminate.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AC-5 Segmentation limits authorised communications to reduce lateral movement.
NIST Zero Trust (SP 800-207) SC-7 Zero Trust architecture emphasizes segmenting flows and reducing implicit trust.
NIST SP 800-53 Rev 5 AC-4 Information flow enforcement is the core control behind microsegmentation.

Restrict device communications to approved paths and verify the rules stay aligned with clinical need.