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.
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.
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.
Each pillar links to a deep-dive guide or service so you can go as deep as you need.
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 complianceMachine-readable SBOM in CycloneDX or SPDX, with VEX statements that tell reviewers which CVEs are actually exploitable in your device's context.
Explore SBOM & VEXSTRIDE-based threat modeling for medical devices, with trust boundaries, attack surface mapping, and traceability into design controls.
Explore Threat modelingMonthly CVE triage, coordinated vulnerability disclosure, change-controlled patch delivery, and incident response - for the life of the device.
Explore Postmarket monitoringIndependent, exploit-driven testing across hardware, firmware, wireless, BLE, mobile, web, and cloud back end - with a traceable Test Plan, Test Cases, and Test Report.
Explore Penetration testingFull medical device cybersecurity package with eSTAR-ready documentation and a no-cost deficiency resolution commitment. Track record: 275+ FDA submissions supported, zero cybersecurity rejections.
Explore Premarket packageNeed definitions? See the MedTech cybersecurity glossary or the FDA cybersecurity acronyms reference.
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:
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.
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:
Build the system description, architecture views, and threat model from the same device configuration. Name the hardware, firmware, companion app, cloud APIs, update service, and deployment assumptions. Trace threats to security requirements, controls, and test evidence.
Use ANSI/AAMI SW96 for security risk management, IEC 81001-5-1 for health software security lifecycle activities, and ISO 14971 for patient-safety analysis. AAMI TIR57 and TIR97 provide security risk and postmarket guidance. Select references for their scope rather than assuming one standard makes a submission acceptable.
An operational SBOM maps components to released versions, support information, and vulnerability monitoring. Blue Goat builds to CISA 2026 minimum elements plus FDA support fields. The FDA's February 2026 guidance still cites NTIA 2021 and does not require the added CISA fields. VEX is optional; retain applicability evidence whether or not you publish a VEX statement.
Organize evidence using the applicable eSTAR 7.1 prompts and cross-references. Do not assume a universal single-attachment layout. Scope security testing to the actual interfaces, document findings and corrections, and retain retest evidence. The manufacturer owns clinical harm severity, risk acceptance, and release decisions.
A penetration test does not replace secure development or postmarket work. Assign owners for vulnerability intake, triage, disclosure, component monitoring, and patch planning. Review whether missed targets or recurring findings meet the manufacturer's CAPA criteria.
CISA 2026 SBOM checklist · CAPA in medical device cybersecurity
Place cybersecurity milestones inside the product plan. Threat modeling before architecture freeze can inform component selection, interfaces, update trust, and support requirements. Starting later may require revisiting those decisions, but neither effort nor submission timing has a universal duration.
Make scope, dependencies, responsibilities, and funding visible to leadership. Coordinate software, hardware, quality, and regulatory teams around the same released configuration. Budget for development evidence and for the operating postmarket program, not only for documents prepared at submission.
Section 524B imposes duties for applicable cyber-device submissions. Guidance recommendations remain distinct from statutory obligations. Hospital buyers may also request an SBOM, MDS2, support information, and vulnerability response commitments; procurement requirements do not replace the manufacturer's regulatory assessment.
After launch, the program needs named intake and triage owners, monitoring sources, patch approval and deployment processes, and customer communication responsibilities. Review actual performance rather than treating a written plan as proof that the process operates. No single gap establishes that a Warning Letter or recall will follow.
Plan your premarket evidence dates · Postmarket cybersecurity services
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.
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.
Three steps take a manufacturer from first questions to a cybersecurity section. Each one has its own page with the detail.
The health software security activities the standard describes, how it builds on IEC 62304, and how it supports an FDA SPDF.
Read more →How weakness types and disclosed vulnerabilities each support findings, remediation, and FDA submission evidence.
Read more →Testing of device, firmware, app, cloud, and wireless interfaces, with a report traced to your threat model and retests included.
Read more →Christian Espinosa and guests unpack Section 524B, threat modeling, SBOM strategy, and real FDA deficiency letters - weekly episodes drawn from active premarket submissions.
Free, no-signup tools that mirror how FDA actually reviews cyber devices.
275+ FDA submissions supported, zero cybersecurity rejections. Anonymized findings: deficiency patterns, timing impact, and AI/ML SaMD vulnerabilities.
Read Original research & datasetsWhat the FDA expects in the cybersecurity section of every 510(k) submission.
Read 510(k) cybersecurity requirementsHigher-risk submission pathways and the medical device cybersecurity bar they require.
Read PMA & De Novo cybersecurity180-day clock running? Diagnose, remediate, and respond to FDA cyber deficiencies.
Read FDA deficiency responseChoosing an SBOM format the FDA accepts and reviewers can actually parse.
Read CycloneDX vs SPDXTwo foundational AAMI standards for medical device cybersecurity risk.
Read AAMI SW96 vs TIR57Quick-reference glossary: SPDF, SBOM, VEX, RTA, eSTAR, SaMD, and more.
Read FDA cybersecurity acronyms30-minute strategy session. No cost, no commitment - just answers from people who have supported 275+ FDA submissions, with zero cybersecurity rejections.
