the ventilator has a password problem

Problem statement

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 premarket cybersecurity guidance (finalized September 2023, updated June 2025 and February 2026) and section 524B of the FD&C Act — added by section 3305 of the Consolidated Appropriations Act, 2023, effective March 29, 2023 — now require new submissions for "cyber devices" to include cybersecurity 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.

Why this matters

FDA oversees more than 6,500 different medical device products, manufactured at roughly 25,900 FDA-registered medical device facilities worldwide (FDA at a Glance, January 2024), and a significant fraction of fielded devices are networked — a January 2022 research report cited by the FBI found 53% of connected medical and other IoT devices in hospitals had known critical vulnerabilities (FBI PIN 20220912-001). Healthcare has had the highest average data-breach cost of any industry for 13 consecutive years, reaching $10.93 million in IBM's 2023 Cost of a Data Breach report. A successful attack on a safety-critical device — an infusion pump, a ventilator — could directly endanger patients. Since FDA began enforcing the new cybersecurity requirements on October 1, 2023, device-security firm MedCrypt reports a 700% increase in cybersecurity-related deficiency letters among the manufacturers it works with, and FDA has publicly stated that deficiency letters that include cybersecurity deficiencies carry an average of fifteen of them — indicating that even new submissions struggle to meet the standard.

What’s been tried and why it hasn’t worked

The FDA's September 2023 premarket guidance (since updated in June 2025 and February 2026 to address section 524B) 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. Section 524B (the enacted successor to the proposed PATCH Act) similarly requires cybersecurity plans, vulnerability monitoring, and an SBOM 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 hardware often remains active for 10-30 years while manufacturer-specified software life cycles end far earlier, and legacy devices no longer receive manufacturer support for patches or updates — leaving many running outdated, unsupported operating systems (FBI PIN 20220912-001).

What would unlock progress

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.

Entry points for student teams

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.