Software bill of materials (SBOM) for medical devices: what FDA expects in 2026

A software bill of materials (SBOM) is now a legal requirement for a large class of medical devices, and the U.S. Food and Drug Administration (FDA) has been rejecting submissions that lack one for more than two years.

The requirement traces to Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023 and effective March 29, 2023. Since Oct. 1, 2023, the FDA has had the authority to refuse to accept premarket submissions for cyber devices that lack adequate cybersecurity documentation, the SBOM included. For a team preparing a 510(k) in 2026, the SBOM is no longer a forward-looking best practice. It’s a requirement.

The most useful way to approach the SBOM in 2026 is as a continuous output of your software build, one that stays current as your code and its dependencies change, rather than a file assembled once for the submission. That distinction is the difference between a submission that clears and one that stalls.

FREE RESOURCE: Access the full recording and slides of our recent webinar on cybersecurity for connected devices.

What is an SBOM, and what does FDA require?

An SBOM is a structured inventory of every software component in a device, including proprietary code, commercial software, open-source libraries, and the dependencies those components pull in behind the scenes. Think of it as the ingredient label for your software, one that’s machine-readable and complete enough that someone else can see exactly what is inside.

Section 524B applies to "cyber devices." The statute defines one as a device that includes software, has the ability to connect to the internet, and carries characteristics that could leave it vulnerable to cybersecurity threats. Most software as a medical device (SaMD) and connected devices sit squarely inside that definition. Keep in mind, the FDA’s current guidance treats a device that contains software, or is software, as in scope whether or not it is network-enabled, so a software device generally brings the cybersecurity documentation, SBOM included, into play. The wider expectations are covered in the FDA's rules on medical device cybersecurity.

FDA does not mandate a single file format. Its guidance points manufacturers to a machine-readable SBOM aligned with the federal minimum elements, first defined by the National Telecommunications and Information Administration (NTIA) in July 2021 and now being updated by the Cybersecurity and Infrastructure Security Agency (CISA). In practice, two industry-standard formats meet that bar: SPDX (Software Package Data Exchange, maintained by the Linux Foundation) and CycloneDX (maintained by the OWASP Foundation, the Open Worldwide Application Security Project). Both encode the NTIA minimum elements, which include supplier name, component name and version, unique identifiers, dependency relationships, and the author and timestamp of the SBOM itself.

The governing document is FDA's final guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions", issued in February 2026. It supersedes the June 27, 2025 version, which had replaced the original guidance from Sept. 27, 2023, and the change in its title from "Quality System" to "Quality Management System" follows the FDA's move to the Quality Management System Regulation (QMSR) that took effect Feb. 2, 2026. Under Section 524B an SBOM is legally required for cyber devices, and the guidance reads that scope broadly, carrying its SBOM expectations to software devices even when they are not obviously networked.

The mistake: treating the SBOM as a submission artifact

The most common failure pattern is to assemble the SBOM as a deliverable in the weeks before a submission. A team pulls together a spreadsheet of components, formats it, and files it, then moves on.

Modern device software is mostly not written by the team shipping the device. A single application can pull in hundreds of open-source packages, each with its own transitive dependencies, and those versions move constantly. An SBOM built by hand at submission time is a snapshot of one moment, and it is usually already wrong by the time a reviewer opens it. Worse, manual assembly tends to hide the exact thing an SBOM exists to surface: the obscure third-party library, four levels deep, that carries a known vulnerability.

There is a cost argument here that every team should understand. Reconciling an SBOM under deadline pressure costs more than generating it on every build from the start, and a refuse-to-accept decision for incomplete cybersecurity documentation costs weeks that a funded startup rarely has to spare. Cleanup is always more expensive than setup. Cybersecurity is one of the areas where deferral compounds fastest.

Generating the SBOM in your build pipeline

The SBOM is an output of your build, not a document you write. Continuous integration (CI) systems already resolve and assemble every dependency your software uses each time they run. That is the natural point to emit an SBOM. Open-source generators such as Syft, along with format-native tooling for most package managers, can produce a CycloneDX or SPDX file as a build step. Run the generation on every commit to a release branch. From that point the SBOM for any given build exists the moment the build finishes.

Tie each SBOM to a specific software version and store it as a versioned artifact next to the build it describes. When you release version 2.3 of your device software, the SBOM for 2.3 is generated, stored, and retrievable, and the same holds for every version still in clinical use. That versioning matters because the postmarket obligations under Section 524B run for as long as the device is on the market, well beyond the moment of clearance.

Maintaining the SBOM as dependencies change

Generation is the first half. The obligation that often trips teams up is maintenance.

Dependencies change on their own schedule. A library you shipped clean last quarter can have a critical vulnerability disclosed against it next week, without a single line of your code changing. Because your pipeline produces an SBOM on every build, you hold a current, machine-readable inventory. You can scan it continuously against public vulnerability databases as new advisories land. When a new vulnerability lands against a component you ship, the SBOM tells you which device versions are affected and how deep the dependency sits.

Feed those findings into your postmarket surveillance process rather than parking them in a separate security backlog. The FDA expects a documented plan to monitor, identify, and address postmarket vulnerabilities, and the SBOM is the connective tissue between a newly disclosed vulnerability and a decision about whether it warrants a patch. Pairing SBOM scanning with your existing complaint and postmarket workflows keeps a single record of what is in the field and what you are doing about it.

What FDA reviewers look for in a 524B submission

Reviewers are not grading the SBOM in isolation. They are checking whether it connects to the rest of your cybersecurity documentation. A few things reliably draw scrutiny.

• Completeness and depth come first. The SBOM should include transitive dependencies, reaching well beyond the top-level packages you chose directly, because a flat list of your direct imports reads as incomplete the moment a reviewer expands it.
  

• Format and lifecycle data come next. Beyond the NTIA elements, reviewers look for support status and end-of-support dates for each component, since an unsupported library that no longer receives security patches is a standing risk that needs a written rationale.
  

• Linkage to security risk management is where many submissions fall short. Each component and its known vulnerabilities should trace into your security risk assessment, showing how you evaluated exploitability and potential patient harm. An SBOM that does not connect to a risk file is a list without a conclusion.
  

• A postmarket monitoring plan closes the loop. The submission needs to show how you will keep watching the components in the SBOM after clearance, and how a disclosed vulnerability becomes an assessed and, where warranted, patched fix. When any of these pieces are missing, the submission risks a refuse-to-accept decision before substantive review begins, so it pays to check them against the full premarket submission documentation early.

FREE RESOURCE: Access the full recording and slides of our recent webinar on cybersecurity for connected devices.

Greenlight Guru helps SaMD teams stay compliant and ship faster

For a SaMD team, the SBOM lives closest to the people who already own the build. The friction shows up when the quality system sits apart from the development tools, so the SBOM turns into something a quality lead has to request from engineering instead of something the pipeline emits on its own. Every one of those handoffs is a chance for the record to drift out of date.

Greenlight Guru built to close that gap. It connects the quality system to the tools software teams already use, so design controls, risk records, and software documentation stay linked to work in Jira and GitHub rather than living in a parallel set of files. When your SBOM is a versioned build output and your quality records point straight to it, the 524B story assembles itself from evidence you already produce, not from a document stitched together the month before you file. That alignment also keeps you consistent with IEC 62304 software lifecycle expectations, which reviewers read right next to the cybersecurity file.

The teams that treat the SBOM as a build output, maintained continuously and tied to their risk and postmarket processes, are the ones for whom a 2026 submission is a formality rather than a scramble. Get your free demo of Greenlight Guru and see how you can keep quality and software documentation in the same place your engineers already work.