Threat Modeling Is the Work. Everything Else Is the Receipt.

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.

The Order That Actually Produces A Defensible System

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

What "Letting It Rewrite The Design" Looks Like

The single biggest tell of a real threat model is that something in the system actually changed because of it.

A connected infusion pump team we worked with started threat modeling six weeks before their submission was due. The first pass uncovered three things they had not been carrying as risks: the maintenance USB port had no authentication, the mobile companion app trusted any pairing response from a nearby BLE device with the right service UUID, and the cloud telemetry channel reused a single device certificate across an entire production lot.

None of those were going to show up on a checklist. All three would have showed up to an attacker, and to a reviewer who walked the architecture carefully.

The right response is not to write three more mitigations into the residual risk table and call it acceptable. The right response is to change the device. Disable the port. Require attested pairing on the app. Provision per-device keys at manufacture. Then the threat model documents a system that is actually defended, not a system someone hopes is defended.

That is the difference between threat modeling as engineering and threat modeling as compliance theater.

Where Most Threat Models Quietly Fail

A few patterns show up in almost every weak threat model we review.

The data flow diagram and the architecture diagram disagree. Two artifacts, one system, different stories. The reviewer notices immediately and the rest of the model loses credibility.

Trust boundaries that wrap the whole system. If your only trust boundary is "the device" or "the cloud," you have not done the work. The interesting boundaries are inside; between firmware and bootloader, between the mobile app and its dependencies, between the ingestion service and the analytics service.

Generic STRIDE entries copy-pasted from a template. "Spoofing of user identity" with no specifics is not a threat. "An attacker on the hospital network impersonates the device's update server because the device does not pin the update server's certificate" is a threat. The first is theater; the second tells you exactly what to build.

Residual risk tables full of mediums. Almost no real residual risk is medium. Medium usually means the team did not want to commit to high (which would force a mitigation) or low (which would force a justification). Pick.

Mitigations with no owner and no verification. A mitigation that does not map to a security requirement and a verification activity is a wish, not a control.

The Payoff

Do this 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.

Reviewers can feel that coherence. So can the team six months later when something changes and they need to know what is affected. So can the postmarket function when a CVE drops and somebody has to decide in 24 hours whether it touches the device.

A submission built on a real threat model is faster to write, easier to defend, and cheaper to maintain. A submission built on a justification looks fine until the first deficiency letter and then collapses under follow-up.

That's the whole game.