Security risk vs safety risk management for medical devices

FDA recommends that manufacturers run a safety risk assessment and a separate security risk assessment. They are distinct but connected. Safety risk uses probability of harm. Security risk focuses on exploitability, because attacks cannot be predicted from historical data the way component failures can.

Why one process is not enough

The guidance says security risk management is distinct from the safety risk management described in ISO 14971. The scope of harm and the assessment factors differ. Safety work focuses on physical injury, damage to property or the environment, and delay or denial of care from unavailability. Security risk management can include risks that cause indirect or direct patient harm, and it can include business or reputational risks that sit outside FDA's safety and effectiveness assessment.

FDA also notes that risk controls chosen for one type of risk must not quietly create new risk in the other. Its example standards for joining the two processes are AAMI TIR57 and ANSI/AAMI SW96.

Exploitability instead of probability

The most useful idea here is the non-probabilistic approach. The guidance says cybersecurity risks are difficult to predict, so it is not possible to assess and quantify the likelihood of an incident from historical data or modeling. That is the normal approach in ISO 14971 safety work.

Security risk assessment therefore focuses on exploitability, meaning the ability to exploit vulnerabilities in the device or system. FDA suggests that a premarket assessment can either assume the worst case and implement controls, or justify a reasonable exploitability rating across the product lifecycle.

Two details are worth copying into your own process:

• If a penetration tester could exploit a vulnerability, a real attacker's ability to do so is likely to grow over the device lifecycle.
• Vulnerabilities in CISA's Known Exploited Vulnerabilities Catalog should be designed out of the device, since they are already being exploited. See what the KEV catalog is.

Known vulnerabilities count as foreseeable

The guidance says a device should be designed to eliminate or mitigate known vulnerabilities. When known vulnerabilities are only partly mitigated or not mitigated, they should be assessed as reasonably foreseeable risks. They may then need extra controls or transfer to the user.

Risk transfer to the user should happen only when the relevant risk information is known, assessed and communicated. FDA specifically asks manufacturers to think about what happens at end of support and end of life, and whether the user, who might be a patient, can take on that role.

What goes in the report

FDA recommends a security risk management plan and report along the lines of AAMI TIR57 and SW96. The report should include the system threat modeling, the cybersecurity risk assessment, the SBOM, component support information, vulnerability assessments and the unresolved anomaly assessments. It should also summarize the evaluation methods, state the residual risk conclusion, list mitigations, and show traceability between the threat model, risk assessment, SBOM and testing.

A simple way to start

1. Keep the existing safety risk file untouched.
2. Create a security risk file with its own scoring method based on exploitability.
3. Add a defined hand off, so a security finding with a clinical hazard becomes an entry in the safety file.
4. Review both when a new vulnerability appears in a component.

Quick check

Sources

• FDA guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 3, 2026)

Last reviewed: 19 October 2026.