The Ventilator Has a Password Problem

Medical devices in clinical use — infusion pumps, ventilators, imaging systems, implantable cardiac devices, patient monitors — are increasingly networked and software-dependent, but the majority of the installed base was designed without cybersecurity controls. The FDA's 2023 premarket cybersecurity guidance and the PATCH Act (Section 524B) now require new submissions to include vulnerability management plans, but the installed base of legacy devices remains largely unpatched and unpatchable. There is no validated methodology for assessing and remediating cybersecurity risk across heterogeneous legacy device fleets in clinical environments.

Approximately 257,000 different types of medical devices are on the U.S. market, produced by roughly 22,000 manufacturing facilities worldwide, and a significant fraction are networked. The healthcare sector consistently ranks among the top targets for ransomware, with average breach costs exceeding $10 million. A successful attack on a safety-critical device — an infusion pump, a ventilator — could directly endanger patients. Since the new cybersecurity requirements took effect in October 2023, CDRH has seen a 700% increase in cybersecurity-related deficiency letters, with an average of fifteen specific concerns per letter, indicating that even new submissions struggle to meet the standard.

The FDA's September 2023 premarket guidance superseded 2014 guidance with detailed requirements for threat modeling, software bill of materials (SBOM), coordinated vulnerability disclosure, and cybersecurity risk assessment — but these apply only to new submissions. The PATCH Act (Section 524B) similarly requires cybersecurity plans in premarket submissions but does not mandate remediation of already-marketed legacy devices, creating a two-tier system where legacy devices operate under weaker protections indefinitely. Hospitals rely on network segmentation as a compensating control, but segmentation is imperfect and operationally burdensome across fleets of thousands of devices from dozens of manufacturers. SBOM standards are not yet mature enough for automated vulnerability correlation across the device supply chain. Manufacturers of legacy devices have limited economic incentive to issue patches for products generating no ongoing revenue. Medical device lifecycles (10-20 years) far exceed software support cycles (3-5 years), and many devices run legacy operating systems like Windows XP or old embedded Linux kernels that no longer receive security patches.

A lightweight, standardized risk-scoring framework for triaging cybersecurity vulnerabilities across heterogeneous medical device fleets would enable hospitals to prioritize remediation even without manufacturer cooperation. Automated asset discovery and SBOM analysis tools purpose-built for clinical environments could give hospitals visibility into what is actually running on their networks. A regulatory or economic mechanism that creates incentives (or mandates) for legacy device manufacturers to provide security updates — or at minimum, SBOMs — for fielded devices would close the gap between new and legacy requirements.

A student team could prototype an automated medical device network scanner that identifies connected devices, infers their software components, and maps them against known vulnerability databases (CVE/NVD) to produce a prioritized risk report. Another approach would be designing a network micro-segmentation policy generator specifically for clinical environments that balances security isolation with clinical workflow requirements. Teams with backgrounds in cybersecurity, networking, embedded systems, or healthcare IT would be well-suited. A scoped semester project could work with a simulated hospital network environment (e.g., using open-source medical device emulators) rather than requiring access to live clinical infrastructure.