Pillar Guide · Updated 2026 · 14 min read

Medical Device SBOM Requirements for FDA

Talk to a MedTech cybersecurity expert

TL;DR

• Section 524B requires an SBOM for every cyber device. The 2026 final guidance specifies CycloneDX or SPDX in machine-readable form.
• NTIA minimum elements are mandatory: supplier, component name, version, unique identifier, dependency relationship, author, timestamp.
• Every component needs a vulnerability disclosure path (linked CVE feed or supplier advisory channel) and a postmarket monitoring plan.
• SBOM must cover firmware, OS, libraries, third-party services, and AI/ML model artifacts including foundation models.

What the statute and guidance require

Section 524B(b)(3) of the FD&C Act requires manufacturers of cyber devices to 'provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components.' The February 2026 final premarket cybersecurity guidance operationalizes this: machine-readable SBOM in CycloneDX 1.4+ or SPDX 2.3+, covering all software in the device, with linked vulnerability data and a documented maintenance plan.

The minimum data field checklist

1. Supplier name (NTIA)
2. Component name (NTIA)
3. Version of the component (NTIA)
4. Other unique identifier - PURL, CPE, or SWID (NTIA)
5. Dependency relationship (NTIA)
6. Author of the SBOM data (NTIA)
7. Timestamp (NTIA)
8. License (FDA expectation, not strictly NTIA)
9. Hash of the component (FDA - integrity verification)
10. End-of-support date (FDA - lifecycle planning)
11. Vulnerability disclosure path (FDA - postmarket monitoring)

Format choice: CycloneDX vs SPDX

Either is accepted. CycloneDX is more common in MedTech because of native support for vulnerability data (VEX), saved in the same document. SPDX is more common in regulated industries with strong license-compliance requirements. Whichever you choose, commit to it across the product line - mixing formats per submission is a friction point reviewers comment on.

What must be in scope

• Device firmware (bootloader, OS, application).
• All third-party libraries and SOUP including transitive dependencies.
• Cloud backend services and their dependencies.
• Mobile companion app dependencies (iOS and Android).
• AI/ML model artifacts - foundation models, fine-tuning datasets references, inference runtimes (ML-BOM extension).
• Container images for any cloud-side components.

Vulnerability mapping

Each component must be linked to a vulnerability source - NVD, OSV, GitHub Security Advisories, or supplier advisory feed. The 2026 guidance expects manufacturers to demonstrate they monitor and triage vulnerabilities continuously, not just at submission. Many teams pair CycloneDX SBOMs with VEX (Vulnerability Exploitability eXchange) documents that explicitly state which CVEs are exploitable in their context and which are not. VEX is the artifact that prevents 1,000-CVE noise from drowning real risk.

Postmarket maintenance

The SBOM is not a one-time deliverable. Reviewers expect:

• SBOM regenerated on every build - automated in CI/CD.
• Diff process that flags new components, version changes, and removed components.
• Vulnerability re-scan against latest CVE data at least daily.
• Triage SLA documented in the postmarket cybersecurity management plan.
• End-of-support tracking and migration plan for each component approaching EOS.

The most-cited SBOM deficiencies

• SBOM is PDF or spreadsheet, not machine-readable.
• Transitive dependencies missing - only top-level libraries listed.
• Cloud backend excluded entirely.
• No vulnerability disclosure path per component.
• AI foundation models not represented.
• Postmarket update cadence not documented in the cybersecurity management plan.

Frequently asked questions

Does the SBOM need to include the cloud backend?

Yes for any code that participates in delivering the device function. Hyperscaler infrastructure components below your application layer (substrate) are covered by the shared-responsibility model and do not need component-level enumeration, but your application stack and its dependencies do.

Do I need an SBOM for AI/ML models?

Yes. The 2025 AI-Enabled Device Software Functions draft guidance and the 2026 cybersecurity guidance both expect AI artifacts in the SBOM. Use CycloneDX's ML-BOM extension to represent models, datasets (by reference), and inference runtimes.

What is the difference between an SBOM and a VEX?

SBOM lists components. VEX (Vulnerability Exploitability eXchange) annotates whether each CVE affecting those components is actually exploitable in your specific configuration. Reviewers increasingly expect both - SBOM tells them what is in the device, VEX tells them what risk you have triaged.

How granular does the SBOM need to be?

Component-level for every dependency, including transitive. File-level is not required unless your build system makes it easy. Container images should be enumerated by their constituent layers and packages.

How is the SBOM delivered to FDA?

In the eSTAR submission as a machine-readable file (JSON or XML) attached to the cybersecurity section. PDF rendering for human readability is fine as a companion but does not replace the machine-readable form.

What tooling do you recommend?

For build-time generation: Syft, cdxgen, or your language ecosystem native tools (CycloneDX Maven/npm/Gradle plugins). For maintenance and triage: Dependency-Track or similar SBOM-management platform. For VEX: OpenVEX or CycloneDX VEX format.

Do I need to share the SBOM with users or hospital customers?

Section 524B requires the SBOM be provided to the Secretary (FDA). Many hospitals now require an SBOM as part of procurement (consistent with the FDA's encouragement and HHS 405(d) practices). Plan for both audiences.

How do I handle commercial third-party components that won't share their SBOM?

You still need to enumerate them in your SBOM with the data you have, document the gap, and include the supplier-evaluation evidence for that component in your QMS. Reviewers accept honest gaps with mitigation plans; they do not accept silent omissions.

What is the cadence for SBOM regeneration?

On every build, with diff and vulnerability scan. The submission SBOM is the build SBOM at the time of release. Postmarket SBOMs are regenerated on every patch and posted/exchanged per your maintenance plan.

What if a vulnerable component cannot be patched before submission?

Document the exposure in VEX as not-exploitable (with rationale) or as affected with a compensating control. A vulnerable component is acceptable if your VEX justification is defensible; an undocumented vulnerable component is a deficiency.

Where to go next

• FDA-Compliant SBOM Service
• Postmarket SBOM Maintenance Guide
• Section 524B of the FD&C Act