An SBOM has to name components, not just exist

A cyber device's premarket submission owes FDA three things under Section 524B(b) of the FD&C Act, and two of them read like commitments a sponsor can describe in prose: a plan to monitor and address postmarket vulnerabilities, and a process for keeping the device patched. The third doesn't work that way. 524B(b)(3) asks for an actual list — a software bill of materials — and FDA's own guidance ties what belongs on that list to a named external standard, not to whatever the sponsor's own engineering team considers thorough.

Three obligations, and only one of them is a document

Section 524B, added to the FD&C Act by the Consolidated Appropriations Act, 2023 and in effect since March 29, 2023, applies to any premarket submission — 510(k), PMA, De Novo, or Humanitarian Device Exemption — for a device that meets 524B(c)'s definition of a cyber device. Once a device clears that definition, 524B(b) requires three things: a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure (b)(1); processes and procedures that provide reasonable assurance the device and its related systems are cybersecure, including making patches and updates available on a reasonably justified regular cycle for known vulnerabilities and as soon as possible out of cycle for critical ones (b)(2); and a software bill of materials, including commercial, open-source, and off-the-shelf software components (b)(3). The first two are described processes a reviewer reads and evaluates. The third is an artifact a reviewer can check line by line against the device's actual codebase.

What ‘component’ has to mean

FDA's final guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, finalized September 2023, doesn't invent its own field list for what an SBOM entry has to contain. It ties the expectation to the National Telecommunications and Information Administration's 2021 publication, The Minimum Elements for a Software Bill of Materials — a baseline naming, at minimum, the supplier name, component name, and version for each entry; a unique identifier such as a purl or CPE; the dependency relationship between components; the author of the SBOM data; and a timestamp. An SBOM entry missing the version number or the dependency relationship hasn't left out a nice-to-have field — it's left out one of the elements the guidance treats as the baseline for what counts as an SBOM at all.

Machine-readable is a constraint on the format, not a bonus

The requirement is a machine-readable SBOM, and FDA's guidance points to established formats built for that purpose — SPDX, CycloneDX, and SWID tags are the three most commonly accepted. A PDF appendix listing “open-source libraries used in this device” in prose, however accurate, doesn't satisfy that expectation even if every component named in it is correct, because nothing about a narrative table lets a reviewer, or a hospital's own security team years later, parse it programmatically against a newly disclosed vulnerability in one specific library version. The format requirement exists because the SBOM's real audience isn't just the reviewer reading the submission once — it's every downstream system that has to check a device's actual component list against a vulnerability database on a day nobody is thinking about the original filing.

The Refuse-to-Accept policy turns this into a gate

FDA's own Refuse-to-Accept review has applied to cyber device submissions since October 1, 2023 — a submission for a device meeting 524B(c)'s definition can be refused at intake for an inadequate SBOM, before substantive review of the device itself even starts. That timing matters: an SBOM gap caught at RTA costs a resubmission cycle, not a mid-review information request a sponsor can quietly satisfy while the rest of the file keeps moving.

It has to describe what's actually shipping, not what shipped at clearance

524B(b) frames all three obligations, including the SBOM, as part of an ongoing duty to provide reasonable assurance the device is cybersecure — not a one-time snapshot filed with the original submission and left untouched. A component patched or swapped after clearance changes what the device actually runs, and an SBOM that still lists the pre-patch version is describing a device that no longer exists in the field. A postmarket change-control process that updates a device's cybersecurity documentation without touching the SBOM entry for the component that just changed has updated only half the record 524B(b) is asking it to keep current.

Where this meets the rest of the file

The SBOM only comes into play once a device has already cleared 524B(c)'s own definition — what makes a device a cyber device is a separate, prior question this obligation doesn't reopen. And the software components an SBOM lists still answer to IEC 62304's own classification for whatever software item they belong to — naming a component isn't the same record as documenting the development process behind it. An SBOM-readiness worksheet built around the NTIA minimum elements, the machine-readable format requirement, and a postmarket update trigger is previewed in the launch catalog. If your program tracks SBOM currency differently, the shelf takes that correction directly.