Threat modelling should change the design

I’m not particularly interested in a threat model that gets filed away and never changes how anything is built.

The diagram is useful. So is the list of threats. But the conversation only really earns its keep when someone leaves knowing what needs to be designed differently, and why.

Begin with the consequence

Ask what would matter if the system behaved incorrectly. Could someone view another client’s information, approve an action they should not control, or disrupt a service others depend on?

Then follow the relevant data and authority. Who initiates the activity? Which component makes the decision? Where does one system rely on another? What is assumed at each boundary?

Turn the discussion into a design choice

Suppose a hypothetical service accepts an account identifier from a browser. The important question is how the service determines that the signed-in person may act on that account. That discussion should produce an authorization decision, an owner, and a way to test it.

It might also reveal that a broad service credential is being used where narrower access would work. Changing that design before other components depend on it can make implementation and operation simpler.

Return when the assumptions change

A threat model should follow material changes in data, access, dependencies, and business use. Revisit the parts affected by the change, with the people who understand them. A small, focused discussion can be more useful than recreating the entire document.

The question is what we will build differently because of what we learned.

My preferred outcome is a short record of meaningful threats, decisions, responsibilities, and validation. Enough detail to guide delivery, and clear enough for the next team to understand why the boundary exists.