IEC 62304 SOUP component tracking and IEC 81001-5-1 configuration management — SBOM formalizes and machine-readifies existing component inventory practices.
§524B(b)(3)(A) of FD&C Act mandates machine-readable SPDX or CycloneDX format with transitive dependencies, CPE/PURL identifiers, and end-of-support dates — generated from the build, not manually curated.
SBOM format (SPDX or CycloneDX), completeness of transitive dependencies, and build-pipeline generation evidence — spreadsheet substitutes and stale snapshots draw RTA deficiency letters.
Maps to
FDA Cybersecurity: §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 (legacy QSR): §820.184 Device history record.
IEC 62304: §5.3.3 Specify functional and performance requirements of soup item
IEC 81001-5-1: §8 Software CONFIGURATION MANAGEMENT PROCESS
Requirement text
Per §524B(b)(3)(A) 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 the SBOM be machine-readable in SPDX or CycloneDX format and include all commercial, open-source, and off-the-shelf software components, including version numbers, suppliers, and dependency relationships. The SBOM should be kept current throughout the product lifecycle.
Why this clause exists
The SBOM requirement exists because a manufacturer who cannot enumerate the software components in their device cannot assess whether those components are vulnerable — and a vulnerability that goes undetected because it was in an undocumented transitive dependency is indistinguishable from one that was deliberately concealed. Prior to the SBOM mandate, FDA reviewers encountered submissions where manufacturers could not identify whether their device ran an affected version of a widely publicized library, because their component inventory was either absent or limited to first-level dependencies only. The statutory SBOM obligation in §524B(b)(3)(A) of the FD&C Act was directly informed by the broader federal policy shift toward software transparency — the same class of supply-chain blindness that enabled widespread compromise through undetected third-party software components in non-medical settings demonstrated equivalent risk in device software, where the patient safety consequences of undetected compromise are qualitatively different. The requirement for machine-readable format (SPDX or CycloneDX) reflects the practical necessity that 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 draft and represented a fundamental shift from voluntary best practices to mandatory, enforceable requirements backed by Section 524B of the FD&C Act (added by FDORA, enacted December 29, 2022), which became effective March 29, 2023. FDA's transitional non-enforcement policy ended October 1, 2023; submissions received after that date missing required cybersecurity documentation receive Refuse to Accept (RTA) letters.
Section 524B created new statutory requirements for 'cyber devices' — any device that includes software, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. Manufacturers must submit: a plan for postmarket vulnerability monitoring and patching, evidence of secure development processes (SPDF), and a machine-readable SBOM in SPDX or CycloneDX format including transitive dependencies and end-of-support dates.
FDA can now refuse to accept (RTA) premarket submissions lacking adequate cybersecurity documentation. Since October 2023, there has been a 700% increase in cybersecurity-related deficiency letters, with an average of 15 deficiencies per letter when cybersecurity is cited. Threat modeling deficiencies appear in a majority of these letters. The SBOM requirement goes significantly beyond the 2014 guidance — binary analysis is expected to find hidden components, and SBOMs must be continuously maintained, not static snapshots.
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 SPDX or CycloneDX files. SBOMs must be continuously maintained and updated at each engineering change order.