What is medical device cybersecurity?
Medical device cybersecurity is the practice of protecting connected devices, their software, and patient data from attacks that could cause harm. FDA cybersecurity compliance is now a gating factor for clearance. Since Section 524B took effect, every cyber device submission must include a Secure Product Development Framework, SBOM, threat model, penetration testing, and a postmarket vulnerability program. This pillar is the map to all of it. Need hands-on help? See our medical device cybersecurity services.
- Section 524B made cybersecurity a gating factor for every cyber device submission - missing items trigger an immediate Refuse to Accept.
- A complete package = threat model + SBOM/VEX + security architecture views + third-party pen test + SPDF evidence + postmarket plan.
- Risk class is irrelevant. A Class I BLE-paired wearable carries the same documentation bar as a Class III implantable.
- Postmarket monitoring is a 5-10 year program, not a deliverable - CVE triage, VEX updates, and patch delivery for the life of the device.
- Clean-on-arrival packages clear in the normal review window. Deficient packages add 90-180 days per AI round.
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 six pillars of a medical device cybersecurity program.
Each pillar links to a deep-dive guide or service so you can go as deep as you need.
Section 524B compliance
FDA's statutory cybersecurity requirements for every cyber device submission - what is required, who qualifies as a cyber device, and how reviewers evaluate it.
Explore Section 524B complianceSBOM & VEX
Machine-readable SBOM in CycloneDX or SPDX, with VEX statements that tell reviewers which CVEs are actually exploitable in your device's context.
Explore SBOM & VEXThreat modeling
STRIDE-based threat modeling for medical devices, with trust boundaries, attack surface mapping, and traceability into design controls.
Explore Threat modelingPostmarket monitoring
Monthly CVE triage, coordinated vulnerability disclosure, change-controlled patch delivery, and incident response - for the life of the device.
Explore Postmarket monitoringPenetration testing
Independent, exploit-driven testing across hardware, firmware, wireless, BLE, mobile, web, and cloud back end - with a signed Letter of Attestation.
Explore Penetration testingPremarket package
End-to-end medical device cybersecurity package, eSTAR-ready and reviewer-tested across 275+ FDA submissions with a no-cost deficiency resolution commitment.
Explore Premarket packageFDA cybersecurity requirements and the standards behind medical device cybersecurity compliance.
- 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:
- 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.
- 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.
- Threat model every interface. Use STRIDE or an equivalent; document trust boundaries, attacker capability, and the control selected for each threat.
- 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.
- Test like an attacker. Independent, manual penetration testing across hardware, firmware, wireless, mobile, web, and cloud - not just automated SAST/DAST.
- Sign and gate every update. Code signing, secure boot, and rollback protection at the bootloader and OTA layers.
- 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.
- 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.
| Topic | United States (FDA) | European Union |
|---|---|---|
| Statutory basis | Section 524B of the FD&C Act (added by FDORA, Dec 2022; RTA effective March 29, 2023) | EU MDR Annex I §17 / IVDR; NIS2; CRA (2027) |
| Guidance | FDA 2026 premarket cybersecurity final guidance; 2016 postmarket guidance | MDCG 2019-16 Rev.1; Team-NB position papers |
| Lifecycle standard | AAMI SW96, AAMI TIR57, IEC 81001-5-1 | IEC 81001-5-1, IEC 62304, ISO 14971 |
| SBOM | Mandatory (§524B(b)(3)) - CycloneDX or SPDX | Expected by notified bodies under MDR/IVDR; mandatory under CRA |
| Postmarket reporting | MedWatch; FDA cyber incident decision logic | EUDAMED vigilance + NIS2 incident notification (24/72 hr) |
| Gatekeeper | FDA reviewer (RTA + substantive review) | Notified body (technical documentation review) |
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.
The MedDevice Cyber Podcast.
Christian Espinosa and guests unpack Section 524B, threat modeling, SBOM strategy, and real FDA deficiency letters - weekly episodes drawn from active premarket submissions.
Frequently asked questions about medical device cybersecurity.
Pressure-test your program before a reviewer does.
Free, no-signup tools that mirror how FDA actually reviews cyber devices.
Related medical device cybersecurity resources.
Original research & datasets
Anonymized findings from 275+ FDA submissions: deficiency patterns, timing impact, and AI/ML SaMD vulnerabilities.
Read Original research & datasets510(k) cybersecurity requirements
What the FDA expects in the cybersecurity section of every 510(k) submission.
Read 510(k) cybersecurity requirementsPMA & De Novo cybersecurity
Higher-risk submission pathways and the medical device cybersecurity bar they require.
Read PMA & De Novo cybersecurityFDA deficiency response
180-day clock running? Diagnose, remediate, and respond to FDA cyber deficiencies.
Read FDA deficiency responseCycloneDX vs SPDX
Choosing an SBOM format the FDA accepts and reviewers can actually parse.
Read CycloneDX vs SPDXAAMI SW96 vs TIR57
Two foundational AAMI standards for medical device cybersecurity risk.
Read AAMI SW96 vs TIR57FDA cybersecurity acronyms
Quick-reference glossary: SPDF, SBOM, VEX, RTA, eSTAR, SaMD, and more.
Read FDA cybersecurity acronymsBuild a medical device cybersecurity program ready for FDA review.
30-minute strategy session. No cost, no commitment - just answers from people who have shipped 275+ FDA submissions.