Skip to content
CROSSWALK

FDA Cybersecurity §V.A.4, VII.C.3, Appendix 4

WHAT CARRIES OVER

IEC 62304 §5.3.3 SOUP specification and IEC 81001-5-1 §8 configuration management — SBOM documentation procedures formalize existing component tracking with lifecycle governance.

WHAT’S NEW

NTIA minimum elements (supplier, version, identifier, dependency, author, timestamp) with defined update triggers—release, component change, critical CVE.

AUDIT FOCUS

Defined update trigger events, NTIA field completeness, and validation against deployed software — unmaintained SBOMs are a lifecycle management gap.

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

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.

Why this clause exists

An SBOM that is created for submission and then not maintained is an accurate snapshot of the software composition at a single point in time that becomes progressively less accurate with every subsequent change — and an inaccurate SBOM feeds incorrect component data into vulnerability monitoring tools, producing false-negative alerts that allow newly applicable vulnerabilities to go undetected. The NTIA minimum element requirements exist because SBOM schemas varied widely before standardization, and an SBOM without a component unique identifier (PURL or CPE) cannot be matched programmatically against NVD CVE entries at all, defeating vulnerability monitoring regardless of update frequency. The defined update trigger events — new release, component change, critical vulnerability discovery — reflect the principle that SBOM accuracy is not a function of calendar time but of events that change the software composition or the relevance of its contents; a weekly-regenerated SBOM with no change is no more accurate than the prior version, while a missed component upgrade is an immediate accuracy gap regardless of when the last scheduled regeneration occurred. SBOM distribution and access procedures are required because the SBOM's value extends beyond internal use: customers and connected healthcare networks need visibility into device software composition to apply their own network security controls, and regulators need access during inspections and post-market surveillance.

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)

  • No SBOM maintenance procedure or update triggersManufacturers 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.

Related clauses

Review your documents against this clause →

Further reading

Free compliance review. Pay only for the detailed report.

No credit card. No sales call. No consultants required.

Start My Free Review →

Read-only access. Your documents stay in your Drive.