The Wake-up Calls: How Real Medical Device Vulnerabilities Reshaped An Industry

<p class="wp-block-paragraph">For a long time, “medical device hacking” sounded like a hypothetical raised in academic papers and security conference talks — memorable, alarming, but distant from actual patient care. That changed as researchers, CISA, and the FDA began documenting a steady stream of real, disclosed vulnerabilities in devices that were already implanted in patients or deployed across hospital networks. Those disclosures, more than any single piece of legislation, are what pushed medical device cybersecurity from an afterthought into a mandatory part of getting a device to market.</p> <h2 id="h-the-cardiac-implant-case-that-changed-the-conversation" class="wp-block-heading"><strong>The Cardiac Implant Case That Changed the Conversation</strong></h2> <p class="wp-block-paragraph">In 2019, CISA and the FDA issued a joint advisory covering the Conexus telemetry protocol used in a range of Medtronic cardiac devices, including certain implantable defibrillators and pacemakers. The finding: the wireless communication between the implanted device and its external monitors and programmers lacked encryption and proper authentication. In theory, that meant an attacker within radio range could potentially intercept or interfere with the communication between a life-sustaining implant and the equipment used to monitor and adjust it.</p> <p class="wp-block-paragraph">Nothing about that finding suggested Medtronic’s engineers were careless — Conexus had been designed years earlier, under a threat model that didn’t anticipate the kind of proximity-based radio attacks security researchers were now demonstrating. But the disclosure sent a clear signal across the industry: proprietary “security by obscurity” radio protocols were no longer an acceptable substitute for real cryptographic protections, even in hardware that had already been implanted in thousands of patients.</p> <h2 id="h-infusion-pumps-a-recurring-target" class="wp-block-heading"><strong>Infusion Pumps: A Recurring Target</strong></h2> <p class="wp-block-paragraph">Infusion pumps — the devices that deliver medication, fluids, and nutrients directly into a patient’s bloodstream — have shown up in advisory after advisory. Between 2021 and 2023, multiple CISA advisories covered vulnerabilities in BD’s Alaris infusion pump systems, including authentication bypass issues and, in some cases, hard-coded credentials baked into the device’s software. In 2022, Baxter’s Sigma Spectrum infusion pump drew its own advisory (ICSMA-22-307-04) over Wi-Fi credential persistence and improper access control — meaning credentials used to join a hospital’s wireless network could remain accessible longer than intended, a serious concern when devices are redeployed, decommissioned, or move between care units.</p> <p class="wp-block-paragraph">Infusion pumps are a natural target for this kind of scrutiny. They combine two things that make cybersecurity failures dangerous: a network-connected interface (often Wi-Fi, for remote dosing library updates and integration with hospital records) and a direct physical link to patient treatment, where a manipulated dosing instruction could cause real harm. Reviewers and researchers alike have paid outsized attention to this device category as a result.</p> <h2 id="h-when-home-monitoring-meets-the-cloud" class="wp-block-heading"><strong>When Home Monitoring Meets the Cloud</strong></h2> <p class="wp-block-paragraph">Not every notable finding involves an implant or a pump. In 2020, the Medtronic MyCareLink Smart monitor — a home-based device that lets patients transmit data from their implanted cardiac device to their care team remotely — was the subject of an advisory involving improper authentication between the monitor and its associated cloud service. The concern was that certain functions of the monitor could potentially be impersonated by an attacker exploiting that weak authentication link.</p> <p class="wp-block-paragraph">This case is instructive because it illustrates a lesson that keeps recurring: the device itself and the cloud service it talks to have to be evaluated as a single system, not tested in isolation. A monitor that is perfectly secure on its own can still be undermined by a weak link in the cloud authentication chain it depends on — and vice versa.</p> <h2 id="h-from-disclosures-to-legislation" class="wp-block-heading"><strong>From Disclosures to Legislation</strong></h2> <p class="wp-block-paragraph">These weren’t isolated incidents happening in a vacuum. Collectively, disclosures like these — echoed across dozens of similar advisories catalogued by CISA’s ICS-Medical Advisory (ICSMA) program over the past decade — built the public and legislative case that voluntary cybersecurity guidance wasn’t sufficient. Congress responded by writing Section 524B into the Food, Drug, and Cosmetic Act in December 2022, giving the FDA explicit statutory authority to require cybersecurity documentation as a condition of premarket clearance, with enforcement beginning October 1, 2023.</p> <p class="wp-block-paragraph">The FDA’s subsequent guidance documents — most recently finalized in February 2026 — are effectively the agency’s answer to the pattern these incidents revealed: require manufacturers to build and document a threat model before the device ships, require a software bill of materials so vulnerable components can be tracked, require independent penetration testing that actually covers firmware and wireless interfaces (not just a superficial network scan), and require a documented plan for how vulnerabilities discovered after launch will be triaged and patched.</p> <h2 id="h-the-researchers-who-forced-the-issue" class="wp-block-heading"><strong>The Researchers Who Forced the Issue</strong></h2> <p class="wp-block-paragraph">It’s worth crediting the specific mechanism that surfaced most of these findings in the first place: independent security researchers, often working outside the medical device industry entirely, probing devices they had legitimate access to and reporting what they found through coordinated disclosure channels. CISA’s ICS-Medical Advisory program exists largely to formalize that process — giving researchers a structured way to report findings to manufacturers and the agency, and giving manufacturers a defined window to develop and ship a fix before public disclosure.</p> <p class="wp-block-paragraph">That disclosure culture has matured considerably over the past decade. Early on, the medical device industry had a reputation, not entirely undeserved, for treating security disclosures adversarially — responding to researchers with legal threats rather than engineering fixes. The shift toward structured coordinated vulnerability disclosure programs, now a required element under Section 524B(b)(2), reflects a hard-won recognition that researchers finding these flaws before attackers do is a benefit to patient safety, not a threat to be suppressed. Manufacturers that still lack a functioning CVD program — a public intake channel, a defined response SLA, and a real triage process behind it — are increasingly finding that gap flagged directly in FDA deficiency letters, not just criticized by the security research community.</p> <h2 id="h-why-the-history-still-matters-today" class="wp-block-heading"><strong>Why the History Still Matters Today</strong></h2> <p class="wp-block-paragraph">None of these incidents happened because the manufacturers involved were unusually careless. They happened because the discipline of testing a device the way an attacker with radio access, physical proximity, or network presence actually would is different from — and harder than — a standard IT security assessment. That gap between “we tested it” and “we tested it the way it will actually be attacked” is precisely what specialist firms exist to close.</p> <p class="wp-block-paragraph">Companies like<a href="https://bluegoatcyber.com/"> Blue Goat Cyber</a> built their practice specifically around this history — treating firmware extraction, wireless protocol fuzzing, and hardware interface testing as standard parts of a medical device engagement, rather than optional add-ons, because the public record of advisories makes clear those are exactly the areas where real devices have failed before.</p> <p class="wp-block-paragraph">For manufacturers building the next generation of connected devices, the lesson from a decade of public advisories isn’t abstract: the attack surface that matters is the one attackers have already demonstrated works, and it rarely looks like a corporate IT network. Building — and testing — around that reality, before a device reaches patients, is the difference between a footnote in an FDA submission and a footnote in the next advisory.</p> <p class="wp-block-paragraph"></p>