FDA 524B: what an SBOM in a premarket submission has to hold

Last updated: 2026-09-29

Section 524B of the FD&C Act (21 U.S.C. 360n-2) requires the sponsor of a premarket submission for a cyber device to provide a software bill of materials that includes commercial, open-source and off-the-shelf software components. The statute names no format and no fields. FDA's guidance of February 2026 recommends a machine-readable SBOM with the NTIA baseline attributes, plus the level of support and the end-of-support date of each component.

What the text says

The statute, 21 U.S.C. 360n-2(b)(3). The sponsor shall:

"provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components; and"

The devices covered, 21 U.S.C. 360n-2(c). A cyber device is a device that:

"(1) includes software validated, installed, or authorized by the sponsor as a device or in a device;"

"(2) has the ability to connect to the internet; and"

"(3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats."

FDA guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions" (3 February 2026; it supersedes the guidance of 27 June 2025), Section V.A.4(b):

"manufacturers should provide machine-readable SBOMs consistent with the minimum elements (also referred to as “baseline attributes”) identified in the October 2021 National Telecommunications and Information Administration (NTIA) Multistakeholder Process on Software Component Transparency document “Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM).”"

The same section, for each software component:

"The software level of support provided through monitoring and maintenance from the software component manufacturer (e.g., the software is actively maintained, no longer maintained, abandoned); and"

"The software component’s end-of-support date."

NTIA, "The Minimum Elements For a Software Bill of Materials (SBOM)" (12 July 2021), data fields:

"Supplier, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp."

What this means in practice

The obligation to provide an SBOM is in the statute; the detail is in guidance. The guidance says of guidances that they "should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited".
The guidance names NTIA's Framing document of October 2021. Its baseline attributes are Author Name, Timestamp, Supplier Name, Component Name, Version String, Component Hash, Unique Identifier and Relationship. NTIA's report of July 2021 lists seven data fields, without the component hash.
The level of support and the end-of-support date are recommended for each component. The guidance lets manufacturers give them in the SBOM or separately, "such as in an addendum".
No format is prescribed: "Industry-accepted formats of SBOMs are encouraged."
The guidance also recommends identifying all known vulnerabilities, including those in CISA's Known Exploited Vulnerabilities Catalog, with a risk assessment and the risk controls for each. An SBOM file does not hold these.
According to the guidance, section 524B has been effective since 29 March 2023 and covers 510(k), PMA, PDP, De Novo and HDE submissions.
The Cyber Resilience Act does not apply to products to which the EU medical device regulations apply (Regulation (EU) 2024/2847, Article 2(2), points (a) and (b)).
The U.S. Code, 2024 edition, gives section 360n-2 as enacted by Pub. L. 117–328 and notes no amendment of it.

What to keep as evidence

The SBOM of the device version in the submission, machine-readable, as generated, with its author and timestamp.
For each component: supplier, name, version, other identifiers and relationships, the level of support and the end-of-support date.
The known vulnerabilities on the date of the submission, including entries in CISA's catalogue, with your assessment of each.

Where DevKit Dossier fits

DevKit Dossier has an FDA 524B export, part of the Business plan: one ZIP per version with sbom.json (the SBOM byte for byte as uploaded), vulnerabilities.json (every component with its findings) and a README.txt that counts which NTIA minimum elements your SBOM gives (SPDX 3.0 files are not counted yet). DevKit Dossier does not add the level of support or the end-of-support date; unless your SBOM already carries them, you add them in your submission, for example in an addendum, as the guidance allows, with the risk assessment of each vulnerability. The SBOM comes from the archive per release, which your CI fills with CycloneDX or SPDX JSON from Syft or Trivy; DevKit Dossier is not a scanner. It supports your evidence: it says nothing about what FDA makes of a submission, gives no legal advice and does not certify anything. It is hosted in the EU and self-serve, at a flat price per organisation of 49, 99 or 249 EUR per month with a 14-day trial.

Join the waitlist

Sources

This guide is general information, not legal advice.