Maps to
QMSR / ISO 13485: §820.184
IEC 62304: §5.3.3
FDA Cybersecurity Guidance: §V.A.4, VII.C.3, Appendix 4
Requirement text
The manufacturer shall create and maintain a Software Bill of Materials meeting NTIA minimum element requirements. The SBOM must be in a standardized machine-readable format (SPDX or CycloneDX), include all required data fields per NTIA guidelines, and be updated with a defined frequency aligned to the software release cycle and vulnerability monitoring needs.
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 meet NTIA minimum elements: supplier name, component name, version, unique identifier, dependency relationship, author of SBOM data, and timestamp.
- •The SBOM must be in SPDX or CycloneDX standardized format.
- •An SBOM update procedure must be defined with trigger events (new release, component change, critical vulnerability).
- •The SBOM must include both direct and transitive dependencies to a defined depth.
- •An SBOM management procedure must define storage, versioning, access control, and distribution to customers or regulators.
- •The SBOM must be validated against actual deployed software to ensure accuracy.
Common gaps
No SBOM maintenance procedure or update triggers
majorManufacturers create an SBOM for initial submission but have no defined procedure for maintaining it. Update triggers (new release, component change, critical vulnerability) are undefined. SBOMs are not validated against actual deployed software, leading to drift.
Evidence signals
- •
FILE_EXISTS
SBOM.*Procedure|SBOM.*Management|Bill.*Materials.*Doc|SBOM.*Policy|Component.*Management
- •
CONTENT_MATCH
Does this document define an SBOM management procedure meeting NTIA minimum elements, specifying SPDX or CycloneDX format, update triggers and frequency, validation against deployed software, and distribution procedures for customers and regulators?
Audit defense
The SBOM Management Procedure for [your product] (Doc ID: [your document ID]) defines our process for generating, maintaining, validating, and distributing SBOMs meeting NTIA minimum element requirements in CycloneDX format, with defined update triggers and accuracy validation procedures.