Medical Device Threat Modeling: Why Rationale Wins

An investigator does not ask whether your device is secure. That question has no answer anyone can defend. The question that actually gets asked in the room is narrower and far harder: why did you choose those controls and not others? Medical device threat modeling is the discipline that produces the answer — and the recorded answer is design rationale, which means it belongs inside your design and development file, not in a security engineer's laptop.

The distinction matters more for medical device threat modeling now than it did two years ago. The FDA's Quality Management System Regulation took effect on February 2, 2026, incorporating ISO 13485:2016 by reference into 21 CFR Part 820. One day later, the FDA issued the revised final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions — retitled, deliberately, to put the quality management system in the name. Medical device threat modeling is named in that guidance as an expected activity. The clauses it now answers to are the design control clauses of ISO 13485, which are federal law in the United States.

Medical device threat modeling sits on the bridge between two bodies of MSI work. On one side sits MSI's guide to medical device cybersecurity as a QMS shift, which maps the whole evidence package to the standard. On the other sits MSI's design and development pillar, which covers how controlled design actually works. Threat modeling is where the two meet, and it is the place teams most often fall between them — the security group builds a model nobody in quality has read, and the design team writes inputs that never mention a threat.

Why Medical Device Threat Modeling Is Design Rationale, Not a Security Deliverable

Reason. Record. Defend.

Every mature engineering discipline distinguishes between a decision and the reasoning that produced it. The decision is visible in the product. The reasoning is invisible unless someone writes it down. Design rationale is the written form of the reasoning — and in a regulated device quality system, reasoning that was never written down is functionally reasoning that never happened.

Security controls are unusually vulnerable to this failure because they look self-justifying. Encryption is obviously good. Authentication is obviously good. Logging is obviously good. A specification that lists them reads like a complete answer, and it is not. It answers what while leaving why entirely undocumented, and why is where a reviewer, a registrar, and an investigator all live. Medical device threat modeling exists to close that gap by forcing the team to name the adversary, the entry point, the asset, and the resulting harm before naming the control.

The Playbook for Threat Modeling Medical Devices, developed by the Medical Device Innovation Consortium and MITRE with FDA funding, organizes the discipline around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Read those four questions against Clause 7.3 and the alignment is almost uncomfortable. The first is design planning and scope. The second is design input. The third is design output. The fourth is design review, verification, and validation. The playbook did not set out to describe design controls. It described them anyway, because rigorous engineering converges.

That convergence is the practical argument for running medical device threat modeling inside the design process rather than parallel to it. Two parallel processes produce two sets of records that disagree with each other at the worst possible moment. One integrated process produces a single traceable chain. MSI client experience suggests the parallel arrangement is the more common starting point, and that the cost of it surfaces during the first serious design review rather than during development.

How Medical Device Threat Modeling Becomes a Design Input Under Clause 7.3.3

Name. Translate. Approve.

Clause 7.3.3 of ISO 13485:2016 asks for functional, performance, usability, and safety requirements according to intended use; applicable regulatory requirements and standards; applicable outputs of risk management; and, where appropriate, information derived from previous similar designs. Cybersecurity requirements — the outputs of medical device threat modeling included — do not get a special clause. They arrive through all four doors at once, which is exactly why they get dropped — a requirement that belongs to everyone belongs to no one unless the process assigns it.

The translation step is the whole craft of medical device threat modeling. A threat model output is a statement about an adversary. A design input is a statement about the device. Getting from one to the other is a deliberate act of engineering writing, and it is where most teams either do the work or quietly skip it. Consider a single threat: an attacker on the same clinical network replays a captured command to a connected infusion device. That is the threat. It is not yet an input to anything.

Three things happened in that translation. The threat acquired a harm, which pulls it into ISO 14971:2019 risk management rather than leaving it as an IT concern. The requirement acquired a mechanism and a failure behavior, which makes it verifiable. And the acceptance criterion arrived early, which is what Clause 7.3.3's “adequacy” review is actually testing for. Good medical device threat modeling ends in sentences an engineer can build against and a verification tester can measure.

Which threat modeling method should feed the design inputs?

The FDA guidance does not mandate a medical device threat modeling method, and neither does the MDIC playbook — it is explicitly non-prescriptive. STRIDE remains the most widely used starting structure because its six categories map cleanly onto requirement language. Attack trees suit devices with a small number of high-consequence failure paths. Data-flow decomposition of the kind described in NIST SP 800-154 works well for devices whose risk is concentrated in what data moves where. Kill-chain and adversary-behavior framings drawn from CISA resources help teams reason about sequences rather than isolated events.

In medical device threat modeling, method choice matters far less than method consistency. A registrar will not fault STRIDE or reward attack trees. A registrar will fault a program that used one method on the first device, a different method on the second, and can produce no documented reason for either choice. Consistency is a quality system property, not a security property — which is one more reason medical device threat modeling belongs to the design procedure rather than to whoever happens to hold the security title this year. MSI's guidance on running the design and development process day to day covers the same principle applied to design reviews and record structure.

Where the software standards attach

Two standards do a great deal of quiet work for medical device threat modeling here. IEC 62304 governs the medical device software life cycle and gives the software requirements specification its structure — the document where translated threat requirements physically land. IEC 81001-5-1 addresses security activities across the health software life cycle and is increasingly the reference regulators point to for secure development practice. AAMI TIR57 supplies the bridge most teams are missing outright: how security risk management relates to, and stays distinct from, ISO 14971 safety risk management.

That distinction deserves a sentence of its own, because collapsing the two is a genuine finding source. Security risk and safety risk are not the same analysis. Security risk considers an intelligent adversary who adapts; safety risk considers foreseeable misuse and random failure. They meet at the point where a security event produces patient harm, and that meeting point is what must appear in the risk management file. Everything upstream of it can stay in the security analysis. Nothing downstream of it can.

What Medical Device Threat Modeling Requires of Design Outputs Under Clause 7.3.4

Specify. Trace. Verify.

Clause 7.3.4 is the clause that converts intention into product, and it is where medical device threat modeling has to become a specification. It is also the clause where security work most often becomes untraceable, because security outputs are frequently produced by people who do not think of themselves as producing design outputs. A security architecture diagram drawn to explain a decision in a meeting is, the moment it describes the shipped device, a design output subject to review and approval before release. If it lives only in a wiki, the quality system has lost it.

The FDA guidance names a set of artifacts that medical device threat modeling should produce, and every one of them is recognizable as a Clause 7.3.4 output or a record referencing one. The security architecture views. The software bill of materials. The security testing evidence, including penetration testing. The cybersecurity labeling that tells the operator what the device expects of the network it joins. The updatability and patchability design — because the FDA has said plainly that a device that cannot be safely updated will eventually become an unsafe device. Updatability is a design characteristic, which makes it a design input at 7.3.3 and a design output at 7.3.4 like any other.

The SBOM is a design output with a purchasing obligation attached

In medical device threat modeling, the software bill of materials sits at an unusual junction. As a description of what the device is made of, it is a design output under 7.3.4 — and Clause 7.3.4 explicitly requires outputs to provide appropriate information for purchasing. That is not incidental phrasing. It is the hinge that connects the threat model to Clause 7.4 purchasing controls, because third-party and open-source components are supplied product, and supplied product with known vulnerabilities is a supplier quality problem as much as a security one.

An inventory alone answers a question no regulator asked. What the guidance expects is the inventory plus an assessment of known vulnerabilities in those components as reasonably foreseeable risks — which is ISO 14971 language applied to software provenance. In a mature program, the threat model is what tells you which components are on an attack path and therefore which vulnerability findings are urgent rather than merely open. Without the model, every finding looks equally important, which in practice means none of them do. MSI's work on ISO compliance automation looks at how organizations sequence tooling against this kind of load without buying modules they never use.

Each item on that list should carry a reference back to the threat that motivated it. That single habit — a traceability column, nothing more elaborate — is the difference between a design file that answers questions and one that generates them. It costs almost nothing during development and it is nearly impossible to reconstruct afterward, which is the argument for building medical device threat modeling traceability from the first design review rather than the last.

What happens when the threat model changes after release

Threat landscapes move, and medical device threat modeling has to move with them. A component reaches end of support, a new class of attack becomes practical, a customer deploys the device into a network topology nobody anticipated. Each of those is a change to the threat model, and a change to the threat model that alters a design input is a design change under Clause 7.3.9 — reviewed, verified, validated as appropriate, and approved before implementation. Organizations running design changes through email and shared folders are exposed here, which is the case MSI makes in its analysis of change management automation under ISO 9001 and ISO 13485.

This is also where the postmarket and premarket halves of a medical device threat modeling program finally meet. Vulnerability reports arrive through feedback and complaint channels under Clause 8.2. Some become corrections; some become corrective actions under Clause 8.5. A meaningful share should also become threat model revisions, because a vulnerability that surprised you is evidence your model had a blind spot. Programs that patch without updating the model keep the same blind spot indefinitely.

Why the Design Review Is Where Medical Device Threat Modeling Is Proven (Clause 7.3.5)

Challenge. Decide. Record.

There is a phrase in Clause 7.3.5 that most teams read past: representatives of functions concerned with the design and development stage being reviewed, and other specialist personnel. That phrase is doing real work. If the stage under review contains security decisions and no one in the room can evaluate a threat model, the review did not meet the requirement — regardless of how many signatures it collected. Competence is not decorative here; it connects directly to Clause 6.2, which requires the organization to determine the necessary competence for personnel performing work affecting product quality and to have records of it.

This is the most common structural failure MSI encounters when medical device threat modeling is retrofitted onto an existing design process. The security work is real, often excellent, and produced by capable people. It simply never enters a forum where it can be contested by the design authority, the risk owner, and the regulatory lead simultaneously. The model is briefed rather than reviewed. Briefings do not generate the kind of record Clause 7.3.5 asks for.

What a design review record should capture about the threat model

In medical device threat modeling, a review record that merely states the model was presented and accepted is thin evidence. A record that captures what was challenged and how it was resolved is strong evidence, and it is not meaningfully harder to produce. The difference is a habit of minuting disagreement rather than only outcomes.

Note the second and third items in particular. A threat ruled out with a documented basis is a strength. A threat that never appears anywhere is indistinguishable, to a reviewer, from a threat nobody thought of. Explicit scoping decisions are among the highest-value records a threat modeling program produces, and they are almost always the ones teams neglect because ruling something out feels like an absence of work rather than a product of it.

Verification and validation of medical device threat modeling outputs follow at Clauses 7.3.6 and 7.3.7, and the guidance is direct that software developers may need to establish cybersecurity risk management and validation processes to satisfy those subclauses. Penetration testing sits here, and it is worth being precise about what it proves. Penetration testing verifies that specific controls resist specific attempts. It does not validate that the threat model was complete. Completeness is argued in review, not demonstrated in a lab, which is one more reason the review record carries so much weight.

The MSI Threat-to-Record Chain: Five Links Medical Device Threat Modeling Must Complete

Link. Trace. Prove.

Across 28 years and more than 200 certification audits attended, the medical device threat modeling pattern MSI sees is consistent: teams are rarely missing the work. They are missing the connective tissue between the pieces of work. The five-link chain below is a diagnostic, not a template — it takes about an hour to run against a single control and it reliably finds the weak link before a registrar does.

Five questions that measure your threat modeling maturity in an hour

Score each question as documented, partial, or absent. The scoring is deliberately blunt, because a two-axis honest answer is more useful than a five-point flattering one. Any answer below “documented” is a specific, fixable piece of work rather than a vague sense that the program needs improving.

Question five is the one that separates medical device threat modeling programs that are genuinely operating from programs that were completed. Organizations typically report that the threat model was built during the submission push and has not been revisited since, which is understandable and also exactly the condition the postmarket expectations in the guidance are written to prevent. A threat model with a single revision date is a snapshot. A threat model with a revision history tied to triggers is a process.

If the five questions surface more gaps than you expected, that is a normal result rather than a bad one, and it is a good moment to bring in an outside read. MSI's The Portrait is an independent operational assessment built on exactly this premise — the disconnect between what a system documents and what it does is nearly invisible from inside the frame. For teams who would rather start with the standard itself, MSI's ISO 13485 Gap Analysis page walks the clause-by-clause scoring method in detail.

How Medical Device Threat Modeling Fails in the Audit Room

Orphaned. Unread. Unrevised.

The medical device threat modeling failure MSI has watched play out most often is the orphaned model. A capable security team produces a genuinely good threat model. It lives in a security repository. It is not a controlled document under Clause 4.2.4, it is not referenced from the medical device file under Clause 4.2.3, and no design input cites it. When the auditor asks the design authority to explain why a particular control exists, the answer is that security asked for it. That answer is a finding, and it is a finding about the quality system rather than about the device — which is precisely why it stings. The security work was fine. The system could not prove it happened.

The second medical device threat modeling failure is the unversioned model. Threat models attract informal editing because they are analytical documents that improve with iteration. Without document control, three versions circulate, verification was run against the second, and the submission referenced the first. Nobody did anything wrong at any point. The record set is still indefensible.

The third medical device threat modeling failure is the model nobody in the review could read. This one is uncomfortable because it looks like a competence gap and often is one — but it is a competence gap the standard actually anticipates. Clause 6.2 requires determining necessary competence and maintaining records of it. If your design review needs someone who can evaluate a trust-boundary argument and you have not defined that role, the gap is in the competence matrix, not in the person. MSI's guidance on navigating a medical device quality management system covers how this and adjacent role definitions get built into a working system.

The fourth medical device threat modeling failure is the parallel risk file. Security risk lives in one register with its own scoring, safety risk lives in the ISO 14971 file with another, and no defined path connects them. This is the failure with the longest tail, because it survives audits for years and then produces a serious problem the first time a security event has a clinical consequence and nobody can show the harm was ever evaluated. AAMI TIR57 exists specifically to prevent this, and adopting its logic early is far cheaper than reconciling two registers later.

What an Investigator Asks About Medical Device Threat Modeling Under the QMSR

Show. Trace. Explain.

Two consequences of the February 2, 2026 transition deserve emphasis for medical device threat modeling because they change what is discoverable. Management review records and internal audit reports, historically shielded from routine FDA inspection, are now within scope under the QMSR framework. So are supplier audit reports. For a security program, that means the honest internal assessment of where the threat modeling program is weak is now a document an investigator may read — which is an argument for writing those assessments carefully and closing them promptly, not for stopping writing them.

The second consequence is definitional. Section 524B of the Federal Food, Drug, and Cosmetic Act sets a three-part test for a cyber device, and a device that was outside the definition can move inside it because of a feature release. A connectivity feature added for a legitimate clinical reason can bring an entire statutory documentation obligation with it. This is why medical device threat modeling should be triggered by the design change process rather than by the regulatory calendar — the design change is what moves the device, and the design change record is where the trigger belongs.

Internal audit is the control that catches a broken medical device threat modeling chain before an external party does. An internal audit program that samples design records against Clause 7.3 and specifically traces two or three security controls through the five-link chain will surface a broken link long before a registrar arrives. MSI's guide to internal audit planning covers how to write criteria precise enough to make that sampling meaningful, and the ISO 13485 management review guide covers how the findings should reach leadership rather than stalling in the quality department.

A 90-Day Path to Defensible Medical Device Threat Modeling

Connect. Control. Sustain.

The sequence matters in medical device threat modeling. Teams that start by rewriting the threat model spend three months producing a better orphan. Teams that start by connecting what already exists find that the model itself needs less work than expected, and that the connective work exposes the real gaps precisely because it forces every claim to land somewhere.

One honest caveat about the timeline. Ninety days is realistic for connective work on a single device family with an existing design file in reasonable order. It is not realistic if the design history is genuinely thin, if the device is mid-submission, or if the organization is simultaneously standing up its first quality system. In those cases the same three phases apply and the calendar stretches — and stretching it deliberately is far better than declaring a finish line the records cannot support.

What this looks like when it is working

A working medical device threat modeling program has a quiet signature that is easy to recognize once you have seen it. Design reviews contain arguments about threats rather than presentations about them. The risk file and the security analysis reference each other by document number. New engineers can find out why a control exists without asking anyone. And when a vulnerability report arrives, the first question in the room is whether the model anticipated it — because that question, asked routinely, is what keeps the model from going stale.

None of this makes a device secure, and it is worth saying so plainly. Documented rationale does not stop an attacker. What it does is make the organization's reasoning inspectable, improvable, and transferable — which is the only mechanism anyone has found for making security decisions get better over time rather than merely get made. That is the durable argument for treating medical device threat modeling as design rationale, and it holds whether or not a regulator is in the building.

Related reading from MSI

Medical Device Threat Modeling: Frequently Asked Questions

Asked. Answered. Sourced.

Is threat modeling explicitly required by ISO 13485?

Which ISO 13485 clauses does a threat model touch?

Is a threat model the same thing as an ISO 14971 risk analysis?

Does the FDA require a specific threat modeling methodology?

Does this apply to devices already on the market?

Who needs to be in the design review when the threat model is examined?

How often should the threat model be revised?

Is an SBOM enough on its own?