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.

Medical Device SBOM Requirements for FDA: A Complete Checklist

On this page

By Christian Espinosa, MBA, CISSP

Founder & CEO · Blue Goat Cyber

Key Takeaways

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.

Talk to a MedTech cybersecurity expert

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

Supplier name (NTIA)
Component name (NTIA)
Version of the component (NTIA)
Other unique identifier - PURL, CPE, or SWID (NTIA)
Dependency relationship (NTIA)
Author of the SBOM data (NTIA)
Timestamp (NTIA)
License (FDA expectation, not strictly NTIA)
Hash of the component (FDA - integrity verification)
End-of-support date (FDA - lifecycle planning)
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

A pass/fail self-check before you attach the SBOM

Run these six checks on the actual file you plan to submit, not on a sample. Each one maps to a deficiency we have seen issued.

Check	How to run it	Fail condition
Schema validity	Validate against the CycloneDX or SPDX schema for the declared version	Any validation error
Identifier coverage	Count components with a PURL or CPE, divide by total	Below roughly 95 percent, or any first-party-critical component missing one
Version precision	Search for version strings like "latest", "master", or empty values	Any occurrence
Depth	Compare component count against the dependency tree from your build system	SBOM is materially smaller than the build tree, which means transitive dependencies are missing
Provenance	Confirm the SBOM timestamp and build ID match the submitted firmware	Any mismatch, including an SBOM generated after the release
Feed match dry run	Run the SBOM through your CVE matcher	Components that silently match nothing because the identifier is malformed

The identifier check is the one that most often fails silently. A component with no PURL and no CPE will never match a CVE feed, so your postmarket monitoring reports zero findings for it forever. That is worse than a known gap, because nothing alerts.

Scope boundaries that cause arguments

Three scope questions come up on nearly every program.

Hardware-adjacent firmware. A signed binary blob from a silicon vendor with no manifest cannot be decomposed. List it as a single component with the supplier, version, and hash you do have, and state the limitation. Silence reads as an omission; a documented boundary reads as rigor.

Cloud infrastructure. Your application containers, runtimes, and libraries are in scope. The hyperscaler's substrate below your workload is covered by the shared-responsibility model. Say which line you drew and why, in one sentence, in the SBOM narrative.

Development-only dependencies. Build tooling that does not ship in the device is not part of the device SBOM, but it is part of your supply-chain risk. Keep a separate build-environment inventory. Reviewers rarely ask for it; a compromise of it is still your problem.

What "maintained" means in practice

The guidance expects the SBOM to be a living artifact, and reviewers test that claim by looking for the mechanism, not the promise. A maintained SBOM has four observable properties:

It is produced by the build, so it cannot drift from the shipped artifact.
It is versioned and archived per release, so any fielded device version can be reconstructed years later.
It is diffed release to release, so new and removed components are visible without manual reading.
It feeds a matcher that runs on a schedule, so new CVEs against old components surface without a new build.

If any one of those is missing, the program has a gap a researcher can find before you do. The deepest treatment of the operational side lives in the SBOM vulnerability management guide; format mechanics are covered in CycloneDX vs SPDX.

Where to go next

Most teams read an SBOM checklist, agree with it, and then stall because the next move is not obvious. The gap is rarely knowledge. It is that generating a machine-readable SBOM touches the build system, and the build system belongs to engineering, while the submission belongs to regulatory. Nothing moves until one person owns both ends.

Start by naming that owner. One engineer with commit access to the build pipeline, accountable for producing the SBOM on every tagged release, is worth more than a committee. Give that person a single deliverable for the first two weeks: a CycloneDX or SPDX file generated automatically by the build, checked into the release artifact store alongside the firmware image. Do not worry yet about completeness. Worry about automation, because a hand-assembled spreadsheet will be stale the day after you file and will not survive the first postmarket update.

Then run the completeness pass. Walk the seven NTIA minimum elements against your generated file and mark each component that fails: missing supplier, missing version, missing unique identifier, missing dependency relationship. The failures cluster in predictable places. Vendored source copied into your tree years ago, statically linked libraries the scanner cannot see, RTOS components shipped as binaries, and bootloaders. Each of those needs a manual entry with a documented justification for how you determined the version.

Third, decide your support status story before a reviewer asks. For every component, you need a level of support statement and an end-of-support date. Where the upstream project has no published date, say so explicitly and describe the monitoring you do instead. Silence in that column reads as an unanswered question, and unanswered questions become deficiencies.

If you have one week, spend it on automation and the support status column. Those two items account for the majority of the SBOM findings we see in cybersecurity deficiency letters. Format arguments between CycloneDX and SPDX almost never appear.

Once the SBOM exists and regenerates itself, the work shifts to keeping it alive across the fleet. That is a different discipline with its own cadence, triage rules, and evidence trail.

FDA-Compliant SBOM Service - we build the generation pipeline, fill the manual gaps, and hand back a submission-ready file with the support status column complete.
Postmarket SBOM Maintenance Guide - the operating model for keeping the SBOM current after clearance, including triage timelines and fleet versioning.
Section 524B of the FD&C Act - the statutory language that makes the SBOM a condition of a valid submission rather than a nice-to-have attachment.