IEC 62304 SOUP component tracking and IEC 81001-5-1 configuration management — SBOM formalizes and machine-readifies existing component inventory practices.
§524B(b)(3) of the FD&C Act requires providing an SBOM that includes commercial, open-source, and off-the-shelf software components; the statute names no format. FDA guidance V.A.4 recommends machine-readable SBOMs consistent with the NTIA minimum elements plus each component's level of support and end-of-support date, and encourages industry-accepted formats. Generating the SBOM from the build rather than curating it by hand is good practice.
Machine-readable SBOM format (for example SPDX or CycloneDX), completeness of upstream and transitive dependencies, and build-pipeline generation evidence — spreadsheet substitutes and stale snapshots are gaps.
Maps to
FDA Cybersecurity Guidance: §V.A.4 Third-Party Software Components, §VII.C.3 Software Bill of Materials (SBOM) (Section 524B(b)(3)), §Appendix 4 General Premarket Submission Documentation Elements and Scaling with Risk
Pre-QMSR Part 820: §820.184 Device history record.
IEC 62304: §8.1.2 Identify soup
IEC 81001-5-1: §8 Software CONFIGURATION MANAGEMENT PROCESS
Requirement text
Per §524B(b)(3) of the FD&C Act, manufacturers of cyber devices shall submit a Software Bill of Materials (SBOM) as part of premarket submissions. FDA's Premarket Cybersecurity Guidance recommends that manufacturers provide machine-readable SBOMs consistent with the minimum elements (also referred to as "baseline attributes") identified in the October 2021 NTIA Multistakeholder Process on Software Component Transparency document, and encourages industry-accepted SBOM formats. Section 524B(b)(3) of the FD&C Act requires the software bill of materials provided to the Secretary to include "commercial, open-source, and off-the-shelf software components". An SBOM or an equivalent capability should be regularly updated to reflect any changes to the software in marketed devices.
Why this clause exists
Guidance V.A.4(a) says "An SBOM helps facilitate risk management processes by providing a mechanism to identify devices and the systems in which they operate that might be affected by vulnerabilities in the software components". A manufacturer who cannot enumerate the software components in a device cannot assess whether those components are vulnerable, and a vulnerability in an undocumented transitive dependency can go undetected. Section 524B(b)(3) of the FD&C Act requires the sponsor of a cyber device submission to "provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components". The guidance recommends machine-readable SBOMs (V.A.4(b)) and encourages industry-accepted formats without naming one. Machine-readable format matters here because automated vulnerability scanning cannot operate against a human-readable spreadsheet. SBOM value is realized only when it feeds continuously into monitoring tooling, not when it exists as a static document.
What changed
The FDA's September 2023 final guidance replaced the October 2014 final guidance 'Content of Premarket Submissions for Management of Cybersecurity in Medical Devices'. The guidance is headed 'Contains Nonbinding Recommendations' and states that, in general, FDA guidance documents 'do not establish legally enforceable responsibilities' and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited; it recommends how to meet the requirements of Section 524B of the FD&C Act (added by FDORA, enacted December 29, 2022), which became effective March 29, 2023. FDA's cybersecurity Refuse to Accept (RTA) policy for cyber devices, issued March 29, 2023, expired on October 1, 2023; from that date FDA expects sponsors of cyber devices to have had sufficient time to prepare premarket submissions that contain the information Section 524B requires (FDA CDRH webinar, November 2, 2023).
Section 524B created new statutory requirements for 'cyber devices' — any device that includes software validated, installed, or authorized by the sponsor as a device or in a device, has the ability to connect to the internet, and contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats. Under Section 524B(b), the sponsor must (1) submit a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures; (2) design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches on a reasonably justified regular cycle for known unacceptable vulnerabilities and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks; (3) 'provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components'; and (4) comply with such other requirements as the Secretary may require through regulation to demonstrate reasonable assurance that the device and related systems are cybersecure.
The statute says nothing about SBOM format, depth or end-of-support dates. Those come from the guidance (Section V.A.4), which recommends that manufacturers provide machine-readable SBOMs consistent with the NTIA minimum elements and, for each software component, the 'software level of support' and the end-of-support date, and says 'Industry-accepted formats of SBOMs are encouraged.' The guidance names no format; SPDX and CycloneDX are formats used in practice, not named by the statute or by the guidance. The guidance describes a robust SBOM as including 'the upstream software dependencies' of proprietary, purchased/licensed, and open-source software (V.A.4(a)), and recommends that an SBOM or an equivalent capability be maintained as part of configuration management and regularly updated to reflect changes to the software in marketed devices. Section V.C lists 'Software composition analysis of binary executable files' among the testing and analyses for which it recommends providing details and evidence.
Common gaps (what we see in audits)
- Static, incomplete SBOMs missing transitive dependencies — SBOMs are generated once and not updated for the submission build. Transitive dependencies are missing. Binary components, firmware libraries, and components outside standard package managers are omitted. Many manufacturers submit manually curated spreadsheets rather than machine-readable SBOM files (for example SPDX or CycloneDX). The guidance recommends that an SBOM or an equivalent capability be maintained as part of configuration management and regularly updated to reflect changes to the software in marketed devices (V.A.4(a)); updating it at each engineering change order is practice.