Medical Device Network Security: Securing IoMT Without Disrupting Patient Care

The IoMT Security Problem in Plain Terms

When an employee's laptop gets a security vulnerability, IT patches it. When an infusion pump, patient monitor, or radiology workstation has a vulnerability, the options are much worse:

• The device runs a proprietary OS that the vendor controls — you can't apply patches yourself
• Patching requires an FDA clearance process that takes months to years
• Many devices are no longer supported by vendors who sold them 5–10 years ago
• Taking a device offline to patch it may disrupt patient care

The FDA's 2023 cybersecurity guidance now requires premarket submissions to include a Software Bill of Materials (SBOM) and a patch management plan. But this only applies to new devices — the installed base of legacy devices remains largely unaddressed.

What Attackers Do With Medical Device Access

The goal isn't usually to interfere with devices directly — it's to use them as network pivot points. A medical device on the same network segment as EHR workstations provides attackers a path to patient data. Documented attack patterns include:

• Using compromised imaging workstations as lateral movement staging points
• Exploiting DICOM server vulnerabilities to access connected file systems
• Compromising building management systems (HVAC, access control) that share network segments with clinical systems
• Using nurse call system vulnerabilities to reach other networked devices

Network Segmentation: The Primary Defense

Since you can't patch most medical devices, the answer is isolation. Proper segmentation means:

1. Complete device inventory first. You can't segment what you don't know about. Use a network discovery tool (or ask your IT provider) to enumerate every connected device — including devices that only connect occasionally.
2. VLAN isolation by device class. Create separate network segments for: clinical workstations, medical devices, building management systems, and guest/patient Wi-Fi. Each segment should have explicit firewall rules for what traffic is allowed in and out.
3. Micro-segmentation where possible. Devices that only need to communicate with one server (e.g., an infusion pump that reports to a specific drug library server) should be restricted to only that communication path.
4. No internet access for devices unless required. Most medical devices have no legitimate reason to access the internet directly. Vendor remote access should go through a managed jump server, not direct device internet access.

Passive Monitoring: Seeing What's Happening Without Disrupting Devices

Traditional endpoint security agents can't run on medical devices. Passive network monitoring (sometimes called "agentless security") watches network traffic without touching the devices themselves:

• NDR (Network Detection and Response) tools like Claroty, Medigate, or Armis are purpose-built for healthcare IoMT environments. They identify device types, map communication patterns, and alert on anomalies.
• SIEM integration: Medical device network events should feed your security event management system so anomalies (a device suddenly communicating with an external IP) trigger immediate alerts.
• Baseline behavior profiling: Know what "normal" looks like for each device type so you can detect when something changes.

Vendor Management for Medical Device Security

Every medical device vendor with remote access to your network is a potential attack vector. Before granting vendor access:

• Require a signed Business Associate Agreement if the vendor accesses PHI
• Document exactly what systems the vendor needs to access and why
• Use a privileged access management (PAM) solution or jump server for vendor sessions — never give vendors direct VPN access
• Require the vendor to provide their patch timeline for known vulnerabilities on devices they've sold you
• Ask for the device's SBOM (Software Bill of Materials) — any vendor selling devices after 2023 should have this

A healthcare-specialized IT provider should have a documented process for onboarding medical device vendors. If your current IT team doesn't have this, it's a gap worth addressing before your next OCR audit.

What to Document for HIPAA Compliance

The HIPAA Security Rule's technical safeguards section doesn't specifically mention IoMT, but your security risk analysis must account for all ePHI — including data transmitted or stored by medical devices. Your documentation should include:

• Complete inventory of connected medical devices with OS version and patch status
• Network segmentation diagram showing device isolation
• Vendor access log with session-level detail
• Device-specific risk assessment for any device touching ePHI

Frequently Asked Questions

Are my infusion pumps actually a cybersecurity risk?

Yes. The FDA has issued multiple cybersecurity advisories for infusion pump lines from major manufacturers including Baxter, BD, and ICU Medical. The primary risk is network pivot — an attacker using the pump as a staging point to reach other systems — rather than direct device manipulation.

Do I need specialized IoMT security software?

For hospitals and larger practices with significant device footprints, purpose-built IoMT security platforms (Claroty, Medigate, Armis) provide visibility that generic network tools can't match. For small practices with a handful of devices, proper VLAN segmentation combined with firewall logging may be sufficient.

What do I do about devices that are completely unsupported and can't be patched?

Isolate them aggressively. A device on an isolated VLAN with no internet access and strict firewall rules that allow only necessary traffic is significantly less risky than an unpatched device on a flat network. Document the risk in your risk analysis and include it in discussions about device replacement timelines.