Most threat models die the week after the workshop. They are produced with real effort, presented once, filed in a shared drive, and quietly overtaken by the next sprint. Six months later the system has three new integrations and the model describes something that no longer exists.
The problem is rarely the method. STRIDE, attack trees and data-flow analysis all work. The problem is where the model lives and who owns it.
Put it next to the code
A threat model that sits in the repository gets reviewed the same way the code does. When someone adds a new external dependency, the pull request is the natural moment to ask what trust boundary it crosses. That question is cheap to ask in review and expensive to ask in an audit.
In practice this means a plain-text model: a short description of the system, a data-flow diagram as code, a list of threats with owners and status, and a log of the assumptions everything rests on. Nothing that needs a licence to open.
Keep it small enough to maintain
The urge in a first workshop is completeness. Resist it. A model with forty well-understood threats that the team actually tracks is worth more than one with four hundred that nobody reads.
Start with the trust boundaries: where data crosses from one level of trust to another. Most serious findings cluster there. Expand only when a change in the system demands it.
Record assumptions, not just threats
The most useful line in a threat model is often an assumption: "internal services are only reachable from inside the cluster". When that assumption breaks, every threat that depended on it needs another look. Writing assumptions down turns silent drift into a visible change.
Make it someone's job
Ownership sits with the engineering team, not the security function. Security can facilitate, challenge and review, but a model owned by outsiders is a model nobody updates.
A good test: if the security architect left tomorrow, would the model still change when the system does? If yes, it will survive.