FDA SBOM Requirements for Medical Devices (2026 Guide)

TL;DR: Yes, the FDA requires a Software Bill of Materials (SBOM) for cyber devices in premarket submissions. It's mandated by Section 524B of the FD&C Act, and the requirement is still in force under the FDA's current February 2026 guidance. The SBOM must be machine-readable, list every software component, and stay current across the device's life. The rules did not loosen. Only the quality-system terminology around them changed.

Medical devices run on software you didn't all write. A modern infusion pump, imaging system, or Software as a Medical Device pulls in commercial code, open-source libraries, and third-party components, each with its own vulnerabilities. That's why the FDA now treats an SBOM as a baseline of medical device security, not a paperwork afterthought. This guide covers what the current FDA cybersecurity guidance on SBOMs actually requires, which devices are in scope, and where manufacturers most often get tripped up.

For context on scale: in 2023 research from Finite State, Health-ISAC, and Securin, vulnerabilities identified in medical products and devices rose 59% year over year, with more than 16% already weaponized [verify before publishing]. Regulators noticed. The rules that followed are the subject of this guide.

Does the FDA require a software bill of materials (SBOM) for medical devices?

Yes. For cyber devices, an SBOM is mandatory in FDA premarket submissions under Section 524B of the FD&C Act, not an optional best practice.

This is the short answer to the question most manufacturers ask first. A software bill of materials is a complete inventory of the software components in your device, and the FDA now expects it as part of the cybersecurity documentation package for any device that qualifies as a cyber device. Submit without an adequate SBOM and the agency can refuse to accept the submission outright.

What does Section 524B of the FD&C Act require?

Section 524B requires makers of cyber devices to submit a cybersecurity plan, design the device for patchability, and provide an SBOM covering commercial, open-source, and off-the-shelf components.

This is the piece worth understanding clearly: Section 524B is the law, and the FDA's guidance is the interpretation of how to meet it. Congress added 524B to the FD&C Act in late 2022. The FDA gained authority to refuse inadequate submissions on March 29, 2023, and began actively enforcing it on October 1, 2023. Section 524B(b)(3) is the specific clause that requires the SBOM. Guidance documents can be revised, and they have been, but the statutory SBOM obligation sits underneath all of them and does not move.

What are the current FDA SBOM requirements?

Current FDA SBOM requirements: a machine-readable SBOM aligned with NTIA minimum elements, listing every software component with version and support status, maintained across the device lifecycle.

In practice, that means four things the FDA looks for. The SBOM must be machine-readable, typically in SPDX or CycloneDX format. It must be complete, covering manufacturer-developed, commercial, and open-source components plus their upstream dependencies. It must carry support information, including whether each component is still maintained and its end-of-support date. And it must be accurate against what actually shipped, consistent with your architecture and risk documentation. An SBOM that lists the code you meant to ship, rather than the code the device runs, is where reviews stall.

Which FDA guidance documents reference SBOMs for medical device cybersecurity?

SBOMs appear across the FDA's 2023 final guidance, the 2024 draft Select Updates, the June 2025 final guidance, and the current February 2026 final guidance.

If you're reading older articles, including earlier versions of this one, it's easy to get lost in which document is current. Here is the actual chain, so you can match any submission to the right version.

The current controlling document is the February 2026 final guidance, which supersedes both earlier finals. It sits alongside the broader body of FDA medical device regulations that govern connected products.

Did the FDA remove or reduce its SBOM requirements?

No. The FDA did not remove SBOM requirements. The February 2026 update mainly swapped quality-system terminology for QMSR references. The SBOM mandate under Section 524B stands.

This deserves a plain answer because the confusion is real and it costs teams time. The February 3, 2026 revision landed one day after the Quality Management System Regulation (QMSR) took effect, and its primary job was to replace references to the old Quality System Regulation (21 CFR Part 820) with QMSR and ISO 13485:2016. The core technical expectations, secure product development, threat modeling, the SBOM, penetration testing, and security architecture, carry over unchanged. What did change is structural: the FDA now expects your cybersecurity documentation, SBOM included, to be generated through controlled quality-system processes rather than assembled as a one-off submission deliverable. If anything, that raises the bar on treating the SBOM as a living part of medical device security, not something you produce once and forget. For where this is heading, see our take on what's next for medical device cybersecurity.

Why does the FDA require an SBOM for medical devices?

The FDA requires SBOMs because you can't manage cybersecurity risk you can't see. An SBOM reveals every software component that could expose a device or its patients.

The FDA's own framing in the guidance is that an SBOM helps manage cybersecurity risk across the software stack, letting manufacturers and the agency identify which devices are affected when a new vulnerability appears, both during development and after the device is on the market. When the next Log4j-scale flaw drops, the manufacturer with an accurate SBOM answers "are our devices exposed?" in hours. The one without it starts a manual hunt across products while patients keep using the devices. That gap, between knowing and guessing, is the whole reason the requirement exists. It also matters for protecting devices from real-world cyber exploitation, where the risky component is often something no one on the team consciously chose.

What are the mandatory data fields for an SBOM in an FDA premarket submission?

An FDA-ready SBOM must include each component's supplier, name, version, unique identifiers, and dependency relationships, plus the SBOM author and timestamp. The FDA also expects component support status.

The FDA builds on the NTIA minimum elements for an SBOM as the baseline data set, then adds lifecycle expectations on top. Here is what each submission should carry.

The support-status fields are where medical device SBOMs go beyond a generic inventory. The FDA wants to know if a device depends on a component that's no longer patched, because that's a long-term risk to safety and effectiveness.

Which submissions and devices need an FDA SBOM?

Any cyber device, broadly a device that includes software and could be vulnerable to threats, needs an SBOM in its 510(k), De Novo, PMA, or HDE submission.

Section 524B defines a cyber device by three traits: it includes software, it can connect to the internet, and it has technological characteristics that could be exploited. The FDA's guidance interprets this broadly. If a device contains software or is software, treat the requirement as applying, whether or not it's network-connected. The SBOM also applies when you make software or connectivity changes to an already-marketed device that trigger a new submission. So the practical scope reaches embedded and firmware-based products, network-connected equipment, and anything built on third-party or open-source code.

How do SBOMs support cybersecurity transparency and labeling?

SBOMs feed device cybersecurity labeling, giving hospitals and users the component visibility they need to assess vulnerabilities and keep the device safe and effective in use.

The guidance treats transparency as part of safe use, not a courtesy. It points to including cybersecurity information in device labeling so that the people operating a device can manage its assets, judge the impact of a new vulnerability, and maintain safety and effectiveness over time. The SBOM is the mechanism that makes that possible. Without it, a hospital learning about a fresh CVE has no way to know whether the device at the bedside is affected.

How should manufacturers keep SBOMs FDA-ready?

Treat the SBOM as a living document: generate it from the shipped build, link it to vulnerability management, and update it with every software change.

The failure mode the FDA is guarding against is the stale SBOM, accurate the day it was filed and wrong within a quarter. A few practices keep you defensible: generate the SBOM from the real build artifact rather than a design assumption, automate generation so it regenerates on every release, tie it to continuous vulnerability monitoring, and assign clear ownership so it stays current. Do that, and the SBOM stops being a submission chore and becomes the backbone of your alignment with FDA requirements for medical device SBOMs.

Meet FDA SBOM requirements with Finite State

Most tools can generate an SBOM. Fewer can prove it reflects what actually shipped in a firmware-heavy medical device, and fewer still keep it defensible over a product's life. That gap is where FDA reviews stall.

The Finite State platform is built for exactly this case. Our binary Software Composition Analysis decomposes the shipped product into its real components, so your SBOM is grounded in what runs on the device, not just what the source manifest claims. We generate, collect, visualize, and distribute SBOMs, and we ingest scans from more than 150 scanners and feeds [verify before publishing] into one unified, prioritized risk view. That means context-aware remediation guidance, a scoring methodology that removes guesswork from what to fix first, and full VEX import and export so your vulnerability communication stays audit-ready and evidence-backed.

FDA cybersecurity 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 request a walkthrough against your own device.