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 classify every threat with STRIDE against a data flow diagram of the device, then score it on two matrices. Exploitability, read from the CVSS v4.0 calculator instead of a guessed probability, is shared by both. The security matrix pairs it with security impact for every finding. The safety matrix pairs it with severity from your ISO 14971 hazard analysis for findings that can reach a patient, and decides controlled or uncontrolled against acceptance criteria you set before scoring. We score and recommend; you decide.
Calculate your security and patient-safety risk on the Rev H / Rev P charts.
Download the client risk-scoring deck (PDF, 81 KB). Fictional examples; manufacturer-owned decisions and methodology limits are included.
Your acceptance criteria are fixed in the security risk management plan first. They belong to you, the manufacturer; we document them with you: 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.
Starting from intended use, use environment, and the harms the device can cause, we draw a data flow diagram in DFD3 notation: external entities, processes, data stores, data flows, and trust boundaries. Every interface an attacker can reach, including service and debug ports, is numbered as an entry point.
Each element is walked through the STRIDE categories that apply to it (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), following Table 3 of the MITRE / MDIC Threat Modeling Playbook. STRIDE classifies threats; it does not score them. Each threat becomes one row with an ID, its entry point, and the harm it could lead to.
There is no failure rate for a person who chooses to attack, so we rate exploitability, as ANSI/AAMI SW96 allows. We record the full CVSS v4.0 vector, and three of its exploitability metrics, attack vector (AV), privileges required (PR), and user interaction (UI), set High, Medium, or Low and the position on the chart, so any reviewer can reproduce it from the vector.
CVSS v4.0 rates confidentiality, integrity, and availability for the vulnerable system and for anything the exploit reaches beyond it. We take the highest of those six ratings: High gives High impact, Low gives Medium, and all None gives Low.
Exploitability and security impact combine in a matrix, not a formula, into Low, Medium, High, or Critical. This sets remediation priority for every finding, whether or not a patient is involved: Low is recorded, Medium is tracked or accepted with a reason, High is fixed before release or on a defined postmarket timeline, and Critical is fixed immediately. That is our own practice, not an FDA timeline.
A finding passes the patient-safety gate if exploitation could change delivered therapy or energy, alter or hide clinical data, stop a clinical function a patient depends on, or suppress or falsify an alarm. Data disclosure alone, such as PHI, does not pass. When unclear, we treat it as patient-affecting.
Exploitability combines with severity of harm from your own ISO 14971 hazard analysis (negligible to catastrophic) into Low, Medium, High, or Very High. We don't estimate severity ourselves. By default, Low and Medium are controlled and High and Very High are uncontrolled, but the acceptance line is yours, fixed in your security risk management plan before scoring.
Every threat gets a named control strategy: eliminate, mitigate, accept, or, as a last resort, transfer to the user through labeling. Each control gets a test case that penetration testing confirms. Each finding is scored before any control and again after each one; the controlled or uncontrolled call applies to the residual. We recommend; you decide, and residual patient risk feeds your ISO 14971 benefit-risk picture.
New vulnerabilities, a CISA KEV listing, design changes, field findings, severity changes, or a failed control trigger a re-score against the same threat ID. A KEV listing doesn't change the exploitability rating on its own; we confirm the device is affected, mark the exploit as known, and re-score if it defeats a control. We recommend remediation over acceptance.
An infusion pump's wireless control channel has no mutual authentication, so an attacker on the hospital network could impersonate the control station and send a dose. STRIDE classifies it as spoofing and tampering. Before any control, high exploitability and a potentially fatal harm score Very High on the safety matrix: uncontrolled. Mutual authentication over TLS lowers exploitability to Medium, which still scores High. A second control requires a clinician to confirm a short-range pairing step at the pump; the calculator now rates exploitability Low, and the finding scores Medium: controlled, with the justification on file. (Illustrative example.)
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 supported 275+ FDA submissions, with zero cybersecurity rejections.
