IEC 62304 problem and modification analysis and ISO 14971 risk control framework — SBOM-driven CVE assessment extends safety risk management to the software supply chain.
FDA guidance V.A.4 recommends that manufacturers "identify all known vulnerabilities associated with the device and the software components" and provide "A safety and security risk assessment of each known vulnerability (including device and system impacts)" and "Details of applicable safety and security risk controls to address the vulnerability"; §524B(b)(1) of the FD&C Act requires the sponsor to submit "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits".
CVE list current to submission date, per-component applicability rationale, and compensating control documentation for unpatched vulnerabilities.
Maps to
FDA Cybersecurity Guidance: §V.A.6 TPLC Security Risk Management, §VI.B Cybersecurity Management Plans, §VII.C.2 Design, Develop, and Maintain Processes and Procedures to Provide a Reasonable Assurance of Cybersecurity (Section 524B(b)(2))
Pre-QMSR Part 820: §820.90 Nonconforming product.
IEC 62304: §6.2 Problem and modification analysis
IEC 81001-5-1: §6 SOFTWARE MAINTENANCE PROCESS
Requirement text
FDA's Premarket Cybersecurity Guidance §V.A.4 recommends that, as part of the premarket submission, the manufacturer identify all known vulnerabilities associated with the device and the software components, including those identified in CISA's Known Exploited Vulnerabilities Catalog; §V.A.6 recommends that manufacturers ensure they have appropriate resources to identify, assess, and mitigate cybersecurity vulnerabilities as they are identified throughout the supported device lifecycle. For cyber devices, §524B(b)(2) of the FD&C Act requires processes that provide reasonable assurance the device is cybersecure. For components with known vulnerabilities, FDA recommends that device manufacturers provide in premarket submissions a safety and security risk assessment of each known vulnerability (including device and system impacts) and details of applicable safety and security risk controls to address the vulnerability; if risk controls include compensating controls, those should be described in an appropriate level of detail.
Why this clause exists
A known vulnerability that is not assessed for applicability is an undecided risk — the manufacturer has neither accepted nor mitigated it, and therefore has no documented basis for asserting that the device is cybersecure. Section 524B(b)(2) of the FD&C Act requires the sponsor to "design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure". A point-in-time scan is not a process that is maintained. A generic CVE affecting a library does not necessarily affect every product that includes that library; whether the vulnerable code path is reachable in the specific product configuration is a substantive engineering question whose answer changes the actual risk. FDA guidance V.A.4 recommends providing "A safety and security risk assessment of each known vulnerability (including device and system impacts)".
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)
- Vulnerability assessment not current at time of submission — The vulnerability assessment is performed early in development and not refreshed before premarket submission. New CVEs between assessment and submission are unaddressed. Assessments scan components but do not include applicability analysis explaining whether each CVE is exploitable in the product's specific configuration.