I've reviewed hundreds of medical device threat models. The bad ones all look the same.
They describe the system as it was already built. They list a few generic threats. They map them to controls that were already in place. They close with a residual risk table that says "acceptable."
FDA reviewers can tell. So can attackers.
A real threat model is the work — the part that shapes architecture, drives requirements, and decides what gets built. The document is the receipt.
Here's the order that actually produces a defensible system:
-
Define the system before you describe it. Boundaries, data flows, trust zones, assumptions. If you can't draw it on one page, you don't know what you're securing.
-
Find the threats before the controls. STRIDE, attack trees, kill chains — pick a method and use it consistently. Threats first, mitigations second. Most teams reverse this and end up with a control catalog dressed as a threat model.
-
Argue with yourself. A trust boundary you don't push on is a trust boundary you're hoping holds. Walk every entry point. Walk every interface. Walk every assumption.
-
Let the threat model rewrite the design. This is the part teams skip. If threat modeling never changes the architecture, you're not doing threat modeling. You're doing paperwork.
-
Then write the document. Concise, traceable, every threat tied to a mitigation and a residual risk. The reviewer should be able to follow the logic in one pass.
The teams that ship cleanly aren't smarter. They start earlier and they let the model change their minds.
Do that and the SBOM, the security requirements, the architecture views, the test plan, and the risk file all line up — because they were derived from the same source, not assembled from different ones.
That's the whole game.