On this page
Key Takeaways
- CycloneDX 1.4+ and SPDX 2.3+ are both acceptable to the FDA; there is no stated preference between them.
- Machine-readable means JSON or XML. PDF, DOCX, XLSX, and CSV renderings are companions at best, never the submitted SBOM.
- Choose one format and use it across the entire product line; mixing formats between submissions creates reviewer friction.
- CycloneDX is the easier choice when you need native VEX, ML-BOM, or CBOM data in the same document.
- SPDX is the easier choice when license compliance and existing build tooling already produce SPDX documents.
The FDA accepts either CycloneDX (version 1.4 or later) or SPDX (version 2.3 or later), submitted as a machine-readable file, normally JSON or XML. The February 3, 2026 final premarket cybersecurity guidance names both and expresses no preference. What the FDA does not accept is a human-only artifact: a PDF component list, a spreadsheet, or a table pasted into the submission narrative.
Format is the single easiest SBOM deficiency to avoid and one of the most frequently cited. Teams build a genuinely complete component inventory, then export it to a PDF for tidiness and submit that. The reviewer cannot ingest it, cannot correlate it to vulnerability data, and issues a deficiency on a package that was substantively correct. This guide covers exactly what format the FDA will accept, the version floors that matter, how to pick between CycloneDX and SPDX, and the format-level errors that show up in deficiency letters.
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
| Format | Minimum version | Serializations | Best fit |
|---|---|---|---|
| CycloneDX | 1.4 | JSON, XML, Protocol Buffers | Security and vulnerability workflows, native VEX, ML-BOM, CBOM, HBOM |
| SPDX | 2.3 | JSON, YAML, XML, RDF, Tag-Value | License compliance, existing SPDX build tooling, SPDX 3.0 AI profile |
Submit JSON unless you have a specific reason not to. It is the serialization every ingestion tool handles, it diffs cleanly in version control, and it is what your own SBOM management platform will consume postmarket.
The SBOM attached to the cybersecurity section of your eSTAR submission must be the machine-readable file itself. A rendered PDF may accompany it for human readability, but it never substitutes for the JSON or XML.
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. A portfolio where one submission is SPDX Tag-Value and the next is CycloneDX XML forces reviewers to reorient every time, and it makes your own postmarket tooling harder to standardize.
Required fields, independent of format
Format choice does not change what has to be in the file. The NTIA minimum elements are the floor:
- Supplier name
- Component name
- Component version
- Other unique identifier (PURL, CPE, or SWID)
- Dependency relationship
- Author of the SBOM data
- Timestamp
The 2026 guidance adds expectations beyond the NTIA floor that reviewers do look for: component license, a hash for integrity verification, an end-of-support date, and a vulnerability disclosure path per component. Both CycloneDX and SPDX have native fields for all of these, so there is no format-driven excuse to omit them.
Format-level mistakes that draw deficiencies
- PDF or spreadsheet submitted as the SBOM. The most common and the most avoidable.
- A valid file that fails schema validation. Validate against the official CycloneDX or SPDX schema before attaching. Hand-edited SBOMs frequently break.
- Version below the floor. CycloneDX 1.2 or SPDX 2.2 output from an old tool. Upgrade the generator, do not hand-patch the version string.
- Identifiers omitted. A component with only a name and version cannot be correlated to CVE data. 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 reads as an uncontrolled process.
- 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 fill the FDA-expected fields beyond the NTIA floor: license, hash, end-of-support, and vulnerability disclosure path. 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.
FAQ
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.
