What Does FDA Require in the Premarket Submission for a Cyber Device?

Section 524B of the Federal Food, Drug, and Cosmetic Act gave FDA authority, effective October 1, 2023, to refuse to accept a premarket submission for a cyber device that lacks adequate cybersecurity information. The statute itself names three required elements; FDA's guidance then translates those elements into the concrete documentation set reviewers actually check against during the acceptance review and substantive review that follow.

The Three Statutory Elements Under 524B(b)

Section 524B(b) requires every cyber device sponsor to demonstrate, as a condition of submission:

• 524B(b)(1)(A), device security assurance. Processes to design, develop, and maintain the device and related systems in a reasonably cybersecurity secure manner throughout the device's lifecycle.
• 524B(b)(1)(B), coordinated vulnerability disclosure. A documented process for accepting and responding to vulnerability reports from outside researchers before a vulnerability becomes public, typically aligned to ISO/IEC 29147 and 30111. A policy statement alone does not satisfy this; the underlying process, a security contact, an intake channel, a triage timeline, has to actually exist.
• 524B(b)(3), Software Bill of Materials. A complete inventory of commercial, open source, and off the shelf software components, each with version information, in a machine readable format.
• 524B(b)(4), postmarket monitoring. A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including those discovered in third party SBOM components, within a reasonable time relative to the risk.

How the 2023 Guidance Expands the Statute Into a Documentation Set

FDA's final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (September 2023), translates these four statutory elements into the practical documentation FDA reviewers expect to see in the submission package:

• Cybersecurity management plan. Describes how the sponsor will manage cybersecurity risk across the device's total product lifecycle, including vulnerability monitoring, patch deployment, and end of life planning.
• Threat model. A structured analysis, typically using a methodology such as STRIDE or PASTA, identifying assets, attack surfaces, and credible threats, each mapped to the device's actual architecture rather than a generic template.
• Security architecture views. System level architecture diagrams, interface descriptions, data flow maps, and trust boundaries sufficient for a reviewer to evaluate whether the design controls match the device's risk profile.
• Vulnerability and risk assessment. Threats mapped against the SBOM and architecture, scored with clinical safety context rather than a raw CVSS score alone, and integrated with the device's existing ISO 14971 risk management file.
• Security testing evidence. Vulnerability scanning plus penetration testing results, confirming that security controls hold up against realistic attack attempts rather than design stage analysis alone.
• Labeling. Instructions for Use content addressing secure configuration, supported software environments, and known residual risks communicated to the end user.

FDA calls the lifecycle approach underlying this set the Secure Product Development Framework, a term for security built into design, confirmed through testing, and maintained after release. The documentation package is meant to serve as evidence that this framework was actually followed, not a static bundle assembled at the end of development.

Where Each Element Sits in eSTAR

FDA's eSTAR template, now required for most 510(k) submissions and used across De Novo and PMA pathways, includes a dedicated cybersecurity section distinct from the general software documentation and risk management sections. The cybersecurity management plan, threat model, security architecture views, vulnerability assessment, and testing evidence all live in this dedicated section, cross referenced to the device's broader software documentation rather than duplicated inside it. Reviewers use this section specifically to confirm the Secure Product Development Framework's elements are present and internally consistent with each other, not just individually complete.

What Happens When an Element Is Missing

FDA may issue a Refuse to Accept finding for a submission that lacks a required 524B element, returning the submission without substantive review. Because RTA resets the review clock rather than pausing it, the full administrative review cycle restarts once the missing documentation is assembled and resubmitted, which for many sponsors adds months to time to market. Addressing every required element before submission, rather than discovering a gap through an RTA letter, is the more efficient path by a wide margin.

ADB's regulatory team reviews a cyber device's full premarket documentation set, the statutory elements and the 2023 guidance's expanded requirements together, against what FDA reviewers are actually citing in deficiency letters as part of the Section 524B gap assessment.

Frequently Asked Questions

What happens if a submission is missing a required 524B element?

FDA may issue a Refuse to Accept finding, which returns the submission without substantive review and resets the review clock entirely, adding months to time to market.

Where does the cybersecurity documentation go in an eSTAR submission?

eSTAR includes a dedicated cybersecurity section for any device meeting the cyber device definition, separate from the general software documentation and risk management sections.

Does FDA require penetration testing in the premarket submission?

Yes. FDA's guidance expects security testing evidence, including penetration testing, in addition to vulnerability scanning, confirming that security controls hold up against realistic attack attempts.