FDA SBOM requirements for medical devices: a practical guide for manufacturers and hospitals

A software bill of materials (SBOM) is an inventory of the software components in a medical device, with each component's supplier, version and dependencies. New to SBOMs? Read what is an SBOM.

Yes. FDA guidance expects an SBOM for any device with software or firmware, and Section 524B(b)(3) of the FD&C Act makes it a legal requirement for cyber devices.

Yes, and FDA reads it broadly. A cyber device has sponsor validated software, could be vulnerable to cybersecurity threats, and can connect to the internet by any means, intended or not. That covers Wi-Fi, Bluetooth, cellular and Ethernet, and also USB or serial ports, even when they are only used for servicing. FDA reviews the whole system, including apps, cloud and update services.

510(k), De Novo, PMA and IDE submissions. For cyber devices, Section 524B makes the SBOM a legal requirement in 510(k), De Novo and PMA submissions. For an investigational device exemption (IDE), FDA's guidance recommends one.

NTIA's October 2021 baseline attributes (author, timestamp, supplier, component name, version, hash, unique identifier, relationship), plus each component's level of support and end of support date.

FDA's guidance asks for a machine readable SBOM, typically SPDX or CycloneDX. In practice, reviewers also expect a human readable table of the same fields.

Either. FDA names no format. It asks for a machine readable SBOM and encourages industry accepted formats, which in practice means SPDX or CycloneDX. SBOM Studio ingests and outputs both.

With every software change, one SBOM per release, and checked on a fixed schedule for new vulnerabilities in between. FDA also expects your security risk documentation to be updated as new information arrives, so residual vulnerabilities need reassessing as exploits and scores change.

Common reasons include missing baseline fields, blank level of support or end of support data, components at or near end of life, and known vulnerabilities listed without a risk assessment. These requests, sometimes called deficiency or hold letters, pause the review until you correct the SBOM and respond.

Not yet. FDA reviews against the documents its guidance cites, which today means NTIA's October 2021 baseline. CISA's 2026 Minimum Elements are best practice.

SBOM Studio is generation agnostic: it works with SBOMs from any generator or supplier. MDMs without an SBOM can have one generated from their firmware binary by partners in the CyBeats Marketplace, including Keysight, and brought straight into SBOM Studio. CyBeats also maintains sbomgen, an open source guide to SBOM generation tools on GitHub.

Request them in procurement, map them to the device inventory, use the manufacturer's VEX to prioritize exploitable vulnerabilities, and track components approaching end of support. Based on CyBeats' work with Health-ISAC, HDOs increasingly ask for SBOMs during procurement.

The MDS2 (Manufacturer Disclosure Statement for Medical Device Security) describes a device's security features. The SBOM lists the software components inside it. Hospitals should ask for both: the MDS2 shows how the device is protected, the SBOM shows what could become vulnerable.

FDA's 2026 guidance does not require VEX; it asks for each known vulnerability with a risk assessment. VEX is a practical way to share that status. Hospitals use it to act first on vulnerabilities the manufacturer marks exploitable, and recheck it with each update.

It stops receiving security fixes, so new vulnerabilities stay open. Track end of support dates from the SBOM so replacement, or compensating controls such as network segmentation, are planned and budgeted in time.

MDMs use SBOM Studio to keep a current SBOM and VEX for every release and share them with customers. HDOs use SBOM Consumer to govern the SBOMs they receive, map them to their device inventory and act on new vulnerabilities.