The Medical Device Security Problem Nobody Wants to Own
In almost every healthcare network assessment, the same finding appears. Somewhere on the network (often on the same VLAN as user workstations or nursing station computers) there are infusion pumps, patient monitors, imaging workstations, or other medical devices running embedded operating systems with known vulnerabilities, no endpoint security agents, and no realistic path to patching.
The finding is documented. It's acknowledged. And then the conversation hits the wall of reality: biomed doesn't control these devices from an IT security perspective, clinical operations can't tolerate changes that risk disrupting patient care, and the FDA's medical device change control requirements mean that vendors may not approve or support firmware updates without going through a validation process that takes months or years. Nobody wants to own this problem. Biomed views it as an IT problem. IT views it as a biomed problem. Security views it as a vendor problem. And attackers view it as an opportunity.
Why Medical Devices Are Different
Medical devices represent a unique risk category that standard endpoint security frameworks don't address. They can't be patched on normal cycles — FDA-cleared devices often require re-validation after firmware updates, which means vendors may release patches infrequently or not at all for end-of-life devices. An infusion pump with a 10-year clinical life may be running software that the vendor stopped supporting at year 5.
They can't run security agents. Endpoint detection and response tools require an operating environment that medical device software doesn't support. You can't install CrowdStrike on an infusion pump. The device remains entirely invisible to endpoint security tooling.
They are well-documented attack targets. Shodan, healthcare security researchers, and threat actor groups have published detailed information about vulnerabilities in specific medical device models. The attack surface isn't theoretical; it's cataloged. They are frequently on flat networks, and a compromise has patient care implications that make the risk category categorically different from standard enterprise IT risk.
A Network-Layer Security Architecture
Because endpoint-level controls don't apply, the security architecture for medical devices lives entirely at the network layer. The approach combines visibility, segmentation, and traffic monitoring in a defense-in-depth model that doesn't require touching the devices themselves.
First, discover what you have. Most healthcare organizations have incomplete medical device inventories. Passive network discovery using telemetry from network switching infrastructure and flow analysis builds this inventory from network behavior without requiring access to the devices. Network observability platforms can identify device types, manufacturers, and communication patterns from traffic analysis alone.
Next, design a segmentation model that reflects clinical function. Medical devices don't all carry the same risk profile, and they don't all require the same communication patterns. Infusion pumps typically communicate with pharmacy systems. Patient monitors communicate with clinical workstations and EMR. Imaging systems communicate with PACS. The segmentation model should group devices by function with firewall enforcement at segment boundaries.
Enforcement and Monitoring
Application identification allows firewall policy to be expressed in terms of application behavior rather than port and protocol. An infusion pump that only communicates with the pharmacy system over a specific protocol can be enforced that way; traffic to unexpected destinations is blocked and logged. This doesn't require changes to the devices; it requires correct firewall policy at the segment boundary.
Once segmentation establishes the baseline communication pattern, monitoring can detect deviations. A medical device that starts making DNS lookups to external addresses, generating traffic to IT management systems, or communicating with other devices in unexpected patterns is detectable as an anomalous event. IVI's secure networking and NDR capabilities provide this behavioral detection layer for healthcare environments.
For devices with known CVEs that can't be patched, documented network-layer compensating controls (segmentation, communication policy enforcement, anomaly monitoring) satisfy the framework requirements that HIPAA risk analysis and HITRUST assessments apply to unpatched vulnerabilities.
Working Within Clinical Constraints
Healthcare IT operates under constraints that generic security advice doesn't account for. Change management processes require clinical informatics review. Biomed teams need to validate that network changes don't affect device function. Some devices have service contracts that restrict what network configuration changes are permissible.
IVI's approach to medical device security engagements is purpose-built around these constraints. The segmentation design process explicitly involves biomed as a stakeholder, documenting communication requirements from biomed's perspective, reviewing enforcement policy with the biomed team, and testing that device function is preserved after segmentation before cutover. The discovery methodology is passive. No changes are made to devices, and no access requires biomed approval.
The goal isn't to implement security controls that the clinical environment can't sustain. It's to implement network-layer controls that measurably reduce the attack surface represented by unagentable, unpatched devices, using the tools available at the one layer where controls can be applied consistently.
Resolving the Ownership Question
At some point, the governance question has to be resolved: who owns the security posture of connected medical devices? The answer is almost always joint. IT owns the network security architecture, biomed owns device procurement and maintenance, clinical operations owns the availability requirement, and compliance owns the documentation obligation. All four parties need to be at the table for the work to get done.
IVI's engagements with healthcare organizations on medical device security are structured to involve all four stakeholders, which is why the assessment phase includes stakeholder interviews and the design phase includes cross-functional review before anything is implemented. The segmentation architecture that nobody owns doesn't get built. The one that has clear stakeholder alignment does.
This cross-functional approach extends to ongoing operations. Aegis managed services can provide the 24/7 monitoring and incident response capabilities that healthcare organizations need for medical device security, while maintaining the clinical workflow integration that biomed teams require.
Key Takeaways
- Passive network discovery builds complete medical device inventories without requiring device access or biomed approval
- Segmentation by clinical function (infusion pumps, patient monitors, imaging) is more sustainable than generic device groupings
- Application-aware firewall policies provide more precise enforcement than port-based rules for medical device communications
- Network-layer compensating controls can satisfy compliance requirements for unpatched medical device vulnerabilities
- Cross-functional stakeholder alignment between IT, biomed, clinical operations, and compliance is essential for sustainable medical device security