A cyber device submission to the U.S. Food and Drug Administration (FDA) under Section 524B has to carry a software bill of materials (SBOM), a cybersecurity management plan and the outputs of the processes that give reasonable assurance the device is cybersecure. The FDA cybersecurity guidance for premarket submissions, revised in February 2026 with its quality-system citations moved to the Quality Management System Regulation (QMSR), asks for more than that statutory list: a security risk management report that provides traceability between the threat model, the cybersecurity risk assessment, the SBOM and the testing documentation.
For a 510(k), FDA puts the submission on Technical Screening hold if its electronic Submission Template and Resource (eSTAR) cybersecurity section lacks accurate responses and relevant attachments. Even a complete section still has to show the traceability between those artifacts that the guidance asks the security risk management report to provide. This guide covers what changed in the February 2026 revision, what Section 524B requires for cyber devices, what a reviewer expects to see linked to what and where trace links go missing before submission.
What Changed in the February 2026 FDA Medical Device Cybersecurity Guidance
The February 2026 FDA cybersecurity guidance moves its quality-system citations off the old Quality System Regulation (QSR) and onto the QMSR, and its Guidance History describes the revisions as including alignment with the amendments to 21 Code of Federal Regulations (CFR) Part 820. FDA’s February text supersedes the final guidance issued June 27, 2025, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, which had itself replaced the September 2023 version. The agency issued the revision under Level 2 guidance procedures (21 CFR 10.115(g)(4)), so it took effect on issue, with comments accepted afterwards. Its docket is still FDA-2021-D-1158, and the Center for Devices and Radiological Health (CDRH) and the Center for Biologics Evaluation and Research (CBER) issue the guidance jointly.
The QMSR incorporates the International Organization for Standardization (ISO) quality management standard ISO 13485:2016 and Clause 3 of ISO 9000:2015 into Part 820 by reference. FDA’s February 2, 2024 final rule (89 FR 7496) made that change, and it took effect on February 2, 2026. Incorporation by reference is how FDA harmonized Part 820 with ISO 13485, so Part 820 no longer carries its own design and development text.
The current text of Part 820 lists §§ 820.20-820.30 as reserved within Subpart B and Subparts C through O as reserved. Design and development requirements now sit in ISO 13485:2016 Clause 7.3 and its subclauses 7.3.1 through 7.3.10, incorporated through 21 CFR 820.10(c). The two versions differ in their title, where “Quality System Considerations” became “Quality Management System Considerations,” and in the quality regulation they cite.
| June 27, 2025 version | February 3, 2026 version | |
|---|---|---|
| Title | Quality System Considerations and Content of Premarket Submissions | Quality Management System Considerations and Content of Premarket Submissions |
| Quality regulation cited | QSR, 21 CFR Part 820 | QMSR, 21 CFR Part 820 with ISO 13485:2016 subclauses |
| Design and development reference | Former 21 CFR 820.30 | ISO 13485:2016 Clause 7.3 via 21 CFR 820.10(c) (820.30 reserved) |
| Threat modeling, Secure Product Development Framework (SPDF), SBOM, Section 524B scope | In effect | Not described as changed |
For postmarket cybersecurity work, the 2026 text cites ISO 13485:2016 subclause 8.2.2 for complaint handling (with 21 CFR 820.35(a)), 7.3.7 for software validation, 7.1 for risk management, 8.2.4, 8.4 and 8.5 for quality audit, analysis of data and improvement, and 7.5.4 for servicing (with 21 CFR 820.35(b)). Under software validation (subclause 7.3.7) and risk management (subclause 7.1), the guidance says we “may need to establish cybersecurity risk management and validation processes, where appropriate.”
What Section 524B Requires Before a Cyber Device Reaches Review
Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act) makes three things law for the sponsor of any cyber device marketing submission: a plan for postmarket vulnerabilities, processes that assure cybersecurity including patches and an SBOM. The Section 524B statutory text, codified at 21 U.S.C. § 360n-2, was added to the FD&C Act by Section 3305 of the Consolidated Appropriations Act, 2023 (Pub. L. 117-328, signed December 29, 2022) and became effective March 29, 2023.
The statute defines a “cyber device” through three criteria: it (1) includes software validated, installed or authorized by the sponsor as a device or in a device; (2) can connect to the internet; and (3) contains any such technological characteristics validated, installed or authorized by the sponsor that could be vulnerable to cybersecurity threats. Nothing in that definition turns on device class or company size. For a device that meets all three prongs, subsection 524B(b) says the sponsor of the premarket submission shall do four things:
- Submit a cybersecurity management plan: The statute calls for “a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures,” which the guidance calls the cybersecurity management plan. Coordinated vulnerability disclosure (CVD) therefore has to be part of it.
- Maintain assurance processes and ship patches: The sponsor must “design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure,” and make updates and patches available “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.
- Provide an SBOM: The SBOM goes to the Secretary and must include “commercial, open-source, and off-the-shelf software components.”
- Meet any further requirements set by regulation: The fourth item is a placeholder for requirements FDA may add through rulemaking to demonstrate reasonable assurance of cybersecurity.
Failure to comply with 524B(b)(2) is a prohibited act under Section 301(q) of the FD&C Act, which puts the processes-and-patches obligation in a different legal category from anything else discussed here. Section VII of the February 2026 guidance sets out FDA’s recommendations for meeting 524B. The three concrete items above are law for cyber devices, while every other document the guidance describes is a nonbinding recommendation, as its cover page says.
Why Security Risk Is a Quality Management System Problem
The guidance frames security risk management around the Total Product Life Cycle (TPLC), saying it should be “an integrated part of” our entire quality management system (QMS) and addressed throughout the TPLC. Read against the ISO 13485 subclauses the guidance cites, that framing puts cybersecurity validation inside software validation, security risk inside risk management planning and vulnerability monitoring inside the audit, data analysis and improvement loop that runs after marketing authorization.
Integrating security into the QMS does not merge security and safety risk management into one process. The guidance states that “Performing security risk management is distinct from performing safety risk management as described in ISO 14971.” FDA’s reason is that the scope of possible harm and the risk assessment factors differ: cybersecurity risk cannot be assessed in a probabilistic manner, so security risk assessment focuses on exploitability, the feasibility or ease and technical means by which a threat can exploit a vulnerability. In the guidance’s words, they are “distinct but connected processes.”
The guidance points to Association for the Advancement of Medical Instrumentation (AAMI) TIR57 and American National Standards Institute (ANSI)/AAMI SW96 as the shape a security risk management plan and report should take. FDA describes AAMI TIR57 as setting out the security risk management process and its links into safety risk management, and ANSI/AAMI SW96 as stating requirements for security risk management across the TPLC using the ISO 14971 framework. SW96 is intended for use with TIR57. The ANSI/AAMI SW96:2023 requirements fall into six sections: security risk analysis, security risk evaluation, security risk control, evaluation of overall security residual risk acceptability, security risk management review, and production and post-production activities.
Assembling the Cybersecurity Section of a Premarket Submission
Section by section, the guidance identifies the documentation it recommends we include in the submission, and FDA’s landing page frames everything as “documentation that FDA recommends be included.” For a 510(k), that documentation goes in the Cybersecurity section of eSTAR. The report itself has to summarize the risk evaluation methods, detail the residual risk conclusion and the mitigation activities, and, in the guidance’s words, “Provide traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation as discussed later in this guidance as well as other relevant cybersecurity risk management documentation.” In the table below, adapted from Appendix 4, Table 1 of the guidance, the recommended items sit apart from the two that Section 524B makes mandatory for cyber devices.
| Documentation item | Where the guidance discusses it | Status |
|---|---|---|
| Cybersecurity Risk Management Report | Sections V, VI.B | Recommended |
| Threat model, which may include architecture views | Sections V.A.1, V.A.3 to V.A.5, V.B.2, Appendices 1 and 2 | Recommended |
| Cybersecurity risk assessment | Sections V.A.2 to V.A.6 | Recommended |
| SBOM | Sections V.A.4, VI.A | Required by 524B(b)(3) for cyber devices; content recommended |
| Vulnerability assessment and software support | Section V.A.4 | Recommended |
| Traceability | Sections V.A, V.A.1 to V.A.6, V.B.1, V.B.2, V.C, VI.A | Recommended |
| Testing | Section V.C | Recommended |
| Cybersecurity management plan | Sections VI.B, VII.C.1 | Required by 524B(b)(1) for cyber devices; content recommended |
How Do We Connect Evidence for an FDA Reviewer?
FDA recommends traceability across the threat model, cybersecurity risk assessment, SBOM, testing documentation, and other relevant cybersecurity risk-management documentation.
Mapping Threats to Security Requirements and Controls
In a connected file, each threat has a risk entry with an exploitability rating, each unacceptable risk produces at least one security requirement, and each requirement maps to a control that appears in the architecture views. The guidance recommends “that threat modeling be performed to inform and support the risk analysis activities,” performed “throughout the design process” and “inclusive of all medical device system elements.” Architecture views in the threat model may show the system, multi-patient harm considerations, updateability and patchability, and security use cases, and each included view should connect to the corresponding threats, risks and controls. A threat that appears in the threat model should therefore be findable in the risk assessment and in the architecture views.
Teams building a threat modeling practice can “develop approaches and artifacts to support traceability to track status of risks and map the risks to new requirements,” and, in turn, threat models can provide inputs into design controls, according to the 2021 threat modeling playbook from MITRE and the Medical Device Innovation Consortium (MDIC). The playbook lists the roles that need to understand how threat modeling fits their work, including systems engineers, design engineers, security risk analysts, safety engineers, design verification and validation (V&V) engineers and regulatory specialists.
Linking Each Control to the Test That Proves It
A connected file records each control with the test that exercises it and each test finding with the control and threat it evaluates. Testing is the evidence that the controls work: the threat model documents how the system was designed, while testing demonstrates whether the applied mitigations block the anticipated threats. Expected test evidence covers security requirements, threat mitigation, vulnerability testing and penetration testing, and the vulnerability testing FDA lists includes fuzz testing and attack surface analysis.
The penetration test report states its scope of testing, which should cover the interfaces the architecture views describe, and unresolved anomalies with security impact need an assessment that feeds the residual risk conclusion. Where the report says a risk is acceptable, the test result that justifies it should be directly linked.
Tying the SBOM to the Risk File and the Cybersecurity Management Plan
The SBOM connects to the risk file through the vulnerability assessment. For each known vulnerability in a component, FDA asks for “A safety and security risk assessment of each known vulnerability (including device and system impacts)” and “Details of applicable safety and security risk controls to address the vulnerability.” The guidance describes the SBOM as a mechanism to identify devices that might be affected by vulnerabilities in their software components. If a component in the SBOM has a known vulnerability in the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD) but no matching risk entry, the risk file leaves that vulnerability undocumented.
FDA recommends machine-readable SBOMs consistent with the minimum elements, which it also calls baseline attributes, in the October 2021 National Telecommunications and Information Administration (NTIA) document Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM). Its baseline attributes are author name, timestamp, supplier name, component name, version string, component hash, unique identifier and relationship. On top of those attributes, the guidance asks for two fields per component: “The software level of support provided through monitoring and maintenance from the software component manufacturer (e.g., the software is actively maintained, no longer maintained, abandoned)” and “The software component’s end-of-support date.” The Cybersecurity and Infrastructure Security Agency (CISA) published 2026 minimum elements for an SBOM in July 2026 to replace NTIA’s 2021 minimum elements, but the February guidance predates them and still points to the NTIA document.
An SBOM should cover the upstream dependencies that proprietary, licensed and open-source components rely on. Where SBOM information cannot be provided, FDA asks for a justification for why it cannot be included. Its component list also carries into the cybersecurity management plan, whose monitoring sources the guidance says should include third-party software manufacturers.
Joining Security Evidence to the ISO 14971 Risk File
FDA asks for a safety and security risk assessment of each SBOM vulnerability, but the guidance keeps security risk management distinct from ISO 14971 safety risk management, so the two files have to be joined deliberately. A security risk that can lead to patient harm needs a hazard entry in the safety risk file, where severity is estimated on the ISO 14971 scale, while its exploitability is estimated in the security risk assessment. The guidance also asks for the method for transferring security risks into the safety risk assessment process. Without that link, the security file can declare a risk acceptable on exploitability grounds while the safety file never learns the hazard exists.
Sponsors may choose to present this traceability separately, in “a separate document linking together software requirements specifications, software design specifications, testing and identified hazards derived from the risk assessment,” according to FDA’s premarket software guidance. Security requirements that threat modeling produces for device software are software requirements in that sense, so the same matrix that ties safety hazards to requirements and tests should carry the security threats too. One trace document with two entry points, one from the hazard analysis and one from the threat model, keeps the two processes separate while connecting their outputs.
Where Do Medical Device Cybersecurity Submissions Lose Traceability?
Submissions lose traceability in three places: procedures submitted without their outputs, submission documents that do not reference one another, and safety and security risk files kept in separate tools.
Submitting Procedures Without Their Outputs
The 524B(b)(2) obligation is to maintain processes, and a potential misreading is to submit the procedures as the complete evidence. For submission documentation, FDA asks for security risk management reports that include the outputs of those processes, among them threat modeling, the cybersecurity risk assessment and the SBOM. An SPDF procedure with no populated threat model behind it gives the reviewer none of the outputs the guidance asks for. Appendix 4 of the guidance summarizes the documentation in a table, but FDA says that table “is not intended to serve as merely a deliverable checklist,” because the processes outlined in the guidance are meant to shape each document’s content.
Leaving Submission Documents Unconnected
Required evidence goes incomplete or unconnected when an SBOM is missing dependencies and carries no justification, which FDA asks for. It also breaks when the SBOM arrives in a non-machine-readable format against FDA’s recommendation, or when the plan lacks the CVD policy that 524B(b)(1) names.
Maintaining traceability in a spreadsheet can get burdensome enough that the matrix stays unfilled until a project is nearly complete, at which point it is an auditor-facing artifact rather than a design tool. Spreadsheet controls alone may also fall short of 21 CFR Part 11 requirements for electronic records and signatures. When a control changes after the penetration test was scoped, nothing in a spreadsheet flags the test as stale, so the report reflects a design that no longer exists.
Design changes can make previously reviewed evidence stale. Section VII.D of the guidance separates modifications that may affect cybersecurity (authentication or encryption algorithms, new connectivity features, a changed software update process) from those unlikely to affect it (material or sterilization method changes, and algorithm changes that leave architecture, software structure and connectivity alone). For any 510(k), Section VII.E adds that FDA considers changes to the environment of use and new vulnerabilities compared with the predicate.
Keeping Safety and Security Risk Files in Separate Tools
A cybersecurity threat that can translate into a patient safety event still tends to live in the security team’s tool while the ISO 14971 hazard analysis lives in the quality team’s, and the two carry no shared traceability. Producing the linkage from security risks through safety risks to design and development outputs then becomes a reconstruction exercise at submission time.
Jama Connect® is a web-based requirements management and traceability platform for complex, regulated product development, and its frameworks for medical device teams harmonize cybersecurity and safety risk management aligned to ANSI/AAMI SW96:2023. BrightInsight, which builds Software as a Medical Device (SaMD) and digital health platforms, cut cybersecurity and patient safety risk evaluations from six weeks to two weeks and reported a more than 50% reduction in risk assessment activities after moving that work into Jama Connect. Describing the change, BrightInsight’s Director of Systems Engineering said: “We’ve been able to link cybersecurity risks back into patient hazards, which is something many companies struggle to do. Jama Connect’s traceability and item relationships make that possible.”
What the Cybersecurity Management Plan Has to Cover
For a cyber device the plan is mandatory under 524B(b)(1), and FDA wants it in the premarket file because it lets the agency assess whether we have sufficiently addressed how to maintain the safety and effectiveness of the device after marketing authorization is achieved. The guidance recommends that the plan cover these elements:
- Responsible personnel: The plan names who owns postmarket cybersecurity.
- Monitoring sources and frequency: The plan states how and how often we monitor for vulnerabilities and which sources we watch, and how we identify and address entries in CISA’s Known Exploited Vulnerabilities Catalog.
- Periodic security testing: The plan describes the periodic security testing that continues after marketing authorization.
- Patch timelines and update capability: The plan gives the timeline to develop and release patches and describes the update process and the device’s patching capability.
- CVD: The CVD process covers vulnerabilities and exploits identified by external entities and by us, and the procedures for disclosing them.
- Customer communication: A plan for communicating remediations, patches and updates to customers closes the loop.
FDA’s postmarket cybersecurity guidance, Postmarket Management of Cybersecurity in Medical Devices, was issued in December 2016 and remains in effect; the February 2026 document did not replace it. The 2026 text refers to it repeatedly, including for “Additional recommendations on coordinated vulnerability disclosure plans” and for whether a new premarket submission or 21 CFR Part 806 reporting is needed after a postmarket vulnerability.
A CVD practice should acknowledge receipt of the initial report to the submitter, per the 2016 guidance, which also notes that FDA had recognized ISO/International Electrotechnical Commission (IEC) 29147:2014 on vulnerability disclosure and ISO/IEC 30111:2013 on vulnerability handling. For a modification unlikely to affect cybersecurity, where a plan is already on file, the guidance asks for “a reference to the prior submission and a summary of any changes to the plan,” and for whether any vulnerabilities with uncontrolled risk were remediated since the last authorization. The remediation history is why the SBOM, the vulnerability assessment and the plan need to reference the same component list.
How Jama Connect Supports FDA Cybersecurity Guidance Compliance
Jama Connect’s medical device frameworks include two this guidance leans on: Cybersecurity for Medical Devices, aligned to ANSI/AAMI SW96:2023, and a Risk Management Framework aligned to ISO 14971. When a Traceability Information Model (TIM) defines threat, security risk, requirement, test and hazard item types and the links each one requires, Jama Connect flags a threat or security risk whose required downstream item is missing. The SBOM itself stays in the team’s own tooling; when the TIM also defines a vulnerability risk item for each SBOM component with a known vulnerability, Jama Connect flags one whose required control, test or hazard link is missing. No one has to build report templates before the first risk review, because these frameworks include ready-made risk analysis reports.
Suspect links react to a change in a threat, a security requirement or an architecture control: each risk item and test case linked below it stays suspect until an engineer assesses and clears it, so a linked penetration test scoped against an earlier design does not silently stay green. Review Center provides electronic signatures and audit-trail capabilities that support customers’ 21 CFR Part 11 compliance processes. For the cybersecurity management plan’s summary of changes and remediated vulnerabilities in the next submission, comparing two baselines shows exactly what changed in the linked items between authorizations. Teams whose quality system requires separate validation of the hosting environment can run Jama Connect in the Customer Validated Cloud.
Carrying FDA Cybersecurity Guidance Evidence Into the Next Submission
Moving citations from the former 820.30 to 21 CFR 820.10(c) and ISO 13485 Clause 7.3 is a document edit; keeping the threat model, risk file, SBOM and test evidence connected through every medical device design change is the work the next reviewer checks. To see threats, security risks, requirements, tests and ISO 14971 hazards traced in one project, start a free 30-day trial of Jama Connect.
Frequently Asked Questions About FDA Cybersecurity Guidance
Which premarket submission types does the FDA cybersecurity guidance apply to?
Relevant submission types include premarket notifications (510(k)), premarket approval applications (PMA), humanitarian device exemptions (HDE), investigational device exemptions (IDE), De Novo classification requests, product development protocols and applicable biologics license application (BLA)/investigational new drug application (IND) pathways. The recommendations apply to devices that contain software (including firmware) or programmable logic, including SaMD, and are not limited to devices that connect to a network; the Section 524B obligations apply only to cyber devices submitted through a 510(k), PMA, product development protocol, De Novo request or HDE, not to IDE, BLA or IND submissions.
Does a low-risk device with software still fall under Section 524B?
Yes, if it meets all three statutory prongs, and the practical scoping step is to record the evidence for each one: which software we validated, installed or authorized, and how the device can connect to the internet. The record then separates mandatory Section 524B materials from recommended cybersecurity documentation, and if a prong is not met, we should preserve the rationale in the submission file and avoid using the device’s risk classification as a proxy.
Can IEC 81001-5-1 be used as the SPDF?
Yes, as long as the process satisfies the QMSR: the premarket guidance names it among the possible frameworks to consider, so teams can use it as an SPDF. IEC 81001-5-1 Edition 1.0 (2021-12) is an FDA-recognized consensus standard whose process requirements derive from IEC 62443-4-1 and extend a development process that conforms to IEC 62304.
Do routine security patches require a new premarket submission?
Not typically, although a 510(k) may be required when a countermeasure is a significant change, and 21 CFR Part 806 reporting may also need to be evaluated. Operationally, we should treat each patch as a controlled change: identify the affected SBOM component, then reassess the risks and tests linked to it, and keep the approval and release evidence with the change record. The controlled record then supplies the remediation history a later submission reports, without reconstruction after the fact.
