Building and Maintaining an SBOM for Medical Devices Under Section 524B of the United States FD&C Act
What the law requires, what FDA looks for in a submission, and how to keep the record accurate once the device is on the market
Andrew Chukwu, CISSP, MBA | Editor-in-Chief
Sep 25, 2026
Very little of the software in a connected medical device is written by the manufacturer that sells it, for example a patient monitor or an imaging workstation is compiled from an operating system, a cryptographic library, communication stacks (e.g DICOM or HL7), a user interface framework, and all dependencies those components bring with them. The team writes the clinical logic but most of what sits underneath came from somewhere else.
That works until a vulnerability is published in one of those components. The question then arrives from your customers like a hospital security team, your field service professionals, or your own postmarket vulnerability management team, and it is always the same. Is our device affected, and which released versions. Without a current list of all ingredience the software is made off, someone goes digging through build files, version by version. With one, you look it up and answer the same day.
An SBOM in short
The FDA in it's February 2026 premarket cybersecurity guidance defines a software bill of materials (SBOM) as a formal inventory of software components and dependencies, information about those components, and their hierarchical relationships, covering commercial, open source, off-the-shelf and custom code.
It earns its place at four moments: component selection during design, submission assembly, security impact analysis when a vulnerability is published, and the day a supplier stops maintaining something you shipped.
It is basically all the ingredience your software depends on to function effectively and meet it's intended use.
Where the requirement comes from
A sponsor or manufacturer must provide to the FDA a software bill of materials, including commercial, open-source, and off-the-shelf software components. This requirement comes from section 524B of the US Federal Food, Drug, and Cosmetic Act.
The obligation applies to cyber devices and section 524B(c) of this law defines one as a device that includes software validated, installed, or authorized by the sponsor, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. All three conditions must hold.
Note that the FDA reads connectivity as covering connections made intentionally or unintentionally through any means, and it's pre-market cybersecurity guidance lists network and cloud connections, Wi-Fi, cellular and Bluetooth, magnetic inductive communication, and hardware connectors including USB and ethernet. That means for example, A device never networked in clinical use but fitted with a service port is still a cyber device. This requirement attaches to submissions through the 510(k), PMA, PDP, De Novo and HDE pathways.
What FDA asks to see in the submission
FDA recommends machine-readable SBOMs consistent with the baseline attributes in NTIA's October 2021 document Framing Software Component Transparency: author name, timestamp, supplier name, component name, version string, component hash, unique identifier, and relationship.
On top of that baseline, the guidance asks for two further important items for every component: the level of support provided through monitoring and maintenance by the component manufacturer, described in terms such as actively maintained, no longer maintained, or abandoned, and the component's end-of-support date. Either may sit in the SBOM or in a separate appendix. Where the information cannot be supplied, FDA expects a clear justification rather than a gap.
Those last two fields are where the work is. The first eight can be generated by software composition analysis wired into the build, and should be, because a hand-maintained component list is wrong within one sprint. Support status and end-of-support date are not properties of the code. They are statements about a supplier's commitments, drawn from contracts and published lifecycle policies, which makes them a purchasing controls problem rather than an engineering one. Marking a component as actively maintained because its repository looks busy is an assertion you may be asked to evidence.
The analysis that travels with the SBOM
The premarket cybersecurity guidance asks manufacturers to identify all known vulnerabilities associated with the device and its components, including entries in CISA's Known Exploited Vulnerabilities Catalog, and to describe how they were found so FDA can judge whether the methods were sufficient. Each needs a safety and security risk assessment covering device and system impacts. Where remediation is deferred, the submission should say which vulnerabilities the future release addresses, when it is expected, and how long the update takes to reach fielded devices.
The patching obligations connect here. Section 524B(b)(2)(A) requires patches for known unacceptable vulnerabilities on a reasonably justified regular cycle, and 524B(b)(2)(B) requires out-of-cycle patches, as soon as possible, for critical vulnerabilities that could cause uncontrolled risks. The controlled and uncontrolled risk distinction is drawn in the postmarket cybersecurity guidance, and it sets your response clock.
Keeping it accurate once the device is on the market
FDA states that an SBOM or equivalent capability should be maintained as part of the device's configuration management and updated to reflect software changes in marketed devices, supporting the design and development file and medical device file records in subclauses 7.3.10 and 4.2.3 of ISO 13485. The cybersecurity risk management report should then give traceability between the threat model, the risk assessment, the SBOM and the testing evidence.
An SBOM therefore describes a build, not a product. If updates are not applied automatically across the installed base, software configurations coexist in the field with different risk profiles, and the guidance is explicit that vulnerabilities must be assessed against all fielded versions. That means an SBOM per released version, including versions no longer marketed but still in use.
The labeling recommendations add an outward-facing duty: make SBOM information available to users continuously, in machine-readable form, with links that stay current if a portal is used. A revision-controlled MDS2 can carry part of that.
Then comes the CISA update and how to use both
The baseline FDA cites has moved on elsewhere. CISA republished the NTIA framing document in an updated 2024 edition, then issued 2026 Minimum Elements for a Software Bill of Materials in July 2026, replacing the 2021 baseline for general and federal use. The additions that matter most for device work are author signature information, generation context recording where in the build the SBOM was produced, coverage of transitive dependencies rather than top-level components alone, component hashes, and a distinction between information that is unknown and information deliberately withheld.
FDA's February 2026 guidance still points to the October 2021 NTIA document, and that is what a reviewer applies today. The two do not conflict. Generate to the newer baseline, since tooling and hospital customers are heading there, and present against the one FDA cites.
Where to start
If there is no SBOM programme today, this order works. Put software composition analysis in the release pipeline, so the inventory is a build output rather than a document. Fix the format on SPDX or CycloneDX. Add support status and end-of-support date to supplier questionnaires and purchasing records, and backfill them for components already shipped. Attach a disposition to every known vulnerability, not a severity score alone. Then decide where customers collect the SBOM and give that channel a named owner, because a portal nobody owns fails quietly.
The requirement is one sentence in the statute. Meeting it is an operating habit.
References & further reading
FDA, Postmarket Management of Cybersecurity in Medical Devices, final guidance.
CISA, Framing Software Component Transparency (2024).
CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM), July 2026.
CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM), July 2026.
How did this land?
Be the first to react.