Maps to
QMSR / ISO 13485: §820.184
IEC 62304: §5.3.3
IEC 81001-5-1: §8
FDA Cybersecurity Guidance: §V.A.4, VII.C.3, Appendix 4
Requirement text
The manufacturer shall generate and maintain a machine-readable Software Bill of Materials (SBOM) in SPDX or CycloneDX format. The SBOM must include all commercial, open-source, and off-the-shelf software components, including version numbers, suppliers, and dependency relationships. The SBOM shall be provided as part of premarket cybersecurity documentation and kept current throughout the product lifecycle.
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 (PATCH Act, effective October 1, 2023).
Section 524B created new statutory requirements for 'cyber devices' — any device that includes software, connects to the internet (directly or indirectly), or 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.
Atomic constraints
- •The SBOM must be in a machine-readable format: SPDX (ISO/IEC 5962:2021) or CycloneDX.
- •All software components must be listed including manufacturer-developed, open-source, commercial off-the-shelf, and third-party libraries.
- •Each component entry must include component name, version, supplier/author, and unique identifier (e.g., CPE, PURL).
- •Dependency relationships (direct and transitive) between components must be documented.
- •The SBOM must be generated from the actual build process, not manually curated.
- •The SBOM must be updated with each software release and maintained throughout the product lifecycle.
Common gaps
Static, incomplete SBOMs missing transitive dependencies
majorSBOMs 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.
Evidence signals
- •
FILE_EXISTS
SBOM|Software.*Bill.*Materials|BOM|SPDX|CycloneDX|Component.*List
- •
CONTENT_MATCH
Does this document contain a software bill of materials listing all software components (open-source, commercial, and custom) with version numbers, suppliers, unique identifiers, and dependency relationships in SPDX or CycloneDX format?
Audit defense
The Software Bill of Materials for [your product] (Doc ID: [your document ID]) is generated automatically from our build pipeline in CycloneDX format per FDA Premarket Cybersecurity Guidance requirements, listing all components with version, supplier, and dependency information. It is regenerated with each release and monitored against vulnerability databases.