How we go from a device design to a risk file the FDA can follow: threats, patient harm, exploitability, controls and what's left.
We find threats interface by interface, link any threat that could hurt a patient to your ISO 14971 file, rate how bad the harm would be on your safety scale and how easy the attack is instead of guessing a probability, then check both against acceptance criteria written before scoring. Every control is tested, and any patient-harm risk left over goes back into your safety file.
We write down the acceptance criteria first: which combinations of patient harm and exploitability are acceptable, which need more controls, and which are never acceptable. Scores are then judged against rules that already exist, so nobody tunes the criteria to fit the results.
We map the hardware, firmware, apps, cloud services and update path of the design you plan to submit, plus every interface: radios, ports, APIs and service connections. We mark trust boundaries, the places where data moves between parts that trust each other differently.
For each interface and trust boundary we ask what an attacker could do: pretend to be something else, change data, read data they shouldn't, block the device, or gain more control. Each threat gets an ID, the entry point it uses and the asset it affects.
If a threat could lead to patient harm, such as a wrong dose, a missed alarm or a false result, it links to a hazard and harm in your ISO 14971 safety file. Both sides use one shared list of harms, so the security and safety files always agree.
How bad the harm would be comes from your existing safety severity scale. We don't invent a separate security severity scale for patient harm.
You can't put a real probability on a deliberate attack, so we rate how easy the attack is: can it be done remotely, how complex is it, does it need credentials or a user's help, and is a working exploit already circulating. If a working exploit is known (for example a CISA KEV listing), it rates as highly exploitable.
Severity and exploitability are kept separate until the end, then combined and checked against the acceptance criteria from step one. Risks outside the criteria need more controls.
Each control is a named design measure, such as signed firmware or authenticated commands, not a note in the labeling. Every control gets a test case, and penetration testing confirms it holds.
We record the risk before and after controls. Known exploited vulnerabilities are fixed or designed out, never accepted as leftover risk. Any remaining risk that could harm a patient rolls into your ISO 14971 file for the overall benefit-risk decision.
New vulnerabilities, design changes and field data feed back into the same threat model and risk rows, so the file you submitted stays the file you maintain.
An insulin pump accepts dose commands over Bluetooth. Threat: an attacker replays a captured bolus command. It could cause an overdose, so it links to the overdose hazard in the ISO 14971 file. Severity comes from the safety scale: catastrophic. Exploitability: nearby attacker, no credentials needed, moderate complexity. Combined, it falls outside the acceptance criteria. Control: message counters so old commands are rejected, verified by a test case and the pen test. The remaining risk is rated again and recorded in the safety file.
Safety and security are two views of the same device, joined by one list of harms. For the full detail on how the two standards work side by side, read ISO 14971 and AAMI SW96: how they fit together.
Our threat model gap assessment checks your existing threat model and cybersecurity hazards against this method and gives you a ranked list of what to fix. No threat model yet? Our threat modeling service builds one. Want to build your own first? Download the free threat model template (Excel). To see how exploitability is rated, try the CVSS v4.0 calculator.
30-minute strategy session. No cost, no commitment - just answers from people who've shipped 275+ devices supported.
