In February 2026, FDA issued "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions". It supersedes the version of 27 June 2025 and addresses section 524B of the FD&C Act, which has applied to "cyber devices" since 29 March 2023.
Part of FDA's cybersecurity framework is law and part is recommendation, and a submission has to handle both. This article explains what is binding, what the guidance recommends, how it connects to the QMSR, and what it means for connected software.
What is binding and what is guidance
| Document | Status |
|---|---|
| Section 524B of the FD&C Act, "Ensuring Cybersecurity of Devices" | Law. Applies to cyber devices in 510(k), PMA, PDP, De Novo and HDE submissions |
| Premarket cybersecurity guidance, February 2026 | Guidance, nonbinding. Current version |
| Postmarket Management of Cybersecurity in Medical Devices, December 2016 | Guidance, nonbinding |
Sources: FD&C Act; FDA.
In our view, the first drafting decision is to separate the statutory duties under section 524B from the recommendations around them.
Which devices are in scope
The guidance is wider than section 524B. According to FDA, it applies to devices with cybersecurity considerations, including devices that contain software, firmware or programmable logic, and it is not limited to network-enabled devices. It covers 510(k), De Novo, PMA, PDP, IDE, HDE, BLA and IND submissions, and also devices that need no premarket submission, such as 510(k)-exempt devices. Recommendations for IDEs are in Appendix 3. Our article on the investigational device exemption covers that route.
Cyber devices are a subset. Under section 524B(c), a cyber device includes software, has the ability to connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. FDA reads "ability to connect to the internet" broadly. It includes devices that can connect intentionally or unintentionally, and FDA lists hardware connectors such as USB and ethernet. A device serviced through a USB port may therefore meet the definition.
What section 524B requires
For cyber devices, the submission must include:
| Provision | Requirement |
|---|---|
| 524B(b)(1) | A plan to monitor, identify and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure |
| 524B(b)(2) | Processes that provide a reasonable assurance that the device and related systems are cybersecure, with updates and patches on a reasonably justified regular cycle for known unacceptable vulnerabilities, and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks |
| 524B(b)(3) | A software bill of materials (SBOM), including commercial, open-source and off-the-shelf components |
| 524B(b)(4) | Any other requirements FDA sets by regulation |
Source: FD&C Act section 524B.
According to FDA, failure to comply with section 524B is a prohibited act under section 301(q) of the FD&C Act.
In our view, a plan that names no owner, intake route, triage criteria or disclosure procedure does not show that postmarket monitoring will actually happen.
The link to the QMSR
The February 2026 version ties cybersecurity to the Quality Management System Regulation, in force since 2 February 2026. Security risk management, threat modelling and security testing belong in the design and development records and the risk file, not only in the submission.
FDA recommends a secure product development framework (SPDF). It names the Medical Device and Health IT Joint Security Plan (JSP2) and IEC 81001-5-1 as medical device-specific examples, and notes that frameworks from other sectors, such as ANSI/ISA 62443-4-1, may also comply with the QMSR.
In our view, cybersecurity should be a design input from the start of development. Threat modelling done late usually forces changes to the architecture or the update mechanism.
What FDA recommends in a premarket submission
| Element | What FDA recommends |
|---|---|
| Security risk management | A security risk management report, with threat modelling and a cybersecurity risk assessment |
| SBOM | Machine-readable, with each component's level of support and end-of-support date, and an assessment of known vulnerabilities, including those in CISA's Known Exploited Vulnerabilities Catalog |
| Architecture views | Including a global system view, a multi-patient harm view, and an updatability and patchability view |
| Testing | Security testing, including vulnerability and penetration testing |
| Labelling | Cybersecurity information users need |
| Plans | Cybersecurity management plans for after clearance |
Source: FDA premarket cybersecurity guidance, February 2026.
The amount of documentation scales with cybersecurity risk. Our article on AAMI medical standards covers the related US security standards, such as TIR57 and SW96.
In our view, the SBOM should be generated from the build and reviewed at each release, so it stays usable for postmarket triage rather than becoming a submission snapshot.
Modifications
The section 524B requirements also apply to a submission for a modification of a cyber device. FDA distinguishes:
changes that may impact cybersecurity, such as changes to authentication or encryption algorithms or new connectivity features;
changes unlikely to impact cybersecurity, for which FDA recommends less documentation.
In our view, the decision should test whether the change touches architecture, connectivity, security controls, third-party components or the SBOM, and the rationale should be recorded either way. Our article on IEC 62304 covers the software change process behind this.
A hypothetical example
Hypothetical example: a Dutch company prepares a 510(k) for a cloud-hosted SaMD app.
Cyber device test: the app includes software and connects to the internet, so section 524B applies.
Statutory elements: the 510(k) includes the postmarket vulnerability plan, the update processes and an SBOM covering the app and the cloud components.
Design records: threat modelling and security testing sit in the design file, following IEC 81001-5-1 as its SPDF.
Architecture views: these show where patient data flows and how a server-side update reaches every user at once.
Later change: an algorithm-only update with no change to architecture, connectivity or components is assessed as unlikely to impact cybersecurity, and the rationale is recorded.
Our article on software as a medical device covers the wider framework.
Conclusion
Section 524B sets three statutory duties for cyber devices: a vulnerability plan, update processes and an SBOM. The February 2026 guidance explains what FDA expects as evidence and links cybersecurity to the QMSR.
In our view, the practical order is: confirm whether the product is a cyber device, build the security evidence into design controls, then keep the SBOM, vulnerability handling and updates current after clearance.
If you need help with FDA cybersecurity documentation, our cybersecurity and privacy team can help, or contact MedQAIR.
Frequently asked questions
What is the current FDA cybersecurity guidance?
The February 2026 guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions", which supersedes the June 2025 version.
What is a cyber device?
A device that includes software, has the ability to connect to the internet, intentionally or unintentionally, and has technological characteristics that could be vulnerable to cybersecurity threats (section 524B(c)).
Is an SBOM mandatory?
For cyber devices, yes, under section 524B(b)(3). For other devices, FDA recommends one.
Does the guidance apply to 510(k)-exempt devices?
Yes. FDA says the recommendations apply to devices whether or not they need a premarket submission. Section 524B applies only to cyber devices in the submissions it lists.
Can a device with only a USB port be a cyber device?
It can. FDA includes devices that can connect to the internet unintentionally and lists USB among the relevant connectors.
