How should hospitals segment networks when medical devices cannot run endpoint agents?

How to Segment a Clinical Network When Devices Cannot Run Agents

Hospitals should segment around what each device must reach, not around what an endpoint agent can observe. That means treating medical devices as fixed-purpose assets, placing controls at switches, firewalls, VLANs, and NAC policy points, and using device identity, protocol allowlists, and clinical workflow constraints to limit east-west movement without interrupting care.

A useful starting point is to classify devices by function and risk, then build zones around those classes. Imaging systems, infusion pumps, lab analyzers, nurse stations, and guest or administrative systems should not share the same trust zone unless there is a clear clinical reason. The tighter the destination list, the smaller the blast radius if a device is misused or compromised.

Hospitals also need to distinguish between segmentation that blocks traffic and segmentation that supports care. A device may need to talk only to a PACS server, a middleware broker, or a specific update service. Good segmentation preserves that narrow path while denying everything else. When device software is old, fragile, or vendor-managed, network controls become the practical enforcement layer.

Build Policies from Device Identity and Clinical Context

Without endpoint agents, policy has to be driven by external evidence. The most reliable inputs are device type, MAC or certificate-based identity, switch location, known IP ranges, and the communication patterns the device actually uses in production. Hospitals should baseline those patterns first, then turn observed necessity into policy rather than guessing from a procurement sheet or a vendor statement.

Clinical context matters because not all communication is equally critical. A device used in an operating theatre, an intensive care unit, or a radiology workflow may need higher availability and more careful change control than a back-office workstation. The policy should therefore specify who can talk to the device, what the device can initiate, and which exceptions are temporary, approved, and logged.

Where possible, zero trust segmentation principles apply well here: verify each request, remove standing reachability where it is not needed, and keep policy decisions close to the enforcement point. That same mindset helps when the asset itself cannot be instrumented.

For network devices and appliance-like endpoints, configuration hygiene also matters. Hospitals should treat unmanaged medical gear as part of the secure configuration problem and align segmentation with CIS Benchmarks where the device stack supports hardening, logging, or segmentation-safe settings.

What Good Network Segmentation Looks Like in Practice

Practical segmentation is usually a layered model: medical devices in their own zone, support services in a separate zone, and only tightly scoped traffic allowed between them. A common pattern is deny by default at the east-west layer, permit only the required protocol and destination, and place any shared broker, update server, or integration engine in a controlled intermediary segment.

This is where hospitals benefit from NIST Cybersecurity Framework 2.0 discipline, especially around identifying assets, protecting them with least-privilege controls, and recovering cleanly from containment events. It is also why NIST SP 800-207 Zero Trust Architecture remains relevant even in environments that cannot deploy endpoint software, because trust is shifted from the host to the policy boundary.

For devices that authenticate with certificates, service accounts, or other machine credentials, the policy should assume those credentials can be stolen and should therefore constrain where they work. That is one reason OWASP API Security Top 10 is a useful adjacent reference when devices and middleware exchange data through exposed interfaces, especially where authorization depends on the calling system rather than the human operator.

Risk and Threat Considerations

Medical networks become fragile when segmentation is broad, static, or built around exceptions. If a device can reach more destinations than it truly needs, lateral movement becomes much easier after a compromised workstation, vendor jump host, or device credential is abused. The same weak boundary can also turn routine maintenance access into an unintended bridge into clinical systems.

Failure mechanism: flat or over-permissive network paths let attackers, malware, or rogue tools pivot between devices, reuse trust relationships, and reach systems that were never meant to be directly reachable.

Impact: disruption of care workflows, unauthorized device manipulation, exposure of patient data, and a larger incident footprint because containment has to happen at the network layer instead of on the endpoint.

Practitioner Guidance

What to prioritise: start with the highest-risk and most connected device classes, then segment outward from there. Imaging, infusion, laboratory, and vendor-supported devices usually reveal the most important communication paths and the highest consequence if they are overexposed.

What to verify: confirm that each allowed flow is tied to a specific clinical purpose, a known source, and a known destination. If a rule cannot be explained in those terms, it is usually too broad.

Common mistake: using VLANs as the whole control. A VLAN is only a boundary if routing, firewall policy, and monitoring enforce the same design intent. Without that, segmentation becomes an address-labeling exercise rather than a security control.

Practitioner takeaway: when endpoint agents are impossible, the network must carry the security burden, and the safest policy is the one that can be justified by observed device behaviour and actual clinical necessity.

Related resources from NHI Mgmt Group

• How should security teams govern devices that cannot run endpoint agents?
• What fails when hospitals try to segment medical networks with legacy tools?
• Why do autonomous agents increase identity risk when they run on employee devices?
• What breaks when organisations cannot see AI agents across devices and browsers?