SBOM for Medical Devices: The 2026 FDA Pillar Guide

Everything a medical device manufacturer needs to know about Software Bills of Materials in 2026 - what they are, why the FDA requires them, which format to pick, how to generate one that survives review, and how it feeds the postmarket vulnerability-management loop. Aligned to the February 2026 final premarket cybersecurity guidance and Section 524B of the FD&C Act.

Last updated: June 2026.

1. What an SBOM Actually Is

A Software Bill of Materials is a structured, machine-readable inventory of every software component that ships inside a product. For a medical device it covers:

• Application code and the dependencies it imports.
• Firmware, bootloader, RTOS or embedded Linux distribution.
• OS packages (Debian, Yocto, Buildroot, Alpine, etc.).
• Third-party SDKs, drivers, and proprietary binaries.
• Transitive dependencies - the libraries your libraries pull in.
• Hashes, suppliers, license, and unique identifiers (CPE, PURL, SWID).

The NTIA "minimum elements" - supplier, component name, version, dependency relationship, unique identifier, author, and timestamp - are the floor, not the ceiling. The FDA expects an SBOM detailed enough to support CVE matching for the entire supported life of the device.

2. Why the FDA Requires an SBOM

Section 524B(b)(3) of the FD&C Act requires every "cyber device" submission to include a software bill of materials, "including commercial, open-source, and off-the-shelf software components". The February 2026 final guidance operationalizes that requirement and adds two things prior drafts only hinted at:

1. Format constraints - the SBOM must be a machine-readable file in a widely supported format (CycloneDX or SPDX).
2. Lifecycle obligations - the SBOM is not a one-time deliverable; it must be maintainable, regeneratable, and tied to your vulnerability-management plan.

If your SBOM is a spreadsheet built by hand from a vendor questionnaire, you do not have an SBOM the FDA will accept.

3. CycloneDX vs SPDX - Which to Pick

Both are accepted. The differences that actually matter for medical devices:

Dimension	CycloneDX	SPDX
Origin	OWASP	Linux Foundation
Strongest at	Vulnerability + VEX workflows	License compliance
Native VEX support	Yes (CycloneDX VEX)	Via separate spec (SPDX 3.0)
Tooling for embedded	Excellent (Syft, cdxgen, cyclonedx-cli)	Strong (sbom-tool, SPDX tools, Yocto integration)
Adoption in MedTech	Growing fast	Historically dominant

Pragmatic guidance: if you're starting fresh, pick CycloneDX 1.5+ JSON for the tighter vulnerability/VEX workflow. If you already produce SPDX from your build (especially Yocto), keep producing SPDX 2.3+ and add VEX separately. Either way, commit to one format per device and produce it from CI on every build. See our CycloneDX vs SPDX comparison for the deep dive.

4. Component Identifiers: CPE vs PURL vs SWID

Component names alone aren't enough to match CVEs reliably. You need identifiers:

• CPE (Common Platform Enumeration) - NIST's identifier scheme. Required to match against the National Vulnerability Database.
• PURL (Package URL) - origin-based identifier (npm, pypi, maven, deb, generic). Required to match against GitHub Advisory Database, OSV.dev, and most modern feeds.
• SWID (Software Identification Tags) - ISO/IEC 19770-2. Less common in medical devices.

A submission-grade SBOM carries both CPE and PURL where possible. Our CPE vs PURL guide covers the mapping pattern in detail.

5. Generating an SBOM (Without Lying to Yourself)

The single most common SBOM mistake is reconstruction - generating the SBOM from a spreadsheet rather than from the build. A reconstructed SBOM misses transitive dependencies, gets versions wrong, and falls out of date the moment the next build runs.

Generate from the build, in CI, on every release candidate:

Build context	Recommended tooling
Embedded Linux (Yocto)	meta-spdxscanner, create-spdx.bbclass, or cdxgen post-build
Buildroot	make legal-info + spdx-tools or CycloneDX wrappers
Containerized backend	Syft (CycloneDX or SPDX output)
Node / npm	cyclonedx-npm, @cyclonedx/cyclonedx-npm
Python	cyclonedx-py, pip-licenses
Go	cyclonedx-gomod, syft
Java / Maven / Gradle	cyclonedx-maven-plugin, cyclonedx-gradle-plugin
.NET	CycloneDX dotnet CLI
Mobile (iOS/Android)	cdxgen (covers Swift, Kotlin, Gradle)
Firmware binaries (no source)	Binary composition analysis: binwalk + cve-bin-tool, or commercial BCA
Proprietary third-party SDKs	Vendor-supplied SBOM, validated and merged

Merge the per-component SBOMs into a single device SBOM per release. Store it as a versioned build artifact alongside the firmware image.

6. Mapping the SBOM to CVEs

A submitted SBOM is the input to a continuous vulnerability-management process the FDA expects to run for the supported life of the device. The minimum feeds to subscribe to:

• NVD - canonical CVE source, CPE-matched.
• CISA KEV - known-exploited vulnerabilities, prioritized.
• GitHub Advisory Database (GHSA) - PURL-matched, often ahead of NVD.
• OSV.dev - aggregator, PURL-matched, fast.
• Vendor PSIRTs - chipset, OS, and SDK vendors directly.

Prioritization signals the FDA recognizes:

• CVSS v3.1 base + environmental.
• EPSS (Exploit Prediction Scoring System) - probabilistic.
• CISA KEV membership - binary, highest urgency.

The depth of this loop is the subject of our companion pillar, SBOM Vulnerability Management for Medical Devices.

7. VEX: Closing the Noise Loop

A naive SBOM-to-CVE match will surface dozens of irrelevant vulnerabilities - components present but not reachable, code paths not compiled in, mitigations already deployed. A VEX (Vulnerability Exploitability eXchange) statement is how you document "we know about CVE-X, here's why it doesn't apply to this device". The FDA expects VEX (or equivalent reasoning) for any CVE you choose not to remediate.

See VEX Documents for Medical Device FDA Submissions.

8. Labeling and Customer Disclosure

Under Section 524B and the 2026 guidance, you must make the SBOM available to device users (typically the hospital). Common patterns:

• A downloadable SBOM linked from the device's cybersecurity information page.
• An SBOM included in the technical file shipped to hospital biomed teams.
• A customer portal that pushes SBOM updates when components change.

The format and depth disclosed externally can differ from the submission SBOM - but it must be a true subset, not a different document.

9. SBOM Under EU MDR, IVDR, and the EU Cyber Resilience Act

If you sell into the EU, your SBOM is no longer just an FDA artifact:

• EU MDR / IVDR - cybersecurity is covered by Annex I 17.2 and MDCG 2019-16; SBOMs are expected as evidence.
• EU Cyber Resilience Act (CRA) - enters into force in stages through 2027; mandates SBOMs and vulnerability-handling for "products with digital elements". Many connected medical devices fall under both.

A single CycloneDX 1.5+ pipeline can satisfy all three jurisdictions. See EU MDR vs FDA cybersecurity crosswalk.

10. A 10-Item SBOM Submission Checklist

1. SBOM is machine-readable - CycloneDX 1.5+ JSON or SPDX 2.3+.
2. Generated by the build system, not reconstructed.
3. Covers firmware, OS packages, app code, third-party SDKs, and transitive deps.
4. Each component has a supplier, version, hash, and unique identifier (CPE and/or PURL).
5. Dependency relationships are encoded, not flattened.
6. A build provenance / timestamp / build ID is captured.
7. Regeneration is automated in CI and reproducible.
8. A vulnerability-management plan references the SBOM as its input.
9. VEX statements exist for CVEs that the team has triaged as not applicable.
10. The SBOM is available to users in accordance with Section 524B.

11. Frequently Asked Questions

Is an SBOM legally required for FDA submissions? Yes. Section 524B(b)(3) of the FD&C Act requires an SBOM for every cyber device submission, and the February 2026 final guidance operationalizes the requirement.

Does the FDA prefer CycloneDX or SPDX? The FDA accepts both equally. Pick the format your build pipeline supports best and commit to it per device.

Do we need an SBOM for Class I devices? Only if the device meets the statutory definition of a "cyber device" - i.e. it includes software validated, installed, or authorized by the sponsor and can connect to the internet. Most Class I devices do not, but check the definition carefully.

How often does the SBOM need to be updated? Every build that ships to a user, and any time a component changes. Lifecycle obligations under the 2026 guidance run for the entire supported life of the device.

What about SBOMs for AI/ML models? The FDA's AI/ML draft guidance (September 2025) extends SBOM thinking to model artifacts, training data lineage, and inference dependencies. CycloneDX 1.5 added an ML-BOM extension; we recommend adopting it for any AI/ML SaMD.

Can a vendor questionnaire replace a generated SBOM? No. The FDA explicitly calls out that the SBOM must be machine-readable and maintainable. Questionnaires are useful as inputs to a generated SBOM, not a substitute.

12. Where to Go Next

• Operational depth: SBOM Vulnerability Management for Medical Devices
• Format choice: CycloneDX vs SPDX for Medical Devices
• Identifiers: CPE vs PURL for Medical Device SBOMs
• VEX: VEX Documents for Medical Device FDA Submissions
• Premarket roadmap: FDA Premarket Cybersecurity Submission Checklist
• Section 524B explainer: FDA 524B Cybersecurity Requirements Explained

Need a hand productionizing your SBOM pipeline before your next FDA submission? Talk to Blue Goat Cyber.