ISO 14971 risk management process and IEC 81001-5-1 security risk management — cybersecurity risk assessment integrates with, and feeds into, the existing safety risk file.
FDA guidance V.A.2 recommends assessing exploitability rather than probabilistic likelihood, and providing the risk-scoring method, the acceptance criteria and the method for transferring security risks into the safety risk assessment process with the premarket submission.
Traceability between threat model and risk assessment entries, CVSS-scored CVE list, and signed risk acceptance records.
Maps to
FDA Cybersecurity Guidance: §V.A.2 Cybersecurity Risk Assessment
Pre-QMSR Part 820: §820.30(g) Design validation.
ISO 14971: §5.4 Identification of hazards and hazardous situations, §5.5 Risk estimation
IEC 81001-5-1: §7 SECURITY RISK MANAGEMENT PROCESS
Requirement text
FDA's Premarket Cybersecurity Guidance recommends that the manufacturer perform a cybersecurity risk assessment that evaluates each identified threat from the threat model. Because likelihood of occurrence cannot typically be quantified for cybersecurity risks using historical data or modeling (unlike ISO 14971 safety risk assessment), the assessment should focus on exploitability and impact, identify cybersecurity controls to mitigate risks, and evaluate residual risk. FDA recommends that the cybersecurity risk assessment provided in premarket submissions capture the risks and controls identified from the threat model, and that the methods used for scoring the risk pre- and post-mitigation, the associated acceptance criteria, and the method for transferring security risks into the safety risk assessment process also be provided as part of the premarket submission.
Why this clause exists
Safety risk management and cybersecurity risk management rest on fundamentally different probability models — ISO 14971 uses statistical likelihood of failure to estimate risk, but a determined adversary's probability of exploitation depends on motivation, skill, and opportunity, none of which follow a random-failure distribution. Manufacturers who apply ISO 14971's probabilistic likelihood framework to cybersecurity threats systematically underestimate adversarial risk: a known, unpatched vulnerability with a published exploit has high exploitability regardless of how rarely the device has been attacked historically. FDA guidance V.A.2 states that security risk assessment processes 'focus on exploitability' because cybersecurity risks cannot be assessed in a 'probabilistic manner', and recommends that the methods used for scoring the risk pre- and post-mitigation and the associated acceptance criteria be provided with the premarket submission. The guidance describes safety and security risk management as "distinct but connected processes" (V.A.2), says the security risk management processes "should also ensure that risk control measures for one type of risk assessment do not inadvertently introduce new risks in the other" (V.A), and recommends that the method for transferring security risks into the safety risk assessment process be provided with the premarket submission (V.A.2).
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)
- Risk assessment disconnected from threat model and safety risk management — Cybersecurity risk assessments use inconsistent methodologies, fail to assess every threat identified in the threat model, or lack traceability to the ISO 14971 safety risk management file. FDA guidance V.A.2 says cybersecurity risks cannot be assessed in a 'probabilistic manner' from historical data or modeling, and recommends focusing on exploitability, not random failure probability.