CycloneDX vs SPDX: Medical Device SBOM Compliance Guide

Every cyber device submission needs a software bill of materials under Section 524B. Teams routinely burn weeks debating which format the FDA wants. This guide answers that, then covers the part that actually affects your review.

Does the FDA require CycloneDX or SPDX?

The February 3, 2026 premarket cybersecurity guidance requires a machine-readable SBOM that includes, at minimum, the NTIA minimum elements. It names no format. Both CycloneDX and SPDX satisfy the requirement when generated correctly.

We have shipped submissions in both. Neither has ever drawn a deficiency for being the wrong format. What draws deficiencies:

• An SBOM delivered as a PDF, Word table, or printed spreadsheet.
• Missing NTIA fields, most often supplier name, unique identifier, and dependency relationships.
• An SBOM that does not match the firmware version under review.
• No stated method or tooling for how the SBOM was produced.
• No process for keeping it current after clearance.

The NTIA minimum elements, and where teams miss them

Identifiers are the most consequential of these. Without a PURL or CPE you cannot reliably match components to CVEs, which means your postmarket monitoring claim is unsupported.

CycloneDX for medical devices

CycloneDX is an OWASP project, now an Ecma International standard (ECMA-424), designed from the start around security use cases.

Strengths for device teams:

• Native VEX. Exploitability statements can be embedded in or linked to the SBOM using the same schema. For a device with hundreds of upstream CVEs that are not reachable in your configuration, this is the difference between a defensible position and an endless triage queue. See our VEX guide.
• Lean schema. Faster to generate, smaller artifacts, easier to diff between builds.
• Firmware and hardware support. Handles hardware components, services, and nested assemblies, which suits embedded devices with mixed firmware and third-party modules.
• CI/CD tooling. Generators exist for most build systems, and the artifact is small enough to attach to every build without friction.
• Pedigree and provenance. Useful for patched or forked open source, which is common in long-lived device firmware.

Weaknesses: licensing metadata is functional but less expressive than SPDX, and legal teams accustomed to SPDX license expressions sometimes push back.

SPDX for medical devices

SPDX is a Linux Foundation project and is published as ISO/IEC 5962:2021.

Strengths for device teams:

• Formal ISO standing. Easier to justify to a quality system that prefers to cite recognized standards, and often the format large hospital and enterprise customers ask for by name.
• Best-in-class licensing. The SPDX license list and license expression syntax are the industry reference for open source compliance and IP due diligence.
• Deep provenance. File-level detail, checksums, and relationship types support forensic-grade traceability.
• Supplier alignment. Many large upstream suppliers publish SPDX by default, so ingesting their data requires no conversion.

Weaknesses: heavier documents, a steeper learning curve, and VEX handled through a separate mechanism rather than the same schema.

CycloneDX vs SPDX: head-to-head for medical devices

Which SBOM format should your device team pick?

Choose CycloneDX if the SBOM's primary job is postmarket vulnerability management, you are generating per-build in CI, you have embedded firmware with hardware components, or you plan to publish VEX statements. This covers most device manufacturers, and it is our default recommendation.

Choose SPDX if your organization already runs an SPDX-based open source compliance program, your customers or suppliers specify it contractually, or license provenance is the dominant driver.

Do not maintain both by hand. Pick a canonical format, generate it in the build pipeline, and convert on demand. The CycloneDX CLI and Syft both convert between formats. Conversion is lossy in the direction of the weaker schema, so keep the richer artifact as your source of truth and treat the converted copy as a derived output with its own generation record.

Generating a compliant SBOM in your build pipeline

1. Generate from the build, not from a source scan. The SBOM must describe the binary you are submitting, including build-time and vendored dependencies a source scan misses.
2. Pin versions and emit PURLs for every component so CVE matching works without human interpretation.
3. Merge supplier SBOMs for third-party modules and record their authorship rather than silently absorbing their contents.
4. Attach the SBOM to the release artifact in your QMS so the SBOM version and the firmware version are inseparable.
5. Diff on every build and route new or changed components to security review.
6. Feed it into monitoring. An SBOM that is not being matched against a CVE feed weekly is not supporting the postmarket claim you made in the submission. See SBOM vulnerability management.
7. Regenerate on every change that reaches the field, including patches.

What to say about SBOM format in the submission

State the format and specification version, the tool and tool version used to generate it, the build artifact it corresponds to, how supplier SBOMs were incorporated, and how the SBOM will be maintained postmarket. That short paragraph pre-empts the most common SBOM follow-up questions.

A usable template, adapted per device:

The SBOM is provided in CycloneDX 1.6 JSON, generated by Syft v1.x during the release build of firmware v2.4.1 (build ID 20260714-a91f). Component identifiers are PURLs where a package ecosystem exists and CPEs for the embedded Linux base. Third-party supplier SBOMs for the BLE module and the analytics SDK were merged at build time and are marked with their originating supplier. The SBOM is regenerated on every release build and archived with the release record; the version accompanying this submission corresponds to the firmware submitted for review.

Three details in that paragraph do specific work. The build ID lets a reviewer confirm the SBOM was generated from the submitted artifact rather than assembled by hand afterward. Naming the identifier scheme signals that your postmarket CVE matching can actually run, which is the next question a reviewer asks. Declaring how supplier SBOMs were merged pre-empts the "components from third-party suppliers are not represented" deficiency, which is one of the most common SBOM findings we see.

What not to write: do not claim the SBOM is "complete" or "exhaustive." Reviewers know that embedded builds have blind spots, and an absolute claim invites a question you cannot fully answer. Describe the generation method and the known limits instead. If a component class is genuinely out of scope, say which and why (for example, the silicon vendor's ROM bootloader shipped as a signed binary with no manifest), and state how you monitor it.

The same component in CycloneDX and SPDX, side by side

Format arguments get shorter once you look at the actual records. Here is one dependency, a statically linked compression library, as each schema represents it.

CycloneDX 1.6 (JSON):

{
  "type": "library",
  "name": "zlib",
  "version": "1.2.13",
  "supplier": { "name": "Mark Adler" },
  "purl": "pkg:generic/zlib@1.2.13",
  "cpe": "cpe:2.3:a:zlib:zlib:1.2.13:*:*:*:*:*:*:*",
  "hashes": [{ "alg": "SHA-256", "content": "8a9ba2898e1d0d774ee..." }],
  "licenses": [{ "license": { "id": "Zlib" } }],
  "pedigree": { "patches": [{ "type": "backport", "diff": { "url": "..." } }] }
}

SPDX 2.3 (tag-value):

PackageName: zlib
SPDXID: SPDXRef-Package-zlib
PackageVersion: 1.2.13
PackageSupplier: Person: Mark Adler
PackageDownloadLocation: https://zlib.net/
FilesAnalyzed: true
PackageChecksum: SHA256: 8a9ba2898e1d0d774ee...
PackageLicenseConcluded: Zlib
PackageLicenseDeclared: Zlib
ExternalRef: SECURITY cpe23Type cpe:2.3:a:zlib:zlib:1.2.13:*:*:*:*:*:*:*
ExternalRef: PACKAGE-MANAGER purl pkg:generic/zlib@1.2.13
Relationship: SPDXRef-Firmware CONTAINS SPDXRef-Package-zlib

Both carry every NTIA element. The differences that matter in practice are visible here: CycloneDX puts the security identifiers in first-class fields and models the backported patch natively through pedigree, while SPDX pushes identifiers into ExternalRef entries and expresses structure through explicit Relationship lines. That relationship model is more expressive, and it is also the field teams most often leave incomplete, which is exactly what breaks a transitive dependency tree.

Where SBOM data comes from in embedded builds

Format is downstream of generation. The gaps in a device SBOM are almost always caused by the build, not the schema.

An SBOM assembled from more than one of these rows is a merge, and the merge is where authorship and duplicate-component errors appear. Deduplicate on PURL, not on name, and keep the supplier's original artifact alongside your merged one.

Validating an SBOM before you ship it

Run these checks in CI and fail the build on the first three.

The identifier and depth checks catch the two conditions that make an SBOM look complete while being useless for CVE matching.

Converting between CycloneDX and SPDX

Migration is rarely a clean cut, and the risk is losing data quietly.

1. Freeze the current format and record the last artifact per released firmware version. You will need those for postmarket questions about older builds.
2. Generate both formats in parallel for one release cycle from the same build, then diff component counts and identifier coverage. Any delta is a generator gap, not a schema difference.
3. Move VEX last. If you are leaving CycloneDX, decide first whether exploitability statements move to CSAF, then rewrite the open statements before retiring the old pipeline.
4. Update the submission narrative and your QMS SOP in the same change record, so the documented tooling matches what the pipeline actually runs.

Never re-issue a converted SBOM for an already-cleared build as if it were the original. Keep the original and mark the conversion as a derived artifact with its own generation timestamp and tool version.

How Blue Goat Cyber approaches SBOM format selection

We start from where the SBOM will do the most work over the device lifetime, which is almost always postmarket monitoring, then wire generation into the build so the artifact stays true without manual effort. We validate NTIA completeness, fix identifier gaps that break CVE matching, and deliver the submission narrative alongside the file. Ongoing monitoring is available through postmarket SBOM and VEX monitoring.

Where this fits in the cluster

• SBOM Vulnerability Management for Medical Devices
• CPE vs. PURL in Medical Device SBOMs
• VEX Documents for Medical Devices
• SBOM for Medical Devices

Related from Blue Goat Cyber

• FDA Premarket Cybersecurity Services
• Postmarket SBOM & VEX Monitoring
• FDA Cybersecurity Deficiency Response

FAQ

Which SBOM format does the FDA prefer?

Neither. The February 3, 2026 guidance requires a machine-readable SBOM containing the NTIA minimum elements and does not specify a format. CycloneDX and SPDX are both routinely accepted. Format choice has never been the deficiency in submissions we have handled; missing fields and non-machine-readable files have been.

Can I use CycloneDX for a SaMD 510(k) submission?

Yes. CycloneDX is fully acceptable for Software as a Medical Device submissions and is often the better fit, because SaMD dependency trees change frequently and CycloneDX is cheap to regenerate per build. Include container base images and cloud service dependencies if they are part of the device.

Is SPDX an ISO standard?

Yes. SPDX 2.2.1 was published as ISO/IEC 5962:2021. CycloneDX is standardized through Ecma International as ECMA-424. Both have formal standing; neither confers a regulatory advantage with the FDA.

What is the difference between CycloneDX and SPDX for VEX?

CycloneDX supports VEX natively in the same schema, so exploitability statements can travel with or alongside the SBOM using one toolchain. SPDX users typically publish VEX separately, commonly via CSAF. If exploitability triage is a major part of your postmarket workload, CycloneDX reduces friction.

How do I convert SPDX to CycloneDX for medical software?

Use the CycloneDX CLI or Syft. Conversion is reliable for core component data but lossy for format-specific detail, particularly SPDX file-level license findings. Keep the original as your source of truth, record the conversion tool and version, and validate NTIA completeness on the output before submitting it.

What are the NTIA minimum elements for medical device SBOMs?

Supplier name, component name, component version, other unique identifiers such as PURL or CPE, dependency relationships, author of the SBOM data, and a timestamp. The FDA additionally expects support level and end-of-support information for each component, plus your process for keeping the SBOM current after clearance.

Sources & primary references

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
• The Minimum Elements For a Software Bill of Materials (NTIA)
• ISO/IEC 5962:2021 SPDX Specification
• ECMA-424 CycloneDX Bill of Materials Standard
• CycloneDX Specification
• SPDX Specification (Linux Foundation)