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.

Reviewed October 22, 2026 against the February 3, 2026 final guidance.

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 2021 minimum elements are supplier, component name, version, dependency relationship, unique identifier, author, and timestamp. 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. The FDA expects an SBOM detailed enough to support CVE matching for the entire supported life of the device.

Free to share with a link to this page: <a href="https://bluegoatcyber.com/resources/infographics/medical-device-sbom-lifecycle">The medical device SBOM lifecycle (Blue Goat Cyber)</a> Full-size infographic and text version

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 3, 2026 FDA guidance, §V.A.4(b), p. 17 says manufacturers "should provide machine-readable SBOMs" and that "Industry-accepted formats of SBOMs are encouraged". It names no format or version floor. It also recommends component support level and end-of-support date, which may be provided in a separate addendum. Build automation is useful practice, not a prescribed FDA generation method.

3. CycloneDX vs SPDX - Which to Pick

Both are industry-accepted options. 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 with external VEX, or use SPDX 3.0’s native Security profile. Either way, consider one canonical format per device and automated generation in CI. 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. Useful for NVD applicability matching; the NVD API also supports CVE-ID and keyword queries.
• PURL (Package URL) - origin-based identifier (npm, pypi, maven, deb, generic). Useful for ecosystem advisory matching, but not a prerequisite for all vulnerability searches.
• 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)

How to create an SBOM for a medical device, step by step

1. Scope the device system. List every software-bearing part: device firmware, operating system, mobile app, cloud service, clinician portal, and any AI model and its runtime. Section 524B(b)(3) covers commercial, open-source, and off-the-shelf components, so include them all. See our Section 524B guide for the full requirement.
2. Pick a format and identifiers. Choose CycloneDX or SPDX (section 3) and use PURL or CPE identifiers (section 4) so components match vulnerability databases.
3. Generate from the build. Run a generator for each build context (table below) in your build pipeline, with manual enrichment and validation where needed.
4. Add what tools miss. Binary-only firmware, vendor SDKs, and chip-level components need binary analysis or a supplier SBOM.
5. Include AI components. Record ML frameworks, inference runtimes, pretrained or third-party models, and their versions. Our AI/ML medical device security page covers how those components are tested.
6. Add support status. For each component, record the level of support and end-of-support date, which the FDA expects alongside the SBOM.
7. Merge and review. Combine per-part SBOMs into one device SBOM per release, then have an engineer check for missing or wrong entries.
8. Map to vulnerabilities. Check every component against known vulnerabilities and document patient-harm assessments (sections 6 and 7).
9. Version and maintain it. Store the SBOM with each release and regenerate it on every software change for the supported life of the device.

Manual reconstruction can miss transitive dependencies or introduce version errors. Validate the inventory against the released software regardless of generation method.

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". Document device-specific applicability and risk reasoning for known vulnerabilities. VEX is optional; the final guidance does not mention or require it.

See VEX Documents for Medical Device FDA Submissions.

8. Labeling and Customer Disclosure

Section 524B(b)(3) requires the SBOM to be provided to the FDA (the Secretary). Availability to device users is a labeling recommendation in the 2026 guidance, not that statutory obligation. 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 - software information-security provisions appear in MDR Annex I 17.2 and IVDR Annex I 16.2. An SBOM can support technical documentation and vulnerability management; neither regulation imposes a universal named SBOM format.
• EU Cyber Resilience Act (CRA) - products covered by the MDR or IVDR are excluded under Article 2(2)(a) (MDR) and (b) (IVDR). Separate companion products need their own applicability assessment. Do not apply CRA reporting duties to an MDR/IVDR-covered device merely because it is connected.

A shared SBOM pipeline can support documentation across jurisdictions, but applicability and evidence needs must be assessed separately. See EU MDR vs FDA cybersecurity crosswalk.

10. A 10-Item SBOM Submission Checklist

1. SBOM is machine-readable, using an industry-accepted format appropriate to your tooling; no FDA version floor is specified.
2. Generated by the build system, not reconstructed.
3. Covers firmware, OS packages, app code, third-party SDKs, and transitive deps.
4. Review supplier, version, and unique identifiers; CPE and PURL are useful where available. Hashes support the CISA 2026 baseline.
5. Dependency relationships are encoded, not flattened.
6. A build provenance / timestamp / build ID is captured.
7. Consider automated regeneration in CI for reproducibility; this is engineering advice.
8. A vulnerability-management plan references the SBOM as its input.
9. Evidence-supported vulnerability assessments exist for CVEs triaged as not applicable; VEX may communicate them if chosen.
10. The SBOM is provided to the FDA under Section 524B(b)(3); plan user availability under the labeling recommendation.

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 can omit relevant transitive components. 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 align with the FDA's February 3, 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 Management 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