FDA Premarket Cybersecurity: Why Your SBOM Won't Save a Weak Submission

Section 524B of the FD&C Act — added by the Consolidated Appropriations Act, 2023, and in effect since March 29, 2023 — gave FDA statutory authority to require cybersecurity information in premarket submissions for devices that meet its definition of a “cyber device.” Most regulatory teams know this means producing a software bill of materials. Fewer have registered that the SBOM is one of at least three required elements, and that FDA has been screening for the other two at the door, before a reviewer ever opens the submission.

What Section 524B actually requires

The statute names four things a sponsor of a cyber device must submit as a condition of premarket clearance or approval: a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure; a process to provide reasonable assurance the device and its related systems are cybersecure, including a way to make updates and patches available on a reasonably justified regular cycle and out-of-cycle for critical vulnerabilities; a software bill of materials, including commercial, open-source, and off-the-shelf components; and compliance with any additional requirements FDA identifies by regulation. FDA's premarket cybersecurity guidance — finalized in June 2025 and revised in 2026 to align with the QMSR — frames these as design control outputs, not a submission-stage checklist — which is exactly where most gaps originate.

Why submissions still fail at the door

Refuse-to-accept screening is a completeness check, not a merits review — a reviewer confirms the required elements are present before the clock on substantive review even starts. That makes it an unforgiving place to be incomplete: a cybersecurity gap caught at RTA doesn't produce a deficiency letter mid-review, it produces a submission that never entered review at all. Teams that built their connected device's cybersecurity file as a document assembled after design freeze, rather than as an output of the design-controls process, are the ones most likely to discover a gap this way.

• An SBOM with no vulnerability-management narrative attached. The component list satisfies one element; it says nothing about how vulnerabilities in those components get monitored and remediated.
• No described process for delivering updates and patches. The statute wants a process, not a promise — how patches reach fielded devices, on what cycle, and how critical vulnerabilities get an out-of-cycle path.
• Coordinated vulnerability disclosure left undocumented. A plan to "monitor and identify" is not the same as a documented process for receiving and acting on an external researcher's disclosure.
• Cybersecurity risk management kept separate from the device's overall risk file. Reviewers increasingly expect cybersecurity risk to be traceable through the same risk-management process as every other hazard, not managed in a parallel document nobody cross-references.

An SBOM tells FDA what is in the device. It does not tell FDA what happens the day a component on that list turns out to be vulnerable. Section 524B wants both. Why the SBOM is necessary but not sufficient

Cybersecurity is a design-control question, not a paperwork question

The submissions that clear RTA screening without incident tend to share one trait: cybersecurity was a design input from the start, not a section drafted against a finished device. That means threat modeling happens alongside the rest of hazard analysis, the SBOM is generated from the actual build rather than reconstructed from memory before submission, and the vulnerability-management plan describes a process the organization already runs internally — not one invented for the filing. Sponsors who route cybersecurity through the same risk-management discipline they apply everywhere else in design controls rarely find themselves explaining a gap to FDA after the fact.

None of this changes the mechanics of the premarket pathway itself — a cyber device still moves through 510(k), De Novo, or PMA review on the same statutory timeline as any other device. What changes is what has to be true before that clock starts. Confirming the cyber device determination early, and building the required documentation as a byproduct of how the device is actually engineered, is materially cheaper than reconstructing it against a submission deadline.