What SBOM Format Does the FDA Require? (2026)

A human-readable rendering alone can limit automated analysis. This guide explains format choices and validation practices without treating engineering preferences as FDA requirements.

Why this matters

Section 524B(b)(3) of the FD&C Act requires manufacturers of cyber devices to provide a software bill of materials covering commercial, open-source, and off-the-shelf software components. The statute does not name a format. The February 3, 2026 final premarket cybersecurity guidance operationalizes it, pointing to the widely adopted machine-readable formats and to the NTIA minimum elements as the field-level floor.

The practical consequence: format is not a stylistic choice. The reviewer's workflow assumes they can parse your SBOM, resolve component identifiers, and check them against vulnerability data. An SBOM that cannot be parsed fails that workflow regardless of how accurate its contents are. Format problems also compound postmarket, because the same file has to feed your continuous monitoring pipeline for the life of the device.

Accepted formats at a glance

Submit JSON unless you have a specific reason not to. It is widely supported, but confirm compatibility with your tools, it diffs cleanly in version control, and it is what your own SBOM management platform will consume postmarket.

Choosing between CycloneDX and SPDX

Both formats satisfy the FDA. The decision should be driven by what your toolchain already produces at the highest fidelity, and by what else you need to carry in the document.

Choose CycloneDX if:

• You want VEX statements in the same document family, or you are already generating CycloneDX VEX.
• You have AI or ML components and want the ML-BOM extension to describe models, datasets by reference, and inference runtimes.
• You have cryptographic inventory obligations and want CBOM.
• Your security tooling (Dependency-Track, Syft, cdxgen, Anchore, Snyk) is CycloneDX-native.

Choose SPDX if:

• Your organization already runs SPDX for open-source license compliance and the documents are well-maintained.
• Your build systems emit SPDX with better component coverage than any CycloneDX generator you have tried.
• You intend to adopt the SPDX 3.0 AI profile for AI-enabled device artifacts.

Whichever you pick, commit to it across the product line. Consistency can make internal postmarket tooling easier to standardize; it is not an FDA format rule.

Required fields, independent of format

The FDA guidance references the historical NTIA 2021 baseline:

The seven fields are the historical NTIA 2021 baseline referenced by the FDA guidance. CISA’s July 29, 2026 SBOM minimum elements supersede that baseline and add elements including author signature, SBOM version, component hash, and license information; these are not additional FDA-specific fields.

1. Supplier name
2. Component name
3. Component version
4. Other unique identifier (PURL, CPE, or SWID)
5. Dependency relationship
6. Author of the SBOM data
7. Timestamp

The FDA-specific additions are component support level and end-of-support date, which may be provided in a separate addendum. License and hash information belong to the CISA 2026 baseline, not these FDA-specific additions.

Format-level mistakes that draw deficiencies

• Human-only inventory. Provide a machine-readable representation rather than relying solely on a rendered document.
• A valid file that fails schema validation. Validate against the official CycloneDX or SPDX schema before attaching. Hand-edited SBOMs frequently break.
• Unsupported schema version. Confirm generator and consumer compatibility; the FDA specifies no version floor.
• Identifiers omitted. Names and versions can support searches, but identifiers improve automated correlation. Carry PURL for packages and CPE for operating systems, firmware, and commercial software.
• Flat component list with no dependency relationships. Dependency relationship is an NTIA minimum element, not an optional nicety.
• Mixed formats within one submission. One CycloneDX file for the device and one SPDX file for the cloud backend can require additional normalization in internal tooling.
• Stale timestamp. The submitted SBOM should correspond to the release build being submitted, not a snapshot from six months earlier.

How Blue Goat approaches this

We start by generating an SBOM from your actual build pipeline rather than reconstructing one by inspection, because a generated SBOM is reproducible and a reconstructed one is not. We validate the output against the official schema, check every component for a resolvable identifier, and record the FDA-recommended support level and end-of-support date, with license and hash data assessed against CISA 2026. Then we wire generation into CI so the SBOM regenerates on every build and the submission artifact is simply the release build's output. Where a component is commercial and the supplier will not provide an SBOM, we document the gap and the supplier-evaluation evidence rather than leaving a silent omission for a reviewer to find.

CTA

If you are unsure whether your current SBOM would survive a reviewer's ingestion step, we will validate the file against the schema, the NTIA minimum elements, and the 2026 guidance expectations before you submit. Talk to a MedTech cybersecurity expert.

Related

• FDA SBOM Requirements for Medical Devices (pillar guide)
• SBOM in a 510(k) Submission: Where It Goes
• Who Is Responsible for Supplier SBOMs
• Postmarket SBOM Maintenance

Free tools for this

• SBOM Readiness Checker - check an SBOM against the FDA's expected fields before you submit it.
• SBOM Diff & VEX Drafter - diff two SBOM versions and draft the VEX statements for the delta.