What Is an SBOM and Why Does FDA Require It for Cyber Devices?

For a device that meets FDA's cyber device definition, the SBOM is not optional supporting material; it is one of the four statutory elements Section 524B(b) requires in the premarket submission, alongside a postmarket vulnerability management plan, a coordinated disclosure process, and evidence that the device's security assurance processes cover its whole lifecycle. An incomplete or non machine readable SBOM is one of the most common reasons FDA issues a Refuse to Accept finding on a cyber device submission.

What Section 524B(b)(3) Actually Requires

The statute requires a software bill of materials, including commercial, open source, and off the shelf software components. FDA's September 2023 premarket cybersecurity guidance expands this into a practical expectation: the SBOM has to identify every component by name and version, trace dependency relationships at least one layer beyond the top level package, and stay current as the device's software changes across its lifecycle. A one time snapshot generated at submission and never updated again does not meet FDA's ongoing expectation, because the SBOM doubles as the reference document the postmarket vulnerability management plan relies on.

Does FDA Require a Specific File Format?

FDA does not mandate a single specific SBOM file format by name, but its guidance and the eSTAR submission template point toward the two machine readable formats the industry has standardized on: SPDX (Software Package Data Exchange) and CycloneDX. Either format satisfies the machine readable expectation when it is complete. A spreadsheet or PDF component list, however well organized, does not satisfy this expectation on its own, because the underlying data has to also exist as a structured, tool readable export that a reviewer or automated system can parse against known vulnerability databases.

In practice, the choice between SPDX and CycloneDX usually comes down to what a manufacturer's existing development toolchain already generates rather than any FDA preference. SPDX tends to suit organizations already documenting license compliance; CycloneDX tends to suit organizations with an existing security tooling workflow, since it was built with vulnerability and dependency tracking as its primary use case.

What Minimum Elements Does a Complete SBOM Contain?

FDA's guidance references the NTIA's minimum elements framework as the floor for SBOM completeness. At minimum, every component entry needs:

• Component name and supplier. The software package's name and the organization that produces or maintains it.
• Version information. The specific version in use, since vulnerability databases are indexed by version, and a missing version number is the single most common deficiency reviewers cite.
• Dependency relationships. How components relate to one another, so a vulnerability in a nested, transitive dependency can still be traced back to the device.
• A current generation timestamp. A date confirming the SBOM reflects the software build actually submitted, not an earlier development snapshot.

What SBOM Deficiencies Draw an RTA or Deficiency Letter

Across the gap assessments ADB's regulatory team performs, a small number of recurring patterns account for most SBOM related findings:

• Non machine readable format. A component list that exists only as a spreadsheet or PDF export, with no corresponding SPDX or CycloneDX file.
• Missing version numbers. Components listed by name only, which prevents any automated cross reference against known vulnerability databases.
• Shallow dependency depth. An inventory that stops at the first layer of libraries instead of tracing transitive dependencies, leaving nested open source components invisible to the review.
• Stale generation date. An SBOM generated before the device's current software build, which signals the document was not regenerated after the last release.
• No vulnerability cross reference for off the shelf components. An SBOM that lists an embedded operating system or a third party communications stack without addressing whether known vulnerabilities in that component were assessed.

ADB's regulatory team reviews the SBOM against the 524B(b)(3) expectation as part of the Section 524B gap assessment, checking format, version completeness, dependency depth, and generation date against the specific build under review before it ever reaches an FDA reviewer.

Frequently Asked Questions

Does FDA require a specific SBOM format, SPDX or CycloneDX?

FDA does not mandate one specific format, but it expects a machine readable SBOM, and SPDX and CycloneDX are the two formats the industry and FDA's eSTAR template have standardized on. A spreadsheet or PDF component list alone does not satisfy the machine readable expectation.

What SBOM deficiencies does FDA cite most often?

The recurring patterns are components listed without version numbers, dependency trees that stop at the first layer instead of tracing transitive dependencies, and a generation date that predates the submitted software build.

Does the SBOM need to be updated after clearance?

Yes. FDA's expectation is a living document that stays current as components are patched or replaced, since the SBOM is the foundation for the postmarket vulnerability monitoring plan required under 524B(b)(4).