Medical IoT Network Segmentation: Protecting Connected Devices Without Disrupting Care

What happens when a patient monitor with nine identified cybersecurity vulnerabilities is connected to the same environment that clinicians depend on for day-to-day care? That is not a hypothetical scenario.

In 2025, the FDA classified a recall involving the Contec CMS8000 patient monitor because of identified cybersecurity vulnerabilities. The manufacturer’s immediate mitigation instructions included network segmentation and firewall controls to isolate affected devices and restrict communications. The FDA had separately warned that vulnerabilities in certain Contec and Epsimed monitors could permit remote control, device malfunction, and patient-data exfiltration.

The case highlights the problem healthcare security leaders face every day.

A compromised laptop can often be reimaged, patched, or isolated. An infusion system, patient monitor, imaging modality, laboratory analyzer, or other network-connected medical device may be actively supporting patient care. It may run an embedded or legacy operating system, depend on vendor-controlled software, communicate with several clinical systems, and be unable to support a standard endpoint security agent.

Simply “putting medical devices on another VLAN” is therefore not enough.

Effective medical device network segmentation must reduce an attacker’s ability to move through the network while preserving the communications that make clinical workflows work.

This guide explains how to build that architecture safely.

What Is Medical Device Network Segmentation?

Medical device network segmentation separates connected medical and Internet of Medical Things assets into controlled security zones and limits communication between those zones, other hospital systems, external services, and individual devices.

The objective is not complete isolation. It is controlled connectivity.

A bedside monitor may need to communicate with its central monitoring system. An imaging modality may need services such as identity, time synchronization, and connectivity to imaging infrastructure. A connected clinical device may require approved manufacturer services for maintenance or software updates.

But none of those requirements mean the device should automatically be able to communicate with every workstation, server, printer, camera, building-control system, or other medical device on the healthcare network.

HHS’s current Healthcare and Public Health Cybersecurity Performance Goals describe network segmentation as separating mission-critical assets into discrete segments to reduce lateral movement after an initial compromise. The goals are voluntary healthcare-specific cybersecurity practices rather than standalone regulatory mandates.

The basic model becomes:

Device → approved clinical systems → required shared services → approved external services

Everything else should be evaluated rather than implicitly trusted.

The Real Problem With Flat Medical Device Networks

A flat or overly permissive network gives compromised systems more opportunities to discover and communicate with assets that have nothing to do with their intended function.

Consider this simplified path:

Compromised endpoint → broad clinical network access → vulnerable IoMT device → device management system → additional clinical infrastructure

Network segmentation attempts to break that path.

CISA’s ransomware guidance recommends logical or physical segmentation and notes that segmentation can contain an intrusion and restrict lateral movement. CISA also recommends maintaining network diagrams that document connections, interdependencies, third-party access, cloud connections, and addressing schemes.

For healthcare environments, however, the correct question is not:

Which VLAN should this device use?

It is: Exactly what must this device communicate with to perform its clinical function safely?

That produces a much more defensible architecture.

Start With Device and Dependency Visibility, Not Firewall Rules

A segmentation project that begins by writing access-control rules is already starting too late. You first need to know what exists. 

For every connected medical device or clinically relevant device family, capture information such as:

Attribute	Why It Matters
Device type and clinical function	Determines expected behavior
Manufacturer and model	Supports vendor-specific requirements
Physical location	Helps map device to clinical workflows
MAC/IP/network identity	Supports discovery and enforcement
Operating system/firmware	Supports vulnerability assessment
Device owner	Establishes clinical/technical accountability
Clinical criticality	Influences containment decisions
Internal destinations	Identifies required hospital dependencies
External destinations	Identifies cloud/vendor dependencies
Protocols/interfaces	Supports least-privilege policy creation
Support/end-of-support status	Identifies legacy risk
Remote-access requirements	Exposes third-party pathways
Security advisories/SBOM data where available	Improves vulnerability context

The inventory should not live only inside the network team’s spreadsheet.

For larger healthcare organizations, medical-device information typically has to be reconciled across clinical engineering or Healthcare Technology Management, the Computerized Maintenance Management System, IT asset inventories, network access control, cybersecurity monitoring, procurement, and vendor-management processes.

HICP recommends maintaining medical-device hardware and software inventories and notes the value of integrating automated discovery data with a CMMS to operationalize maintenance, remediation, security orchestration, and incident response.

That creates the foundation for segmentation.

Step 1: Baseline How Each Device Actually Communicates

After discovery, observe communication before restricting it.

For a device family, determine: Device → destination → protocol/service → direction → purpose → owner

For example:

Source	Destination	Purpose	Policy Decision
Bedside monitor	Central monitoring platform	Patient monitoring	Allow
Medical device	DNS/NTP/DHCP infrastructure	Core network service	Allow as required
Imaging modality	Approved imaging systems	Clinical image workflow	Allow
Medical device	Manufacturer update service	Approved maintenance	Restrict and monitor
Medical device	Random workstation subnet	No documented need	Deny
Medical device	Another unrelated IoMT family	No clinical dependency	Deny

Do not blindly copy port lists from another hospital or online template.

FDA’s February 2026 medical-device cybersecurity guidance recommends that manufacturers document communication paths, interfaces, protocols, ports or channels, approved endpoints, authentication methods, and supporting infrastructure requirements. It also recommends detailed architecture diagrams that make data, command, and communication pathways understandable.

Those manufacturer materials, product documentation, MDS2 information where available, clinical-engineering knowledge, and observed traffic should inform the hospital’s policy.

The goal is a verified communication matrix, not an assumed one.

Step 2: Build Clinical Security Zones

A common mistake in healthcare network segmentation is creating one large “medical device VLAN.” 

That separates IoMT from corporate endpoints, but it does not necessarily protect medical devices from each other. A more mature design uses multiple trust boundaries based on function, criticality, risk, and communication requirements. A conceptual healthcare architecture might separate:

General enterprise endpoints

Corporate laptops, desktops, office infrastructure, and general workforce systems.

Clinical user endpoints

Nursing workstations, clinical carts, and other endpoints that interact with clinical applications.

Medical devices

Further divided where appropriate into logical device groups such as monitoring, medication-management equipment, laboratory devices, or other clinically coherent categories.

Imaging

Modalities and supporting imaging infrastructure may warrant separate treatment because of their specialized workflows, bandwidth requirements, and dependencies.

Clinical application infrastructure

Systems supporting EHR-connected workflows, interface services, device-management platforms, PACS or related services.

Facilities/OT/IoT

Building management, cameras, badge systems, environmental controls, and nonmedical IoT.

Guest and unmanaged devices

Patient, visitor, and otherwise untrusted endpoints.

Vendor-management paths

Controlled pathways for approved external support. The exact zones will differ by organization.

The point is to design boundaries around real communication relationships, rather than organizational labels alone.

Step 3: Enforce Least-Privilege Communication Between Zones

Creating VLANs separates broadcast domains. It does not automatically create a complete security boundary. Effective segmentation generally requires an enforcement mechanism such as:

• firewalls between security zones;
• routed access-control lists;
• software-defined or identity-based policy controls;
• Network Access Control (NAC);
• security-group or role-based policy;
• or microsegmentation technologies.

The policy should increasingly move toward: Allow documented required communication. Deny unnecessary communication. HICP similarly recommends default-deny rules where possible and specifically advises restricting medical-device traffic to the technologies needed for the device’s function.

This distinction matters.

A device located inside a “trusted medical VLAN” should not become trusted merely because of its subnet. That is also consistent with NIST Zero Trust Architecture. NIST defines zero trust as removing implicit trust based solely on physical or network location and evaluating access to resources instead.

So: Segmentation ≠ Zero Trust. Segmentation provides boundaries.

Zero Trust pushes organizations toward verifying identities, devices, communication context, and authorization rather than treating location as sufficient evidence of trust.

Step 4: Microsegment Where the Risk Justifies It

Macrosegmentation might prevent a pharmacy device network from reaching corporate workstations. Microsegmentation goes further. It can prevent unnecessary communication between systems inside the same broader security zone. This is particularly useful for purpose-built medical devices because many have relatively predictable communication patterns.

Two unrelated infusion pumps generally do not require unrestricted peer-to-peer communication simply because they belong to the same device family. HICP notes that microsegmentation can prevent an attacker who has penetrated one traditional segment from moving laterally because unnecessary communication is restricted. It also acknowledges the operational challenge: manually maintaining highly granular policies across tens of thousands of devices can become impractical.

That is why large healthcare organizations often combine: passive IoMT discovery → behavioral profiling → policy recommendation → NAC/firewall enforcement → continuous validation

instead of maintaining thousands of static rules manually.

Step 5: Treat Vendor Remote Access as Its Own Security Boundary

Medical devices frequently require manufacturer maintenance. That can become one of the most dangerous exceptions in an otherwise well-designed segmentation architecture.

Avoid granting a third party permanent broad access to the clinical network merely because they service a device. Where technically feasible, vendor access should be:

authenticated → authorized → restricted → time-bound → monitored → logged

The vendor should reach only the systems necessary for the approved support activity.

A common architecture uses a controlled access layer such as a VPN or secure-access service combined with MFA, privileged-access controls, or a managed jump host, followed by a tightly restricted path to the target device or management environment.

HICP recommends limiting vendor access based on need, restricting access to required information, and segmenting third-party access from the rest of the corporate environment.

Remote support should therefore be designed as a governed workflow, not a firewall exception that never expires.

How to Segment IoMT Without Breaking Clinical Care

This is where implementation discipline matters most.

Preserve device dependencies

Before enforcement, verify:

• DNS
• DHCP
• time synchronization
• application servers
• clinical gateways
• imaging dependencies
• middleware
• manufacturer services
• authentication infrastructure
• cloud endpoints
• management platforms
• software-update mechanisms

HICP specifically warns organizations not to limit essential medical-device functionality, including remote patching where required.

Account for broadcast, multicast, and “silent” devices

Some clinical devices do not behave like conventional managed computers.

Current Cisco healthcare network validation documentation, for example, explicitly addresses multicast services and “silent medical device” behavior that can depend on ARP or Layer 2 flooding.

That does not mean every healthcare network requires the same implementation.

It means network architects must test whether segmentation changes Layer 2 behavior, discovery, multicast, roaming, or other communication patterns a device depends on.

Validate wireless mobility

Portable clinical devices may move between floors, nursing units, or access points while maintaining clinical communications.

A segmentation policy that works only while a device is connected to one physical switch port can create operational problems when the same device roams.

Identity- or role-aware policies can help make controls more consistent across network locations.

Test high-availability behavior

Do not validate only the normal path. Test:

• redundant controllers;
• firewall failover;
• network-path failover;
• DNS/NTP failure;
• WAN outage;
• cloud-service disruption;
• vendor-service unavailability;
• and clinical downtime procedures.

Healthcare availability is part of the security requirement.

Use Monitor-Only Enforcement Before Blocking Traffic

One of the safest ways to introduce IoMT network segmentation is to separate policy discovery from policy enforcement. A practical rollout looks like this:

Discover → observe → model → validate → simulate → pilot → enforce → monitor

Start with passive observation. Build expected flows. Review them with networking, cybersecurity, clinical engineering, application owners, and clinical stakeholders.

Then pilot enforcement on a limited device family, site, unit, or noncritical cohort before expanding.

During the pilot, explicitly verify:

• patient data arrives at the intended system;
• alarms and monitoring continue;
• device-to-EHR workflows remain intact;
• imaging or laboratory workflows complete;
• roaming works;
• manufacturer maintenance still works;
• software updates remain possible;
• failover works;
• and clinical users see no unintended workflow change.

A security policy is not production-ready merely because the firewall accepts the configuration.

It is production-ready when clinical functionality remains validated after enforcement.

Do Not Automatically Quarantine Every “High-Risk” Medical Device

Automated containment sounds attractive. In healthcare, it requires clinical context. If a laptop begins exhibiting ransomware behavior, immediate network isolation may be straightforward.

If a bedside device involved in active monitoring does something anomalous, abruptly removing all connectivity could create a different patient-safety risk.

Build response policies around categories.

For example:

Low clinical criticality + confirmed malicious behavior → automatic isolation may be appropriate.

High clinical criticality + suspicious traffic → block malicious/external communication while preserving required clinical paths, alert the SOC and clinical engineering team, and initiate the approved response process.

Life-supporting or highly critical workflow → escalation and predefined clinical contingency procedures may be required before full isolation.

The containment policy should therefore consider both:

cybersecurity severity × clinical consequence

That is one of the most important differences between generic IoT security and medical IoT security.

Where HIPAA, HHS, and FDA Fit in 2026

Healthcare organizations should be precise about the regulatory context.

Current HIPAA Security Rule

As of August 2026, HHS states that the current HIPAA Security Rule remains in effect and requires regulated entities to implement administrative, physical, and technical safeguards to protect electronic protected health information. Technical safeguards include access control, audit controls, integrity protections, authentication, and transmission security.

Network segmentation can support that broader security program.

But it is important not to claim that the currently effective HIPAA Security Rule explicitly mandates network segmentation in every environment.

Proposed HIPAA Security Rule changes

OCR’s December 2024 NPRM proposed several stronger requirements, including technology asset inventories, network maps, vulnerability scanning, penetration testing, MFA, and network segmentation. As of HHS’s currently published regulatory materials, these remain proposed changes, not the rule presently in force.

That distinction matters for compliance accuracy.

HHS Healthcare Cybersecurity Performance Goals

HHS’s healthcare-specific CPGs are voluntary, but they explicitly identify network segmentation as a high-impact cybersecurity practice for protecting mission-critical systems from lateral movement.

FDA

FDA’s current February 2026 medical-device cybersecurity guidance primarily governs manufacturer cybersecurity considerations and premarket submission content. It should not be presented as a hospital network-segmentation regulation.

However, its requirements and recommendations are highly useful to healthcare delivery organizations because they reinforce the need for well-understood device architecture, interfaces, communication pathways, ports, approved endpoints, security controls, and patchability.

Security teams should increasingly request this information during device procurement, not after a vulnerability is discovered.

Medical Device Segmentation Should Make the Network Smaller for an Attacker, not Harder for a Clinician

The strongest IoMT network segmentation strategy is almost invisible to the people delivering care. A nurse should not need an extra step because an infusion device moved into a better security zone.

A radiologist should not discover that an imaging workflow stopped because a firewall rule was deployed overnight. And the security team should not need to choose between unrestricted connectivity and unplugging every vulnerable device.

The better model is deliberate:

Know the device → understand the clinical dependency → define the minimum communication → enforce the boundary → validate patient-care workflows → monitor continuously.

That turns healthcare network segmentation from a collection of VLANs into a clinical-aware security control. And when the next vulnerable medical device appears, the organization already has something far more useful than a list of IP addresses:

It has a way to contain the risk without containing care.

Build Medical Device Segmentation Around Clinical Reality

CapMinds helps healthcare organizations assess connected-device environments, map clinical and network dependencies, design segmentation architecture, define least-privilege policies, and plan phased healthcare cybersecurity implementation without treating patient-care systems like ordinary IT endpoints.

Discuss Your IoMT Security Architecture