What Does FDA Actually Want in a Threat Model?

There is a version of this document that gets written a month before submission, from a generic threat list, against a design that was frozen the previous quarter. It exists to fill a heading.

Reviewers recognize it on sight, and the tell is not the prose. It is that nothing else in the submission points back to it. The security requirements trace to no threat in the model, the architecture diagrams contain elements the model never considered, and the risk assessment scores hazards the model never identified. Every document in the package is internally consistent and none of them is connected to any other.

That is the failure this page is about, and the fix is upstream of the writing.

Draw the system before you enumerate anything

You cannot list threats against a system you have not drawn, and most teams try anyway, working from a shared mental model that turns out to differ per person once it hits paper.

The data flow diagram is the starting artifact. Processes, data stores, flows, external entities - and the part that gets left off, trust boundaries. A trust boundary is any line where the level of trust changes: between the device and the companion app, between the app and the API, between your service and a third party you call, between an authenticated session and an unauthenticated one, between the clinical network and the general one.

The boundaries are where the interesting questions live, because they are where someone else's assumptions become your inputs. A diagram with no trust boundaries drawn on it is an architecture diagram with a different name on it, and the threat enumeration built from it will be a list of things that could go wrong somewhere.

Draw the system you shipped, not the one in the design review deck. Those diverge, and the divergence is where the findings are.

Then apply a method rather than your imagination

Brainstorming produces threats. It does not produce coverage, and it is not repeatable, which means the model cannot be maintained by anyone who was not in the original session.

STRIDE per element is the common structured approach and it works: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege, asked of every element and every flow on the diagram. Attack trees are the other approach named in the AAMI literature, and they suit a different question - not what could go wrong here, but how would somebody get to that outcome. AAMI TIR57 supplies threat libraries to work from, and MITRE ATT&CK is commonly used alongside as a source of technique-level detail.

The value of STRIDE is not that it is clever. It is that it is exhaustive in a way a brainstorm is not, and that two engineers running it against the same diagram produce roughly the same list.

The tedium is real, and pretending otherwise is how these sessions get abandoned. Six categories against every element and every flow is hours of work, and a large share of those hours go to combinations that are obviously inapplicable the moment somebody reads them out.

That triage is the part worth handing to a model. Not the analysis - the weeding. Not every STRIDE category applies to every element, and an AI pass over the element list will clear the easy negatives and leave you with the combinations that actually require thought, which is where you wanted the session to be spending its time. What comes back has to be reviewed, all of it, under the same rule that governs AI-assisted code: a cleared combination is a claim, and somebody still has to agree with it. The workload drops. The obligation does not move.

Rank by harm, not by data sensitivity

Threat modeling as practiced in most of the industry optimizes toward confidentiality. That is the reflex an IT security background installs, and it is the wrong reflex here.

The question that ranks a threat on a medical device is what happens to a patient. A threat that leaks data may matter considerably less than a threat that changes a therapy parameter, delays an alarm, or corrupts a reading that somebody treats against. Rank by data sensitivity and you will systematically put the wrong threats at the top of the list, then write requirements for them, then test them, and carry that inversion all the way through the submission.

This is the section that separates a real medical device threat model from an IT threat model wearing a lab coat, and it is why the clinical voice belongs in the session rather than in a review afterward.

The harm ranking is also the seam where this document meets your risk files, which have their own rules about scoring and where the two processes converge.

Ask how far each threat spreads

Add one more question to every threat in the list: does this compromise one device or all of them?

A credential unique per unit and a credential shared across the fleet are the same vulnerability with radically different blast radii, and the second is a different conversation with a regulator, with a customer, and with a hospital's security team. The multi-patient question changes the severity, it changes the urgency of the control, and it changes what your architecture has to demonstrate rather than assert. A published advisory built entirely on that distinction is worth reading next to your own threat list.

Treat scale as a first-class attribute of every threat rather than something you notice about a few of them.

What the threat model has to feed

The model is not a standalone deliverable, and whether it is any good is partly answerable by looking at what depends on it.

The architecture views can be delivered as part of the threat modeling documentation, and in practice they are built alongside it - the diagram work and the view work are the same work seen from two angles. The security risk assessment consumes the threat list as its input. The security requirements exist to control threats, which means each one should trace up to something in this document. The verification evidence then traces to the requirements.

If nothing downstream points back at your threat model, you have produced decoration. Check that before a reviewer does: pick five security requirements at random and find the threat each of them controls.

Revisit it when a boundary moves

Threat modeling is expected throughout the design process rather than once before submission, and "throughout" needs an operational definition or it becomes an intention.

The workable rule is that any change moving a trust boundary triggers a revisit. A new interface. A new component that reaches the network. A new integration with a system you do not control. A new deployment model. A change in who is allowed to do what. Those are all boundary events, and a threat model that predates one is describing a product you no longer ship.

Everything else - refactors, dependency bumps, features that add no new connections - can wait for the scheduled review.

This is engineering guidance, not legal or regulatory advice.

This is the work I do - FDA cybersecurity submissions, penetration test remediation, and security ownership for companies too small for a full-time CISO. bill@bato.com.