SBOM and FDA cybersecurity: what Section 524B requires

A software bill of materials (SBOM) is a complete, machine-readable inventory of the software components in a product — every commercial, open-source, and off-the-shelf piece, with its version and supplier. For medical devices, it’s no longer optional documentation: under FDA Section 524B, an SBOM is a required part of premarket submissions for cyber devices.

This guide explains what 524B requires, what a usable SBOM contains, and why the SBOM’s real value only appears when you connect it to the rest of your engineering record.

Section 524B, in plain terms

Section 524B (“Ensuring Cybersecurity of Devices”) was added to the FD&C Act by the Consolidated Appropriations Act of 2023 and took effect March 29, 2023. It applies to cyber devices — broadly, devices that contain software, can connect to the internet, and have characteristics that could be vulnerable to cyber threats.

For any premarket submission (510(k), PMA, De Novo, PDP, or HDE) covering a cyber device, 524B(b) requires the sponsor to:

• Submit a postmarket plan to monitor, identify, and address vulnerabilities, including coordinated vulnerability disclosure.
• Design and maintain processes that provide reasonable assurance the device is cybersecure, and make updates and patches available.
• Provide a software bill of materials covering commercial, open-source, and off-the-shelf components — section 524B(b)(3).

The FDA can issue a Refuse to Accept (RTA) decision on submissions that lack adequate cybersecurity documentation, so the SBOM isn’t a formality — a missing or inadequate one can stall a submission before substantive review begins. The agency’s June 2025 premarket cybersecurity guidance (terminology updated in February 2026 to align with the QMSR) details what it expects.

What a usable SBOM contains

The FDA expects a machine-readable SBOM in an industry-accepted format (such as SPDX or CycloneDX). For each component, a strong SBOM records at least the component name, version, and supplier, and ideally its dependencies, license, and end-of-support date. Completeness matters: an SBOM that omits transitive dependencies or off-the-shelf components leaves exactly the blind spots attackers exploit.

But an inventory alone is a starting point, not an answer. The reason to maintain an SBOM is to answer a question quickly when a new vulnerability lands: does this CVE affect us, and where?

From list to impact: the connected SBOM

This is where most SBOM efforts stop short. A standalone SBOM tells you that a vulnerable component is present. It doesn’t tell you which device functions use it, which requirements depend on it, or which hazards and tests it touches — and those are the questions risk management and a regulator actually care about.

An SBOM becomes a tool rather than a document when it’s connected to the rest of the record: when a component links to the software requirements that use it, the risk controls that depend on it, and the tests that verify them. Then a newly disclosed CVE isn’t a research project — you trace from the affected component straight to the impacted requirements, hazards, and verification, and scope the response in minutes instead of days. FDA guidance reinforces this direction, treating the SBOM as a living document tied to the device’s risk management and lifecycle, not a one-time attachment.

As with the rest of the cybersecurity framework, no tool delivers 524B compliance on its own — the manufacturer owns the secure-development process, the risk management, and the submission. What tooling can do is produce traceable, review-ready artifacts and keep them current.

Where TraceUnified fits

Connecting the SBOM to the thread is the model TraceUnified is built on. The SBOM lives as records on the same traceability graph as requirements, risk, and tests, so a CVE on a component surfaces exactly which requirements, hazards, and verification it touches — vulnerability impact you can read off the graph rather than reconstruct. Paired with a tamper-evident audit trail and Part 11 signatures, the SBOM and its vulnerability assessments become part of one connected, audit-ready record. The cybersecurity program is still yours to run; the system is engineered to make its evidence traceable.