Threat modelling is widely recommended and rarely practised sustainably. What makes it fail, and what does a version that survives contact with delivery look like?

Why it fails

• It is too heavy. A formal methodology producing a large document takes days and is done once, for one system, and never repeated. The output ages immediately and nobody updates it.
• It happens too late — at a security review before release, when the architecture is fixed and findings are either ignored or become expensive exceptions.
• It is done by security specialists to the team, rather than by the team, so the knowledge does not transfer and the team's own design intuition never improves.
• The output has no owner and no route into the backlog, so findings are recorded and not addressed.
• It covers the whole system, which is too large to reason about, rather than the change being made.

The version that survives

Threat model the change, not the system, at design time, in thirty minutes, with the team.

Four questions, from the widely-used framing:

1. What are we building? A diagram on a whiteboard, with the data flows and the trust boundaries drawn — the boundaries are the substance; everything else is context.
2. What can go wrong? Prompted by a checklist so the team does not have to be creative under pressure.
3. What are we going to do about it? Concrete actions, with owners, in the same backlog as the feature.
4. Did we do a good job? A brief review, which is what makes the practice improve.

The prompts that generate the most findings

• At each trust boundary: what is being trusted, and what happens if it lies? Trust boundaries are where vulnerabilities live, and drawing them explicitly does most of the work.
• What is the most sensitive data here, and where does it go? Data flow reveals the exposure that component diagrams hide.
• What identity does this run as, and what can that identity do? Almost always over-privileged, and almost always fixable cheaply at design time.
• What happens if this component is fully compromised? The blast-radius question, which produces architectural findings rather than bug-shaped ones.
• What is logged, and could it contain secrets or personal data? Consistently productive, rarely asked.
• Who can access this in production, and is that recorded?

Making it stick

• A trigger tied to normal work — a checkbox on a design document, a pull-request template question, a rule for changes touching authentication, personal data or external interfaces. A practice with no trigger does not happen.
• Timeboxed, with a template that fits on a page.
• Findings in the ordinary backlog, ranked with everything else, not on a separate security list that is reviewed quarterly.
• The team facilitates it, with security available on request, so capability transfers rather than accumulating in one place.
• Reuse across similar changes — a library of common threats for the organisation's typical patterns, so each session starts from prior knowledge instead of from nothing.

Thirty minutes at design time, repeated for every significant change, produces vastly more security value than a comprehensive annual exercise — and it is the only version that continues past the first quarter.