What Information FDA is Expecting for Cyber Devices?

For a cyber device, FDA expects three things the law requires and a documentation package the guidance recommends. Section 524B(b) of the FD&C Act requires a postmarket vulnerability plan, processes and procedures that give a reasonable assurance of cybersecurity, and a software bill of materials, plus any further requirements FDA sets by regulation under 524B(b)(4). FDA's February 3, 2026 premarket cybersecurity guidance, in Section VII, says how to document each one and points to Appendix 4 for the full package. This post walks through what to put in the eSTAR Cybersecurity section, and why.

Is your device a cyber device?

Section 524B(c) defines a cyber device as a device that "(1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to 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."

Section VII.B of the guidance explains how FDA reads each part. Software includes firmware and programmable logic. The ability to connect to the internet covers connections that are intended or unintended, through any means. FDA's illustrative list:

• Network, server, or cloud service provider connections.
• Radio-frequency communications such as Wi-Fi, cellular, Bluetooth, and Bluetooth Low Energy.
• Magnetic inductive communications, such as the link between an implant and its programmer.
• Hardware connectors capable of connecting to the internet, such as USB, ethernet, and serial ports.

A footnote adds that a device serviced over a brief USB connection has the ability to connect. If your device has software and any port or radio, plan on being a cyber device.

Two scopes apply. The recommendations in the guidance cover any device with software, connected or not. The Section 524B requirements cover only cyber devices, and only when the sponsor submits a 510(k), PMA, PDP, De Novo, or HDE. Our Section 524B guide covers the statute and FDA's FAQ on edge cases.

What the statute requires

Section 524B(a) says the person who submits one of those applications for a cyber device is required to include the information FDA needs to ensure the device meets the requirements in 524B(b). Those requirements are:

1. 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 and related procedures."
2. 524B(b)(2): to "design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure," and to make available updates and patches on a reasonably justified regular cycle, 524B(b)(2)(A), and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks, 524B(b)(2)(B).
3. 524B(b)(3): a software bill of materials "including commercial, open-source, and off-the-shelf software components."
4. 524B(b)(4): any other requirements FDA sets by regulation. FDA has issued none and the guidance notes it isn't required to.

The guidance adds in Section IV.D that for cyber devices, failure to comply with any requirement under 524B(b)(2) is a prohibited act under section 301(q) of the FD&C Act.

How FDA wants each one documented

Section VII.C takes the three requirements in turn.

The plan (VII.C.1)

FDA recommends the plan contain the Cybersecurity Management Plan elements from Section VI.B:

• Personnel responsible.
• Sources, methods, and frequency for monitoring and identifying vulnerabilities.
• How you identify and address vulnerabilities in CISA's Known Exploited Vulnerabilities catalog.
• Periodic security testing.
• Timeline to develop and release patches.
• Update processes and patching capability.
• A description of your coordinated vulnerability disclosure (CVD) process.
• How you'll communicate remediations, patches, and updates to customers.

Section VII.C.1 adds three specifics. First, CVD should cover vulnerabilities found by outside parties, vulnerabilities you find yourself, and the procedures you use to disclose both. Second, the plan should state and justify the timelines for the regular patch cycle and for out-of-cycle patches. The guidance distinguishes "known unacceptable vulnerabilities," which the regular cycle handles, from "critical vulnerabilities that could cause uncontrolled risks," which go out of cycle, and points to the 2016 postmarket guidance for examples of each. Third, the plan should account for fielded devices on different software versions, since each version carries its own risk profile.

Our book chapter on building a vulnerability monitoring program covers what the monitoring half looks like in practice.

The processes and procedures (VII.C.2)

This is the broad one. FDA says the documentation recommendations throughout the guidance, summarized in Appendix 4, "should be considered and used to demonstrate reasonable assurance that the device and related systems are cybersecure." Related systems include manufacturer-controlled elements such as other devices, software performing other functions, update servers, and connections to healthcare networks.

Appendix 4 Table 1 lists six documentation types:

• Cybersecurity Risk Management Report, containing the threat model, cybersecurity risk assessment, SBOM, vulnerability assessment and software support, unresolved anomalies assessment, and traceability.
• Measures and Metrics for your security processes.
• Architecture Views, with the security requirements and the views themselves.
• Testing.
• Labeling.
• Cybersecurity Management Plans.

Each is described below. Our book chapter on understanding eSTAR requirements walks through where each lands in the form.

The SBOM (VII.C.3)

FDA recommends the SBOM contain the information in Section V.A.4(b): a machine-readable SBOM consistent with the NTIA's October 2021 minimum elements, plus, for each component, the level of support from its maintainer and its end-of-support date. Those two fields can go in the SBOM or in an addendum. The guidance names no format and encourages industry-accepted ones.

Alongside the SBOM, the submission should identify all known vulnerabilities in the device and its components, including any in CISA's Known Exploited Vulnerabilities catalog, describe how each was found, and provide a safety and security risk assessment and the risk controls for each. If any SBOM information can't be provided, give a justification. Our book section on SBOM analysis for eSTAR submissions and the SBOM requirements guide cover the fields.

The documentation in detail

Threat model

Section V.A.1 asks for threat modeling documentation that identifies risks and mitigations, states assumptions about the environment of use, and captures risks from the supply chain, manufacturing, deployment, interoperation, maintenance, updates, and decommissioning. Include the rationale for the methodology you chose. The MITRE playbook for threat modeling medical devices is the reference FDA cites. See threat modeling for cloud-connected devices for the method.

Cybersecurity risk assessment

Section V.A.2 states that security risk assessment "focus[es] on exploitability," because the likelihood of an attack can't be estimated from historical data the way component failures can. The assessment should capture the risks and controls from the threat model, show scores before and after mitigation with the acceptance criteria, and describe how security risks transfer into the safety risk assessment. Known vulnerabilities are foreseeable risks. Anything in CISA's Known Exploited Vulnerabilities catalog should be designed out.

For scoring, the guidance defers to the postmarket guidance, which cites CVSS. The MITRE rubric adapts CVSS for devices. Our CVSS for medical devices post covers the adaptation.

Architecture views

Section V.B.2 asks for four views at minimum, each with diagrams and explanatory text at the level of detail in Appendix 2:

• Global System View: the device and every internal and external connection, including update infrastructure, facility networks, intermediaries, cloud, and home networks.
• Multi-Patient Harm View: how the device and system defend against and respond to attacks that could harm many patients at once.
• Updatability and Patchability View: the end-to-end path by which updates reach the device, including the parts you don't control.
• Security Use Case Views: one per functionality through which a compromise could affect safety or effectiveness, across operational and clinical states.

If a view doesn't apply, explain why. The number of Security Use Case Views scales with connectivity. Section V.B.1 also asks for the requirements and acceptance criteria for each of eight control categories, and evidence the controls were implemented and tested. Our post on the architecture security view covers each view.

Testing

Section V.C says cybersecurity controls "require testing beyond standard software verification and validation activities." The submission should include evidence that each security requirement was implemented, threat mitigation testing against each view, vulnerability testing (abuse cases, fuzzing, attack surface analysis, vulnerability chaining, known-vulnerability scanning, software composition analysis, static and dynamic analysis), and a penetration test report stating tester independence and expertise, scope, duration, methods, and findings.

Metrics

Section V.A.6 names three measures to track and report when available: the percentage of identified vulnerabilities that are patched, the time from identification to patch, and the time from patch availability to deployment in the field. A first submission may have no data yet. Say how you'll collect it.

Labeling

Section VI.A lists the security information users should receive, from recommended controls for the use environment and a list of network ports, to how to obtain authorized updates, how the device responds to security events, backup and restore, secure configuration, forensic log access, end of support, and secure decommissioning. The SBOM should be available to users in machine-readable form.

Changes to a cyber device

Section VII.D covers modifications. If the change may affect cybersecurity, such as a new connectivity feature, a change to authentication or encryption, or a new update mechanism, the full Section VII.C package applies. If the change is unlikely to affect cybersecurity, such as a materials or sterilization change, FDA recommends a lighter set: a reference to the prior plan with a summary of changes, a statement of whether any critical vulnerabilities with uncontrolled risk exist now or were remediated since the last authorization, and an SBOM.

What happens when it's missing

A cyber device submission without the plan, the process evidence, or the SBOM is incomplete under Section 524B(a). A submission that has the documents but can't show a reasonable assurance of cybersecurity draws an Additional Information request. Section VII.E gives FDA's example: a central-station alarm that lacks encryption against a known threat, where inadequate data "would likely" lead to a not substantially equivalent decision. Our post on five cybersecurity reasons FDA will refuse your 510(k) covers the common gaps.

The guidance recommends using the Q-Submission process to discuss cybersecurity design early. For a first cyber device, that conversation is worth having before the architecture is locked.

Need help with the cybersecurity section of a cyber device submission? See our FDA cybersecurity documentation service or email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• Federal Food, Drug, and Cosmetic Act, Section 524B, Ensuring Cybersecurity of Devices, 21 U.S.C. 360n-2. https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title21-section360n-2&num=0&edition=prelim
• FDA. Postmarket Management of Cybersecurity in Medical Devices. Final guidance, December 28, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/postmarket-management-cybersecurity-medical-devices
• NTIA. The Minimum Elements for a Software Bill of Materials (SBOM). July 12, 2021. https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
• MITRE and MDIC. Playbook for Threat Modeling Medical Devices. November 2021. https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices
• FDA. eSTAR Program. https://www.fda.gov/medical-devices/how-study-and-market-your-device/estar-program