CycloneDX or SPDX - which format should we use?

FDA accepts either. CycloneDX is more common in security-tooling pipelines and pairs naturally with VEX. SPDX is broader (also used for license compliance) and is an ISO/IEC standard. Pick whichever your build toolchain produces natively; converters exist between the two.

Do hospitals get to see our SBOM?

Yes. Hospitals increasingly request the SBOM as part of procurement and post-market vulnerability response. The Healthcare Sector Coordinating Council (HSCC) Joint Security Plan and the AHA's medical-device security guidance both reference SBOM disclosure to operators.

How often does the SBOM need to be updated?

The SBOM should be regenerated for every software change that ships to the field - patches, hot-fixes, model updates, the lot. The FDA guidance ties SBOM maintenance to the device's supported lifetime, not a calendar cadence.

All terms

CybersecurityConnected & Cyber-Physical Devices Software LifecycleSBOM

Software Bill of Materials

A machine-readable inventory of all software components, including open-source and third-party libraries, used to build a medical device.

Reviewed by Christian Espinosa, Founder, Blue Goat CyberLast reviewed May 5, 2026

Definition

A Software Bill of Materials (SBOM) is a formal, machine-readable record of every software component - including third-party, open-source, and commercial dependencies - that ships in a medical device, together with the supply-chain relationships between those components. An SBOM typically lists each component's name, version, supplier, license, and a cryptographic identifier so vulnerabilities disclosed against any component can be matched back to the devices that contain it. The two industry-standard formats are CycloneDX (OWASP) and SPDX (Linux Foundation, ISO/IEC 5962:2021).

What the regulation says

Section 524B of the FD&C Act, added by the Consolidated Appropriations Act of 2023, makes a complete SBOM a statutory requirement for cyber device premarket submissions. FDA's September 2023 guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" specifies that the SBOM must be machine-readable (CycloneDX or SPDX), include commercial, open-source, and off-the-shelf components, identify support level and end-of-support dates for each, and describe the process for monitoring and addressing vulnerabilities throughout the device's supported lifetime. CISA's SBOM minimum elements (NTIA 2021) define the floor: supplier name, component name, version, unique identifier, dependency relationship, author, and timestamp.

What this means in practice

An SBOM is not a one-time artifact - it must be regenerated and reviewed whenever software changes and made available to operators (typically hospital security teams) who use it to assess the device's exposure to newly disclosed CVEs. In practice, MedTech teams generate SBOMs from their CI/CD pipeline (Syft, CycloneDX-Maven, SPDX tooling), pair each SBOM with a VEX document that explains which CVEs are not exploitable in their product, and store both with the Design History File. Hospital procurement increasingly requires an MDS2 form plus a current SBOM before purchase.

Use cases

2 scenarios

Premarket cybersecurity submission for a connected infusion pump

Product security engineer

Engineering produces a CycloneDX SBOM from the CI pipeline covering firmware, OS, and third-party libraries. They map each component to known CVEs, attach a VEX document marking unaffected vulnerabilities, and include the SBOM in the 524B section of the 510(k).

OutcomeFDA accepts the cybersecurity package on first review; hospital procurement teams reuse the SBOM for their own risk assessments.

Hospital responding to a new OpenSSL CVE

Healthcare delivery org (HDO)

A hospital biomed team queries vendor SBOMs for OpenSSL versions affected by a newly published critical CVE. They cross-reference vendor VEX statements to filter out devices where the vulnerable code path isn't reachable.

OutcomePatching is prioritized to ~12 truly affected device families instead of all 400+ network-connected devices.

Common pitfalls

•Generating an SBOM only at submission rather than continuously through the build pipeline.
•Omitting transitive dependencies, firmware blobs, or commercial third-party components such as RTOS or DRM libraries.
•Shipping an SBOM without a VEX (Vulnerability Exploitability eXchange) document - leaving operators to triage every CVE themselves.
•Treating SBOM generation as a regulatory checkbox rather than feeding it into a real vulnerability-monitoring workflow.

Frequently asked questions

An SBOM is required for any submission that meets the statutory definition of a 'cyber device' under section 524B of the FD&C Act - broadly, devices that include software validated, installed, or authorized by the sponsor and have the ability to connect to the internet. That captures most modern Class II and Class III software-containing devices.

Cross-references

Uses

Concepts or artefacts this term builds on.

Used by

Things that build on this term.

Section 524B of the FD&C Act(524B)

Primary references

5 sources

Link health: 3 verified 2 bot-blocked· last checked 2026-05-09

FDA·2CISA·1OWASP·1Linux Foundation·1

Inline markers like [1] jump to the matching reference above.