Somewhere in most risk management files for a connected device, there is a row that reads roughly like this: hazard, cybersecurity; probability of occurrence, low; severity, high; risk, acceptable with controls.
It looks like diligence. Every other row on that sheet was produced the same way, and the other rows are fine. This one is not, and the reason is narrower and more interesting than “you need a threat model.”
The method, stated fairly
Risk under ISO 14971 is the combination of the probability of occurrence of harm and the severity of that harm. In practice almost every risk management training decomposes the first term further, into two conditional steps:
- P1 — the probability that a hazardous situation occurs at all.
- P2 — the probability that, given the hazardous situation, harm actually results.
The decomposition is a teaching device rather than an obligation, and good practitioners say so. But it is genuinely useful, because it forces you to describe a sequence rather than assign a vibe: what leads to the hazardous situation, and what turns that situation into injury.
To populate it, the standard analysis techniques send you to a familiar set of sources: known failure modes, published literature, adverse event databases, clinical hazard lists, and experience with similar devices. Whether you work forward from hazards or backward from harms, those are the inputs.
Now run it on a security hazard
Take a connected infusion pump, and the hazardous situation unauthorised change to the infusion rate. Work the list honestly.
- Known failure modes. An adversary is not a failure mode. Nothing in the component reliability data speaks to a decision made by a person.
- Published literature. Gives you vulnerability classes. It does not give you the rate at which anyone chooses to use one against this device.
- Adverse event databases. Record harm that occurred. They are a record of outcomes, not of intent, and they are systematically silent about attempts that failed or were never reported as attacks.
- Similar devices. The nearest thing to a base rate, and still the wrong shape: a capacitor does not choose its victim, and attackers select targets for reasons that have nothing to do with your bill of materials.
None of them yields P1. Not “yields a poor estimate of P1” — yields nothing. There is no population and no frequency to draw from, because the event is chosen rather than distributed.
The part worth being precise about
It would be easy, and wrong, to conclude that ISO 14971 does not apply to security. It applies exactly as well as it ever did to the second half of the chain.
Once an attacker has achieved the hazardous situation — the infusion rate is now wrong — estimating what happens next is ordinary clinical work. Which patients, what dose error, over what period, with what monitoring, leading to what injury and how severe. P2 is entirely intact. So is severity. Nothing about the presence of an adversary makes a pharmacological consequence harder to reason about.
So the framework does not collapse. One factor of one term does. And because the term is a product, an unestimable factor is not a weak link in a chain of strong ones — it determines the result regardless of how carefully the other factor was derived.
If P1 cannot be estimated, the number in that row was not derived. It was chosen.
That is the actual problem with probability: low. It is not that the estimate is optimistic. It is that it is not an estimate.
FDA says this out loud
This is not a clever reading. The current premarket cybersecurity guidance, issued 3 February 2026, states it directly. On the distinction itself:
Performing security risk management is distinct from performing safety risk management as described in ISO 14971.
And then, three pages later, the mechanism — which is the passage worth having open when you next review a risk file:
… cybersecurity risks are difficult to predict, meaning that it is not possible to assess and quantify the likelihood of an incident occurring based on historical data or modeling (also known as a “probabilistic manner”). This non-probabilistic approach is not the fundamental approach performed in safety risk management under ISO 14971 and further underscores why safety and security risk management are distinct but connected processes. Instead, security risk assessment processes focus on exploitability, or the ability to exploit vulnerabilities present within a device and/or system.
“Not possible” is doing the work there. Not difficult, not imprecise, not requires expert judgement. The agency is describing a different kind of quantity, and naming the one it wants instead.
A check you can run in a minute
Download the guidance and search the text for the word probability.
| Term | Count |
|---|---|
probability | 0 |
likelihood | 1 |
probabilistic | 2 |
exploitability | 12 |
threat model | 28 |
Zero. In a document about assessing risk in medical devices, across sixty-four pages, the central noun of conventional risk estimation does not appear once. The single occurrence of likelihood is inside the sentence quoted above — the one saying the likelihood cannot be quantified. Both occurrences of probabilistic are in that same passage, and one of them is preceded by non-.
Counts are on the PDF's text layer with whitespace removed, so hyphenated line breaks cannot hide a match. It is a thirty-second check and you should not take my word for it.
What FDA offers in its place
Having removed the number, the guidance does not leave you without a method. For premarket work it gives two acceptable routes:
… a premarket exploitability assessment could either assume a worst-case assessment and implement appropriate controls, or provide a justification for a reasonable exploitability assessment of the risk throughout the TPLC and how the risk is controlled.
Read that as a fork, because it is one. Assume the worst case and control for it, which is cheap to write and expensive to build. Or justify a lower exploitability, which is cheap to build and expensive to write — because a justification is an argument someone else has to be able to follow and disagree with.
What is not on the menu is the third thing, the popular one: assert a low probability, in a column headed probability, and move on. That is neither worst case nor justification. It looks like the first two because it produces a number in the same shape.
So the row was never the problem
The row is a symptom. Security analysis produces a different object — threats, attack surface, exploitability, controls — and the only thing that should cross into the ISO 14971 file is the part that ends in patient harm, arriving as a hazardous situation with a severity you can defend.
How those two processes are meant to interface, and what QMSR changed about where they live, is its own subject and I have written about it separately. FDA points at AAMI TIR57 and ANSI/AAMI SW96 for the mechanics.
The narrow point here is upstream of all of that, and it survives whatever structure you choose. A reviewer who opens your hazard analysis, finds one row headed cybersecurity with a probability beside it, and knows the guidance says probability is not available for that row, has learned something about the file before reading any of your controls.
An attacker is not a failure mode. Everything downstream of the compromise — the harm, its severity, the clinical reasoning — is ordinary risk management and your existing file does it well. Everything upstream of it is a different question, and the honest answer to that question is not a small number.