The requirement to produce a software bill of materials for a medical device reads in two sentences in the statute and in about thirty pages across the FDA's premarket guidance. Neither document tells you how to generate an SBOM for a firmware image that combines a vendor-provided real-time operating system, a proprietary BLE stack, a half dozen cryptographic libraries pulled in via a yocto recipe, and a handful of in-house drivers written over the past fifteen years. That gap between the written requirement and the engineering reality is where most medical device SBOM programs stall.
After working through this with a number of device manufacturers, a few practical patterns have emerged. The regulators are flexible about tooling and format, but inflexible about completeness, accuracy, and the ability to act on the SBOM when a vulnerability is disclosed. The teams that succeed treat SBOM as a continuous engineering artifact rather than a document produced for a single submission.
What Regulators Actually Ask For
Section 524B of the FD&C Act says the SBOM must include commercial, open-source, and off-the-shelf software components. The FDA's September 2023 premarket guidance specifies that the SBOM must be machine-readable, and it references SPDX, CycloneDX, and SWID as acceptable formats. The NTIA minimum elements -- supplier, component name, version, unique identifier, dependency relationship, author, timestamp -- are the floor. The CISA Software Supply Chain Guidance extends this with expectations around completeness depth and vulnerability linkage.
The International Medical Device Regulators Forum published the "Principles and Practices for Medical Device Cybersecurity" in 2020 and updated it subsequently with specific SBOM guidance. The IMDRF principles are increasingly cited by regulators outside the US, and they broadly track the FDA position: the SBOM should be accurate, complete for the device and its supporting infrastructure, updated when the software changes, and useful for vulnerability management.
In Europe, the Medical Device Regulation (MDR) 2017/745 and the In Vitro Diagnostic Regulation (IVDR) 2017/746 do not name SBOMs explicitly, but the Essential Requirements around IT security, the MDCG 2019-16 guidance on cybersecurity, and the Radio Equipment Directive delegated acts push manufacturers toward equivalent documentation. The NIS2 Directive adds obligations for medical device manufacturers classified as essential or important entities.
Why Firmware SBOMs Are Harder Than Application SBOMs
For a web application running Node.js, generating an SBOM is mostly an exercise in parsing the lockfile. The tooling is mature, the package ecosystem is well-identified, and the SBOM maps cleanly to what actually ships. Medical device firmware is not that.
The first complication is the build system. A device running Yocto, Buildroot, or a vendor-specific build system composes the final firmware from dozens of recipes, each of which pulls source from upstream repositories, applies patches, and produces binaries. Generating an SBOM means tracing every recipe back to its source package, capturing the version and the patches applied, and representing that in the SBOM format. Tools like create-image-sbom and the SPDX SBOM extractor for Yocto help, but they require discipline in how recipes are written.
The second complication is proprietary components. Silicon vendors ship RTOSes, BLE stacks, and cellular modems as binary blobs with their own internal SBOMs -- or without SBOMs at all. The device manufacturer's submission still has to account for them. In practice this means vendor SBOMs are requested in procurement, stitched into the device-level SBOM using CycloneDX's externalReferences or SPDX's DocumentRef mechanism, and reconciled against binary analysis when the vendor will not provide a complete list.
The third complication is the hardware-firmware boundary. A modern medical device has firmware running on a main application processor, firmware running on one or more coprocessors, bootloaders, and increasingly, FPGAs or ASICs with their own firmware. The SBOM should cover all of these, which requires coordination across engineering disciplines that historically did not share dependency data.
Format Choices: SPDX vs CycloneDX vs SWID
All three formats are accepted, but they are not equivalent. SPDX is more verbose, better supported in Linux-rooted build systems, and strong for license analysis. CycloneDX is more compact, better suited for vulnerability-centric workflows, and has a richer vulnerability extension (VEX) model. SWID tags are focused on identifiers for installed software and are less commonly used as the primary SBOM format for medical devices.
Most medical device teams end up producing CycloneDX as the primary format because the VEX integration is operationally valuable. When a CVE is disclosed against a component in the SBOM, the manufacturer can publish a VEX statement indicating whether the device is actually affected, and the VEX lives alongside the SBOM in a way that downstream consumers -- hospitals, integrators, the FDA -- can ingest directly. SPDX is generated as a secondary format when the build system produces it naturally or when a specific customer requires it.
The Depth Question
A recurring debate is how deep the SBOM needs to go. The NTIA minimum elements require the direct dependencies, but the FDA guidance and most mature programs now push for transitive dependencies as well, because that is where most exploitable CVEs actually live. The practical answer is that the SBOM should go as deep as the dependency resolution can reliably reach.
For a Yocto-built Linux firmware, that means every package in the final image, including the libraries inside each package. For a containerized backend, that means every language-level dependency, every OS package in the base image, and the base image itself. For a native application built with static linking, it means the source components that went into the build, reconstructed from the build system because the binary no longer has them separately identifiable.
Where the dependency resolution does break down -- a statically linked binary from a third party, an obfuscated vendor library -- the SBOM should say so explicitly. A "known unknowns" entry is more useful to a regulator than a silent gap, and CycloneDX's metadata and SPDX's annotations both support this.
Vulnerability Linkage and Fleet Awareness
The SBOM is a starting point for vulnerability management, not an endpoint. The operational value comes from matching SBOM components to vulnerability feeds -- NVD, OSV, vendor advisories, KEV -- and turning the matches into work items. The matching is harder than it sounds because component identifiers across sources are inconsistent. The same OpenSSL version might be identified as "openssl 3.0.2" in one feed, "pkg:github/openssl/openssl@OpenSSL_3_0_2" in another, and "cpe:2.3:a:openssl:openssl:3.0.2" in a third. Good SBOM tooling normalizes these and handles version ranges correctly.
Fleet awareness is the next layer. When a manufacturer ships firmware version 1.4.2 to twenty thousand installed units and firmware version 1.5.0 to five thousand, a new CVE in a library that was updated between those versions affects only the 1.4.2 fleet. The SBOM infrastructure has to support per-version queries and tie back to the field inventory. Most device manufacturers historically did not have this capability, and building it is a significant part of the FDA compliance lift.
Sharing SBOMs With Customers
Hospitals and integrated delivery networks are increasingly requesting SBOMs from medical device manufacturers as part of procurement. The AHA's Model Medical Device Procurement Contract Language, the HSCC's Medical Device and Health IT Joint Security Plan, and the Mayo Clinic's MDS2 (Manufacturer Disclosure Statement for Medical Device Security) all contemplate SBOM sharing.
The sharing question raises concerns -- manufacturers worry about revealing vulnerabilities to competitors or to attackers, and customers worry about being unable to interpret raw SBOM data. The pragmatic answer is a tiered sharing model: a public VEX-enabled summary, a contractually protected detailed SBOM for purchasers, and a confidential detailed version for coordinated vulnerability disclosure with trusted researchers.
How Safeguard Helps
Safeguard generates SPDX and CycloneDX SBOMs directly from medical device firmware builds, reconciles them with vendor-supplied component data, and produces the VEX statements the FDA and hospital procurement expect. The platform links SBOM components to KEV, NVD, OSV, and ICS-CERT feeds in real time and maintains the per-version fleet awareness that turns an SBOM into actionable postmarket vulnerability management. Manufacturers use Safeguard to produce the machine-readable artifacts the FDA premarket guidance and Section 524B require, to share SBOMs with hospital customers under the appropriate confidentiality tier, and to demonstrate audit-ready evidence that the supply chain is being continuously monitored rather than documented once.