How SBOMs Streamline Medical Device Security

TL;DR: A medical device SBOM is a complete inventory of the software inside a connected device, from in-house code to open-source and off-the-shelf components. The FDA requires one for cyber devices in premarket submissions, and it's the fastest way to answer "which of our devices are exposed?" when a new vulnerability lands. But an SBOM is only as trustworthy as what it was built from. For firmware-heavy devices, that means the shipped binary, not just the source.

Medical device manufacturers are asked to deliver innovation, quality, and security in equal measure. That was never easy, and the connected-device landscape has not made it easier. Traditional Application Security (AppSec) tools have earned their place, but they were built to read source code. They struggle with the binary components that get integrated at the final stages of a build, often with no source attached. That blind spot is exactly where regulators and attackers are now looking.

This guide covers what a medical device SBOM is, what the FDA actually requires, and how to make an SBOM that holds up. One idea runs through all of it: an SBOM is only as good as what it was generated from. Read the source and you learn what the device was meant to contain. Analyze the shipped binary and you learn what it actually contains.

What is a Software Bill of Materials (SBOM) for medical devices?

A medical device SBOM is a complete, machine-readable list of every software component inside a connected device, including in-house, third-party, open-source, and off-the-shelf code, plus their dependencies.

Think of it as an ingredients list for the device's software. It names each component, its version, and how the pieces relate, so manufacturers, hospitals, and the FDA can see what the device is made of and which parts might carry known vulnerabilities. The scope covers everything the device uses to function or to connect with other systems, from electronic health records to cloud platforms. If you want the fundamentals of the format itself, our explainer on what a software bill of materials is covers the basics. The rest of this page is about what makes them work in a medical device context.

Does the FDA require an SBOM for medical devices?

Yes. The FDA requires an SBOM for cyber devices in premarket submissions. Without adequate cybersecurity documentation, the agency can issue a Refuse to Accept notice and the submission stops.

This is mandated by Section 524B of the FD&C Act, which Congress added in late 2022. The FDA gained authority to refuse inadequate submissions on March 29, 2023, and began enforcing it on October 1, 2023. The requirement is spelled out in the FDA's cybersecurity guidance, and it has not gone away. If anything, it has hardened. Missing this is not a paperwork slip, it's a delayed product launch and the financial hit that comes with it.

Which FDA guidance is current, and what changed?

The current guidance is the FDA's February 2026 final guidance, which supersedes the June 2025 and September 2023 versions. The SBOM requirement is unchanged. Only the quality-system terminology changed.

This matters because a lot of published articles, including older versions of this one, still point at the September 2023 guidance. Here is the actual chain, so you're working from the right document.

The February 2026 update landed a day after the Quality Management System Regulation took effect, and its main job was aligning the guidance with QMSR and ISO 13485:2016. The core expectations, secure development, the SBOM, vulnerability management, and postmarket monitoring, carry over. You can confirm the current version on the FDA's medical device cybersecurity page. For the fuller regulatory picture, see our breakdown of what the FDA's guidance says about SBOMs.

Which medical devices need an SBOM?

Any cyber device needs an SBOM, meaning a device that includes software, can connect to a network, and has features that could be exploited. That covers most modern connected medical devices.

The FDA reads this broadly: if a device contains software or is software, treat the requirement as applying. The SBOM also kicks in when you make a software or connectivity change to a marketed device that triggers a new premarket review. Worth noting: many manufacturers keep SBOMs even for devices that fall outside the strict cyber-device definition, because a standalone lab instrument can still be compromised through something as simple as a USB drive. Documenting software across the board closes attack paths you'd otherwise leave off the table.

How does an SBOM improve medical device cybersecurity?

An SBOM improves medical device cybersecurity by giving teams a clear map of every software component, so when a new vulnerability appears they can find affected devices fast and act before patients are put at risk.

The biggest risks in your device usually aren't in the code you wrote. They're in the third-party and open-source components you pulled in to build it. When the next Log4j-scale flaw drops, the manufacturer with an accurate SBOM answers "are our devices affected?" in hours. The one without it starts a manual hunt while devices stay in use at the bedside. Beyond incident response, SBOMs help developers spot dependency conflicts early, surface unsupported components before they become liabilities, and flag restrictive software licenses before they create legal exposure. That's the difference between reacting to whatever breaks and managing what you actually ship.

What are the software bill of materials requirements for medical device manufacturers?

FDA SBOM requirements have two halves: premarket, the SBOM must carry NTIA baseline data fields, cover all software, and list known vulnerabilities; postmarket, it must be monitored and updated as vulnerabilities change.

On the premarket side, the SBOM has to include the NTIA minimum data fields for every component, not just the code you wrote, plus support status and end-of-support dates. It also has to identify known vulnerabilities, including any in CISA's Known Exploited Vulnerabilities catalog, and for each one explain how it was found, its risk to patient safety, and how you're responding. Vulnerability data can live inside the SBOM or in a separate document, and many teams use a VEX (Vulnerability Exploitability eXchange) statement to record whether a flaw actually affects the product. On the postmarket side, the guidance requires ongoing surveillance and updates to affected software, which in practice means keeping the SBOM current and notifying users when it changes.

What data fields must a medical device SBOM include?

A compliant SBOM must carry seven NTIA baseline attributes for each component: supplier name, component name, version, unique identifiers, dependency relationship, SBOM author, and timestamp, plus FDA-expected support status.

These fields give every component a clear identity and show how the pieces connect. The FDA draws them from the NTIA's foundational work on software transparency, then adds lifecycle expectations on top. Here is what each submission should carry.

A basic SBOM with only these fields meets the FDA's floor. A comprehensive one goes further, capturing every dependency down to the lowest level, using a machine-readable format like CycloneDX or SPDX, and including license data so you don't unknowingly ship software with restrictive terms.

Why isn't a source-code SBOM enough for medical devices?

A source-code SBOM lists intended dependencies. A binary SBOM analyzes the compiled artifact that actually ships. For firmware-heavy medical devices, the binary is where the real risk hides.

This is the gap traditional AppSec tools leave open, and it's the heart of the problem for connected medical devices. Manufacturers integrate binary components late in the build, frequently with no source code available. A source-only scan simply can't see inside them. Binary Software Composition Analysis decomposes the finished firmware image into its real components, open-source and proprietary alike, so your inventory reflects what runs on the device rather than what the manifest claims. A manifest describes intent. A binary is reality. For a medical device, that difference can be the difference between catching an unsupported, vulnerable library and shipping it into a hospital.

How should manufacturers keep medical device SBOMs current?

Treat the SBOM as a living document: generate it from the shipped build, enrich it with current vulnerability intelligence, link it to postmarket monitoring, and update it every time the software changes.

The failure mode the FDA is guarding against is the stale SBOM, accurate at submission and wrong within a quarter. A few practices keep you defensible: generate from the real build artifact rather than a design assumption, automate generation so it refreshes on every release, tie it to continuous vulnerability monitoring, and assign clear ownership. Post-market, your plan should show how you track new vulnerabilities, notify customers, and deploy patches, with response metrics feeding your annual report to the FDA. Done well, the SBOM stops being a submission chore and becomes the backbone of how you align with FDA requirements for medical device SBOMs over the life of the product.

Medical device SBOM services from Finite State

Most tools can generate an SBOM. Fewer can prove it reflects what actually shipped in a firmware-heavy device, and that is exactly where medical device manufacturers get stuck.

The Finite State platform is built for this case. Our binary Software Composition Analysis dissects uploaded binaries to reveal both open-source and proprietary components, giving you a granular, accurate view of the software ecosystem grounded in what runs on the device. Our end-to-end SBOM services cover generation, import, enrichment, and distribution, so you can bring in SBOMs from suppliers, enrich them with current vulnerability intelligence, and keep your security posture current. For FDA submissions, that comes together in a few practical pieces:

We integrate more than 150 AppSec scanning tools [verify before publishing] into one unified platform for visibility and risk management, with intuitive risk scoring and full VEX import and export so your vulnerability communication stays audit-ready.

FDA compliance should not be a last-mile scramble before a submission. It should be a continuous workflow grounded in what you actually ship. That's what we build. See how the platform supports medical device manufacturers, or explore what's next for medical device cybersecurity.