Cybersecurity Risk Management
Medical-device cybersecurity risk management decides how threats and vulnerabilities can affect safety, effectiveness and performance. A threat model, SBOM, vulnerability scan or penetration test can support the assessment, but none of them is the risk assessment by itself.
Risk management role
FDA treats security risk management as part of the quality system and device lifecycle. It is distinct from ISO 14971 safety risk management because security failures can be intentional, exploitability changes over time, and harm can be indirect through loss of availability, integrity, confidentiality or control. The two processes still have to interface because a security issue can create patient harm.
MDCG 2019-16 takes the same practical position for EU files: cybersecurity belongs in the risk-management system when security issues can affect safety or effectiveness, and security controls can themselves create safety effects if they are too weak or too restrictive.
Patient harm
FDA postmarket guidance defines the central patient-harm question around injury or damage to patient health, including death, rather than business impact alone.
Safety and performance
EU MDR and MDCG evidence should explain how security affects the device's intended operation, safety, performance, availability and user information.
Threat modelling feeds the assessment
A threat model is the structured analysis that identifies assets, actors, data flows, trust boundaries, interfaces, threats, assumptions, mitigations and attack paths. FDA expects threat modelling to inform and support the risk-analysis activities, not to sit as a separate drawing exercise.
- The threat model identifies what can go wrong and where an attacker or accidental trigger can reach the system.
- The cybersecurity risk assessment evaluates the risks, controls, residual risks and acceptance criteria.
- The safety risk process receives security risks when exploitation can affect patient harm, clinical performance or safe operation.
- The postmarket process updates the model when new vulnerabilities, changed deployments, new interfaces or new attack techniques change the risk picture.
Exploitability changes the analysis
Cybersecurity risk assessment cannot rely only on historical probability. FDA explains that security-risk assessment focuses on exploitability: the feasibility, ease and technical means by which a vulnerability can be exploited. That is why a vulnerability found in testing, a CISA Known Exploited Vulnerability, a changed network path or a new public exploit can change the assessment even if no patient incident has occurred.
Premarket assessment should connect the threat model to the cybersecurity risk assessment, security architecture, control selection, acceptance criteria and testing evidence. FDA allows the sponsor either to assume worst-case exploitability or justify a reasonable exploitability assessment across the total product lifecycle.
Postmarket assessment starts from a real signal, such as a CVE, researcher report, supplier notice or observed exploit. FDA postmarket guidance frames the decision around exploitability, severity of patient harm, compensating controls and whether residual patient-harm risk is controlled or uncontrolled.
SBOM is not the risk assessment
An SBOM identifies software components and dependency relationships. It helps the manufacturer find exposure to known component vulnerabilities, support status and affected versions. It does not show whether a vulnerable component is reachable, whether a control prevents exploitation, whether clinical performance changes, or whether residual patient-harm risk is acceptable.
An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships.
NTIA, Framing Software Component Transparency, 2021
SBOM contribution
Component identity, version, supplier, dependency and support data help identify exposure and support vulnerability management.
Risk contribution
Architecture, threat modelling, exploitability, control evidence and patient-harm analysis decide what the exposure means for the device.
Connected records
The risk file is strongest when the records point to each other. FDA recommends traceability between the threat model, cybersecurity risk assessment, SBOM and testing documentation. EU files should translate that same chain into MDR or IVDR technical-documentation, risk-management, verification, validation, IFU, PMS and vigilance records.
- A threat model without residual-risk decisions is incomplete risk evidence.
- A risk assessment without architecture context cannot show reachability or control placement.
- A clean vulnerability scan does not remove the need to assess foreseeable misuse, support status, update paths and fielded configurations.
- A high-severity CVE in an SBOM is a signal for assessment, not automatically uncontrolled patient-harm risk.
Primary sources
Sources
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final guidance, February 2026
- FDA, Postmarket Management of Cybersecurity in Medical Devices, final guidance, December 2016
- European Commission, MDCG 2019-16 Guidance on Cybersecurity for medical devices
- NTIA, Framing Software Component Transparency: Establishing a Common Software Bill of Materials