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:

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:

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. How Blue Goat Cyber Approaches Medical Device SBOMs

An SBOM is not a build artifact you ship once - it is a living deliverable that has to survive vulnerability triage, deficiency letters, and postmarket updates. Here is how we run it.

• Build-system-generated, never hand-curated. SBOMs come from CycloneDX or SPDX generators wired into your build so components, versions, and hashes match what actually ships.
• Dual identifiers where they exist. Both purl and cpe are emitted so vulnerability feeds line up regardless of which identifier the advisory uses.
• Depth to transitive dependencies. First-level dependency lists are a common RTA trigger. Every SBOM we ship resolves transitive components with declared licenses.
• VEX pairing. Every SBOM is shipped with a VEX document so reviewers see which CVEs apply, which do not, and why.
• Postmarket monitoring wired in. SBOMs feed into an automated vulnerability watch that flags new CVEs and routes them into your CAPA process.
• Standards alignment. Format, content, and traceability match FDA's February 2026 guidance, AAMI SW96, and IEC 81001-5-1.

Our FDA-Compliant SBOM Services engagement is the entry point.

Frequently Asked Questions

Is an SBOM legally required for FDA submissions?

Does the FDA prefer CycloneDX or SPDX?

Do we need an SBOM for Class I devices?

How often does the SBOM need to be updated?

What about SBOMs for AI/ML models?

Can a vendor questionnaire replace a generated SBOM?

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
• Legal/compliance angle: Cleared a 510(k) but not doing postmarket cybersecurity? Am I breaking the law?
• FDA SBOM requirements - line-by-line submission checklist.
• Postmarket SBOM Maintenance for Medical Devices - keeping the SBOM accurate after clearance.

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

Free tools for this

• SBOM Readiness Checker - check an SBOM against the FDA's expected fields before you submit it.

References

Primary sources cited or relied on in this guide:

• Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (Feb 2026 final), U.S. FDA
• Section 524B of the FD&C Act (Consolidated Appropriations Act, 2023, §3305), U.S. Congress
• NTIA/NIST, The Minimum Elements For a Software Bill of Materials (SBOM), NTIA / U.S. Dept. of Commerce
• IMDRF Principles and Practices for Software Bill of Materials for Medical Devices, IMDRF
• ANSI/AAMI SW96:2023, Standard for Medical Device Security, AAMI/ANSI