Medical device cybersecurity, end‑to‑end.

What "medical device cybersecurity" actually means.

Medical device cybersecurity is the discipline of protecting connected, software-driven medical devices from cyber threats across their entire lifecycle - design, premarket submission, manufacturing, clinical deployment, and postmarket. It spans every device that meets the three-part Section 524B definition: it contains software, it has the ability to connect to the internet, and it has technological characteristics that could be vulnerable to cybersecurity threats.

In practice that captures nearly every modern device - BLE-paired wearables, USB-charged hearing aids, cloud-connected infusion pumps, and most SaMD. Risk class is irrelevant. If the device meets the three conditions, the full medical device cybersecurity package is mandatory and the FDA can refuse to accept the submission without it.

The Secure Product Development Framework, end to end.

Every medical device cybersecurity program maps to the same five-phase SPDF loop. The premarket package the FDA reviews is the evidence trail this loop produces - not a separate deliverable.

The standards that define medical device cybersecurity.

• Section 524B of the FD&C Act - statutory baseline for every US cyber device submission (SPDF, SBOM, postmarket monitoring, patch delivery). See the FDA cybersecurity hub.
• FDA 2026 premarket cybersecurity guidance - how reviewers evaluate threat models, security architecture views, penetration testing, and labeling. Read the FDA guidance document.
• AAMI SW96 and AAMI TIR57 - the security risk management standards FDA reviewers expect to see referenced. AAMI standards catalog.
• IEC 81001-5-1 and IEC 62304 - secure software lifecycle and medical device software development.
• ISO 14971 - risk management that the cybersecurity risk file must integrate with, not bolt on to.
• NTIA SBOM minimum elements and CycloneDX / SPDX - SBOM format and content expectations. NTIA SBOM resources.

Need definitions? See the MedTech cybersecurity glossary or the FDA cybersecurity acronyms reference.

Examples of medical device cyberattacks.

Medical device cybersecurity is not theoretical. Public-record incidents and FDA / CISA advisories span four decades, from the 1985 Therac-25 radiation overdoses through to modern infusion-pump and pacemaker recalls. A full sourced timeline of 86+ events is maintained at Code Blue Chart, our public-record MedTech cyber timeline. A handful that every product team should know:

• St. Jude Merlin@home (2016-2017) - the FDA confirmed exploitable RF vulnerabilities in implantable cardiac devices, leading to a Class I recall of the transmitter and the first-ever cybersecurity firmware update for an implantable.
• Medtronic CareLink 2090 & MyCareLink (2018-2020) - the FDA issued multiple safety communications covering unauthenticated firmware updates and proprietary protocol weaknesses on cardiac programmers, ultimately taking products off the market.
• Becton Dickinson Alaris infusion pumps (2020-2021) - CISA ICS advisories documented hardcoded credentials and weak session handling impacting hospital-wide drug delivery infrastructure.
• Illumina Universal Copy Service (2023) - a critical CVSS 10.0 vulnerability in NGS sequencing instruments, one of the highest-severity CVSS 10.0 advisories ever issued for an FDA-cleared device, triggering a Class II recall.
• Contec CMS8000 patient monitors (2025) - the FDA and CISA warned of a hidden backdoor function transmitting patient data to a hard-coded external IP, an unprecedented public advisory for a marketed device.

The pattern is consistent: weak authentication, unsigned firmware, unmaintained third-party components, and missing postmarket monitoring. A modern medical device cybersecurity program is designed to make every one of those failure modes structurally hard.

Best practices for medical device cybersecurity.

Reviewer expectations, AAMI SW96, IEC 81001-5-1, and a decade of incident response converge on the same operating model. A defensible medical device cybersecurity program implements all of the following:

1. Anchor security in ISO 14971 risk management. Cybersecurity hazards belong in the same risk file as electrical and biocompatibility hazards, not in a parallel spreadsheet.
2. Operate a Secure Product Development Framework (SPDF). Design inputs, threat model, security requirements, V&V, and unresolved-anomaly disposition must trace end-to-end through the design history file.
3. Threat model every interface. Use STRIDE or an equivalent; document trust boundaries, attacker capability, and the control selected for each threat.
4. Maintain a machine-readable SBOM with VEX. CycloneDX or SPDX, refreshed at every build, with VEX statements that tell reviewers and customers which CVEs are actually exploitable.
5. Test like an attacker. Independent, manual penetration testing across hardware, firmware, wireless, mobile, web, and cloud - not just automated SAST/DAST.
6. Sign and gate every update. Code signing, secure boot, and rollback protection at the bootloader and OTA layers.
7. Run a postmarket vulnerability program. Monthly CVE triage against the SBOM, a published coordinated vulnerability disclosure (CVD) channel, MedWatch-reportable incident decisioning, and change-controlled patch delivery under 21 CFR Part 820.
8. Disclose for transparency. Cybersecurity labeling, an MDS2 form for healthcare-delivery procurement, and a stated software support duration.

US vs EU medical device cybersecurity rules.

US and EU regulators converge on the same goal - safe, resilient devices - but reach it through different instruments. A device shipped in both markets has to satisfy both bars.

Contact us about EU MDR / IVDR / CRA programs, including notified-body-ready packages and EU MDR threat modeling.

Who is responsible for medical device cybersecurity?

Responsibility is shared, but it is not symmetrical. The manufacturer is the accountable party for the security of the device itself; everyone else operates on top of that foundation.

• Manufacturers own design security, SPDF evidence, premarket submissions, the SBOM, postmarket vulnerability management, patch delivery, and coordinated vulnerability disclosure. Section 524B makes this statutory.
• Healthcare Delivery Organizations (HDOs) own network segmentation, identity and access management, patch deployment within their environment, and clinical risk acceptance for legacy devices. The HSCC MDS2 form is the procurement-level interface between the two.
• The FDA and CISA set expectations, screen submissions, issue safety communications and ICS advisories, and can compel recalls or Warning Letters when programs fail.
• Notified bodies (EU) assess technical documentation against MDR / IVDR cybersecurity requirements before CE marking.
• Third-party testing labs and consultancies (like Blue Goat Cyber) provide the independent threat modeling, penetration testing, and submission engineering that manufacturers and reviewers both rely on.

Frequently asked questions about medical device cybersecurity.