FDA Premarket Cybersecurity

Section 524B of the Federal Food, Drug, and Cosmetic Act made cybersecurity a statutory requirement for cyber devices, not a best practice. If your device includes software, connects to the internet, or could be vulnerable to cybersecurity threats, your premarket submission must demonstrate a plan to monitor and address postmarket vulnerabilities, processes to release updates and patches, a software bill of materials, and reasonable assurance that the device and connected systems are cybersecure.

In practice, that translates into a documentation package: a threat model, a cybersecurity risk assessment tied to your ISO 14971 risk management file, an SBOM covering commercial, open source, and off-the-shelf components, evidence of security testing including penetration testing, architecture views showing trust boundaries, and cybersecurity content for your labeling. Reviewers are not looking for a security narrative - they are looking for traceable artifacts that link identified threats to controls to test evidence.

The Refuse to Accept policy lets FDA reject a submission at administrative review before a substantive reviewer ever sees it. Cybersecurity is now one of the most common RTA triggers for connected devices, and the reasons are consistent: no SBOM, an SBOM without support and end-of-support dates, a threat model that enumerates generic threats with no device-specific analysis, security testing that amounts to a vulnerability scan report, or a postmarket plan that is a paragraph of intent rather than a process.

The most expensive failure mode is treating cybersecurity as a documentation exercise late in the program. Threat models built after design freeze surface architectural problems that cannot be fixed without a redesign, and teams end up either shipping with a documented residual risk that reviewers reject or slipping the submission by months.

Manufacturers who move through review cleanly start cybersecurity at the same time as requirements definition. They build a threat model against the system architecture early, feed the resulting risks into the ISO 14971 file so security and safety risk live in one place, generate an SBOM from the build pipeline rather than by hand, and schedule penetration testing far enough before submission that findings can actually be remediated and retested.

They also write the submission for the reviewer. Each claimed control maps to a threat, each threat maps to test evidence, and the narrative explains the residual risk rationale in the language of patient harm. The episodes below feature engineers, regulatory leads, and consultants working through exactly these decisions on real programs.