Medical-device cybersecurity risk management
Sytance · Updated
Medical-device cybersecurity risk management assesses 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 explains that a security measure can itself affect safety. For example, an access restriction may prevent unauthorised changes but also delay a legitimate operation. The manufacturer needs to assess both effects in the intended use environment.
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
Assess whether the security issue changes the device’s intended operation and whether a control introduces a new safety or performance concern.
Threat modelling feeds the assessment
The threat model identifies how an attacker could use a device interface or external dependency to cause an unwanted result. Its attack conditions and possible consequences become inputs to the cybersecurity risk assessment.
- 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.
The premarket assessment uses the threat model to evaluate attacks and select controls. Verification results show whether the controls work against those attacks. FDA allows either an assumption of worst-case exploitability or a justified exploitability assessment that considers 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 (original English)
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
FDA recommends traceability between the threat model, risk assessment, SBOM and test records. A reviewer should be able to start with an affected component and find the resulting risk decision and verification result. For an EU technical file, explain how those records support the applicable MDR or IVDR requirements.
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