Threat modelling has a reputation problem. In many organisations, it's associated with lengthy documents that security consultants produce and delivery teams never read. The output sits in a shared drive, ticked off as a compliance activity, while the actual architecture decisions it should have informed were made weeks earlier.
The document trap
The most common failure mode is treating threat modelling as a document rather than a conversation. Teams produce detailed STRIDE analyses or attack trees that are technically correct but practically useless because they arrive too late in the design process, cover threats the team already knows about, and don't connect to specific engineering decisions.
The second problem is audience. Many threat models are written for auditors rather than engineers. They use security terminology that delivery teams don't speak and describe risks at a level of abstraction that doesn't map to implementation choices.
Threat modelling as design input
Effective threat modelling happens during design, not after it. The ideal moment is when the team has a proposed architecture but hasn't started building. A 90-minute session with the right people — the architect, lead developer, and someone with security context — can identify the decisions that matter most from a security perspective.
Focus on decisions, not documentation. The output of a threat modelling session should be a short list of architectural decisions: "We will encrypt at rest because...", "We will use mutual TLS for this integration because...", "We accept the risk of X because the mitigation cost exceeds the impact." These decisions get recorded as Architecture Decision Records that live alongside the code.
Keep the scope tight. Don't model every possible threat to every component. Focus on the trust boundaries — where data crosses between systems, users, or privilege levels. Most security vulnerabilities cluster around these boundaries, and modelling them produces the highest return on investment.
Building the habit
The goal is to make threat modelling a lightweight, recurring practice rather than a one-time heavyweight exercise. Run short sessions at the start of significant features, not comprehensive reviews at the end of projects. Over time, teams internalise the thinking patterns and begin asking security-relevant questions naturally during design discussions.