Threat modelling a medical device: architecture views and the risk matrix

Your notified body or the FDA asks for a “threat model”. The team then produces a STRIDE enumeration and a handful of countermeasures, or conversely a set of very clean architecture diagrams. Either way half the deliverable is missing — and above all the thread that ties one to the other, all the way to the patient. Because the FDA’s September 2023 premarket guidance does not ask you to choose: it expects documented architecture views and a scored risk analysis, linked together and transferred into the patient-safety risk analysis. Here is the method I apply with my clients, and what the text actually requires.

What is a medical device threat model?

Definition: threat modelling is the process that identifies security objectives, risks and vulnerabilities across the medical device system, then defines the countermeasures intended to prevent, mitigate, monitor or respond to the effects of threats throughout its life cycle.

What separates it from a classic IT threat model is not technique, it is the exit criterion. In IT, the question is “is the attack possible, and how do we block it?”. In a medical device, the question is “if it succeeds, what harm does the patient suffer, and is that harm acceptable?”. Everything else in the method follows from that shift.

The requirement is explicit on both sides of the Atlantic: the FDA recommends threat modelling be performed throughout the design process and cover all elements of the system, and threat analysis is one of the activities mandated by IEC 81001-5-1, one of the workstreams when catching up on an existing codebase.

What the FDA actually expects from the threat model

This is the part most often skimmed, even though the guidance is very directive. The threat model must do four things.

Identify risks and mitigations, and inform the pre- and post-mitigation scoring carried into the cybersecurity risk assessment. Double scoring is therefore not a methodological flourish: it is expected by name.

State its assumptions about the system and its environment of use. The guidance supplies the example to follow: hospital networks are inherently hostile, and manufacturers are recommended to assume an adversary controls the network, with the ability to alter, drop and replay packets. A threat model that does not state its assumptions leaves the reviewer to guess them — and they will be guessed against you.

Cover the whole life cycle, not just the product in operation: risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance and update activities, and decommissioning. The guidance notes that these are precisely the risks a traditional safety risk assessment tends to overlook — the March 2026 Stryker attack is the clearest illustration of it.

Justify the chosen method. You are free to pick your methodology, or combine several, but the rationale for that choice must be provided with the documentation. That sentence deserves attention: it turns “we did STRIDE” into a decision you have to argue.

Matrix or diagrams? The FDA asks for both

This is the framing error I see most often, in both directions. Some teams deliver a risk matrix with no diagram, others beautiful diagrams with no scoring and no decision. The guidance expects both, and connects them.

On the diagram side, it recommends providing at minimum four security architecture views in the submission:

• the Global System View, the overall view of the system;
• the Multi-Patient Harm View, covering multi-patient harm scenarios;
• the Updateability/Patchability View, on the update and patching mechanism;
• one or more Security Use Case Views, per sensitive use case.

Each is documented with diagrams and explanatory text — both, not one or the other. The accepted forms are broad: data-flow diagrams, state diagrams, swim-lane diagrams, call-flow diagrams. The bar, however, is high: the views must be detailed enough for an engineer or a reviewer to follow data, code and commands from one asset to another, including across intermediate assets, with protocols and their versions, ports, authentication mechanisms and session management.

The views must also identify system elements and their interfaces, define the security context, domains, boundaries, critical user roles and external interfaces, and establish traceability between architecture elements and security requirements.

The guidance adds a sentence worth its weight in practice: architecture views are an effective way to convey threat modelling information, and if the threat modelling documentation already sufficiently captures a view, the FDA does not expect duplication. Views and matrix are not two competing files: they are two faces of the same work.

In practice I therefore deliver both: the views carry the demonstration — how the system is built and where the flows run — and the matrix carries the decision — which risk was scored, controlled, accepted, and by whom.

The three registries to build before the matrix

The costliest methodological mistake is filling in the matrix directly. You first need three numbered catalogues, maintained separately and reusable from one product to the next:

• Assets — anything of value or worth targeting: data (patient data, images, configuration, generated reports), credentials and secrets, application components, integrated third-party services, hosting infrastructure, and manufacturer-controlled assets such as an update server. The asset inventory overlaps your SBOM without being the same thing: the SBOM enumerates software components, the asset registry enumerates what an attacker wants. The guidance notes that this analysis also helps determine what belongs in the SBOM.
• Threats — phrased generically and reusably: an actor, a capability, an objective. They do not depend on your product.
• Vulnerabilities — the conditions that make a threat feasible: weak authentication, no encryption in transit, secrets stored in clear text, no logging.

Every entry gets a permanent identifier. That apparently bureaucratic detail is what makes the exercise repeatable: at the next version you re-score existing lines instead of rewriting everything, and an auditor can follow a thread end to end.

One risk line = one threat × one asset group

This is the methodological point I see missed most often. A single threat produces several risk lines, one per asset group — because the controls differ.

Take a threat of unauthorised access through credential guessing. It applies to your own application, to the third-party services you integrate, and to the infrastructure hosting all of it. Three perimeters, three owners, three sets of countermeasures: in the first case you control the code, in the second you depend on the vendor’s capabilities, in the third on your host or managed service provider.

Merge those situations into a single line and the controls column turns into a blur where nobody can tell who does what. Splitting them costs three lines and makes the matrix honest.

Exploitability, not probability

If you take away one point from this article, make it this one — and it is the one that gets the most files sent back.

The FDA explains that the likelihood of a security incident cannot be quantified from historical data or modelling, the way a hardware failure can. An attack is not a random phenomenon: it is the act of an adversary who decides. Security risk assessment is therefore non-probabilistic, and focuses on exploitability — the actual ability to exploit a vulnerability present in the device or its system.

This is exactly what separates your security matrix from your ISO 14971 analysis, and the guidance says so in those terms: this non-probabilistic approach is not the one used in patient-safety risk management, which underscores why the two processes are distinct but connected.

Two concrete consequences. Premarket, some CVSS exploitability factors — exploit code maturity, remediation level, report confidence — do not apply to unreleased software: the guidance then accepts either a worst-case assumption backed by controls, or a reasoned justification. And exploitability increases over time: if a penetration tester manages it today, an attacker will manage it more easily tomorrow. Vulnerabilities listed in CISA’s KEV catalogue, already actively exploited, should be designed out of the device.

The bridge to ISO 14971: expressing impact as harm

The impact column is not written in technical terms. “Loss of confidentiality” or “server compromise” means nothing to a clinical assessor. It is written as the clinical consequence in the worst credible case: what happens to the patient if this threat succeeds? A wrong therapeutic decision, delayed care, a prolonged procedure, a falsified value a practitioner relies on. The privacy dimension is declared in parallel, not instead: a health data breach is a harm in its own right.

And above all — this is an explicit submission requirement — you must provide the method for transferring security risks into the patient-safety risk assessment process. In other words, it is not enough for the two files to coexist: the path leading from a matrix line to the risk management file must be described, and workable.

A threat model that never mentions the patient is not a medical device threat model. It is an IT security audit with a medtech logo on it.

Scoring twice: initial risk, controls, residual risk

The matrix reads left to right in two passes. Exploitability × impact give the initial risk. You document the controls. Then you re-score both axes to obtain the residual risk, which carries the acceptability decision.

One principle follows, and it is worth holding firmly: controls reduce exploitability, almost never severity. Multi-factor authentication does not make an erroneous surgical plan less serious for the patient; it makes it less likely. As a result the impact column is generally identical across both passes — and a matrix where severity collapses after mitigation is an immediate red flag for an assessor.

On the scale itself, an important nuance: because security scoring rests on exploitability rather than probability, it cannot be strictly the one from your ISO 14971 file, and that is normal. What the FDA asks you to provide are the scoring methods pre- and post-mitigation, the associated acceptance criteria, and the transfer method mentioned above. The consistency required is therefore not about the scale, but about the verdict: the two files must never conclude differently on the severity of the same patient harm.

What makes the matrix defensible

A controls column describing intentions is worthless. Every control must reference a controlled document in your quality system: access control policy, user management procedure, cybersecurity policy, infrastructure configuration record. “MFA enabled” is a claim; “MFA enabled, see access control policy” is verifiable evidence. Anything unreferenced will be read as unverifiable — therefore as not done.

One last point: the matrix is a snapshot, and vulnerabilities keep arriving. The threat model must be wired into your vulnerability monitoring and triage process and into the post-market management plan the FDA expects. A threat model frozen on submission day is wrong six months later.

Recap: the columns of the matrix

FAQ

Does the threat model replace the ISO 14971 risk analysis?

No, and conflating them is a common mistake. They are two distinct analyses with different evaluation logics — non-probabilistic and exploitability-centred on one side, probabilistic on the other. They meet through a path you must describe explicitly in the submission: the method for transferring security risks into the patient-safety risk assessment process.

STRIDE, MITRE ATT&CK: which method should you pick?

The one you can apply completely — and can justify, since the FDA asks for the rationale behind the choice to accompany the documentation. STRIDE structures threat enumeration element by element; ATT&CK brings realistic adversary techniques. To get started, the Playbook for Threat Modeling Medical Devices from MDIC and MITRE is the resource the guidance itself cites.

Must the threat model be redone at every version?

Redone, no — re-evaluated, yes. That is what stable identifiers are for: a new interface or third-party service adds lines, an architecture change forces some to be re-scored, the rest is reviewed and dated. The FDA expects threat modelling performed throughout design, and IEC 81001-5-1 a living document reviewed at life-cycle milestones — not a deliverable produced once for the submission.