Medical Device Cybersecurity for FDA Submissions
The device works and the verification is done, then the submission needs a threat model, four architecture views and an SBOM with support dates that nobody has written yet. Agnotic Technologies builds connected device software and produces the cybersecurity documentation FDA expects alongside it, so security evidence is ready when the rest of the file is.
Trusted by global innovators
What does the cybersecurity part of an FDA submission contain?
The cybersecurity part of an FDA premarket submission shows how a device was designed and tested to resist attack: a threat model, a security risk assessment scored on exploitability, security architecture views, an SBOM with support status, testing evidence and customer security labeling. Agnotic Technologies produces this documentation alongside the device software it builds.
Submission checklist
Which cybersecurity documents does a premarket submission need?
This is the checklist we work from on a connected device. Each document traces to the others: threats to risks, risks to controls, controls to tests. Your regulatory team owns the submission; we produce the engineering content.
| Document | What it must show | Who produces it | Where FDA's guidance covers it |
|---|---|---|---|
| Threat model | Assets, entry points, threats and the security objectives for the whole device system, including apps, cloud and update servers | Agnotic engineering, reviewed with your quality team | Section V.A.1, Threat Modeling |
| Cybersecurity risk assessment | Each threat scored on exploitability, the control chosen and the residual risk, kept apart from the ISO 14971 safety file but linked to it | Agnotic engineering with your risk management owner | Section V.A.2, Cybersecurity Risk Assessment |
| Security architecture views | Global system, multi-patient harm, updateability and patchability, and security use case views, as diagrams with text | Agnotic engineering | Section V.B.2, Security Architecture Views |
| SBOM with support status | Every commercial, open source and off-the-shelf component, with its level of support and end-of-support date | Agnotic engineering, generated from the build | Section V.A.4 and Section VII.C.3 |
| Unresolved anomalies assessment | Known defects still open at submission, each checked for security impact | Agnotic engineering with your quality team | Section V.A.5 |
| Cybersecurity testing report | Control testing, fuzzing, attack surface analysis, scanning, binary composition analysis, static and dynamic analysis and a penetration test, with findings and how each was closed | Agnotic engineering, with an independent penetration tester where you require one | Section V.C, Cybersecurity Testing |
| Labeling and customer documentation | Security features, recommended network setup, update and end-of-support information, often packaged in an MDS2 form | Your regulatory team, with technical content from Agnotic | Section VI.A, Labeling Recommendations |
| Postmarket vulnerability plan | How vulnerabilities will be monitored, disclosed and patched after release | Your quality team, with the engineering process from Agnotic | Section VI.B and Section VII.C.1 |
Section numbers refer to FDA's February 2026 guidance. This table is engineering guidance; your regulatory team decides what goes in the submission and how it is presented.
Is your product a cyber device?
Section 524B applies to a device that meets all three conditions below. Your regulatory team makes the call; we document the facts it rests on, such as every network path the software can reach.
Software validated, installed or authorized by you
The device includes software that you, the sponsor, validated, installed or authorized as a device or in a device. That covers firmware, companion apps and device software functions.
Able to connect to the internet
The device has the ability to connect to the internet. FDA reads this broadly, so we map direct and indirect paths, such as a sensor that reaches the cloud through a phone app or a hospital gateway.
Characteristics that could be vulnerable
The device contains technological characteristics that could be vulnerable to cybersecurity threats, such as wireless interfaces, update mechanisms, ports and stored credentials.
What follows if it is
The submission must include the 524B items, and FDA's guidance describes the documentation it expects. The same guidance also covers devices with cybersecurity risk that are not cyber devices.
App gallery
View AllLera Health
Health evolve
How is security risk scored apart from safety risk?
Safety risk asks how likely a hazard is. Security risk asks how easily a weakness could be exploited, because an attacker does not follow a probability curve. We keep the two files separate and linked.
Start from the threat model
Each threat names the asset, the entry point and the attacker's goal, across the device, apps, cloud services and update path.
Score exploitability
Each threat is rated on how easily it could be exploited, using a method agreed with your quality team and recorded with its rationale.
Choose and trace controls
Controls such as authentication, signed updates and encrypted storage are linked to the threats they address and to the tests that prove them.
Hand over safety impacts
Where a security failure could cause patient harm, the item is passed to the ISO 14971 safety file so both teams see the same risk.
Which rules and guidance define device cybersecurity?
Short facts from the statute and FDA's guidance, each linked to its primary source.
Section 524B of the FD&C Act defines a cyber device as a device that includes software validated, installed or authorized by the sponsor as a device or in a device, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats.
Source: 21 U.S.C. 360n-2(c) (govinfo)FDA's premarket cybersecurity guidance says security risk assessment focuses on exploitability rather than the probabilistic approach used in safety risk management under ISO 14971, which is why safety and security risk management are distinct but connected processes.
Source: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)FDA recommends that premarket submissions include, at minimum, a global system view, a multi-patient harm view, an updateability and patchability view and security use case views, each documented with diagrams and explanatory text.
Source: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)For each software component in the SBOM, FDA recommends that the premarket submission state the level of support from the component's manufacturer, such as actively maintained, no longer maintained or abandoned, and the component's end-of-support date.
Source: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)FDA notes that a revision-controlled Manufacturer Disclosure Statement for Medical Device Security (MDS2) and customer security documentation as outlined in the Joint Security Plan version 2 may address a number of its cybersecurity labeling recommendations.
Source: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)
Which healthcare standards sit alongside device cybersecurity work?
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Medical device cybersecurity FAQs
Build compliantly