A threat model should change a design.

A threat model should give a team a reason to build something differently while the design is still easy to change.

A diagram and a list of threats can help a team think. The useful outcome is a clearer understanding of what the system must protect and which choices will make that protection possible.

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.