How do you know when a threat model has gone stale, and how would you catch it before an incident does?

Short answer

A threat model is stale when its diagram or assumptions no longer match production. Refresh it after new integrations, changed trust boundaries, new sensitive data, authentication changes, dependency swaps, incident lessons or major deployment topology changes.

Staleness is a property of drift, not of age

The natural instinct is to answer with a calendar — review every six months — but a calendar cadence catches staleness only by coincidence, because the thing that actually invalidates a threat model is a change in the system's shape, not the passage of time.

A threat model built around a monolith talking to one database can remain perfectly accurate for two years if nothing about the system changes, and can be dangerously wrong within a month if the team adds a new third-party integration, moves an internal-only endpoint behind a public gateway, or swaps an authentication mechanism. The trigger that matters is the change event, and a review scheduled by date will either fire when nothing changed, wasting the review, or miss a change that happened the week after the last scheduled check.

The concrete list of change events worth wiring a trigger to is short and specific: a new trust boundary is introduced, such as a third-party integration or a new external-facing endpoint; a component moves from internal-only to internet-reachable, or the reverse trust assumption quietly stops holding because a network topology change happened for unrelated reasons; an authentication or authorisation mechanism changes, including something as apparently minor as switching a token format or adding a new scope; a dependency with broad access — a new library with a lot of capability, a new admin tool, a new service account — is added; or the data classification of what a component handles changes, such as a service that previously handled only anonymised data starting to receive personally identifiable information.

Wiring the trigger into a process people already follow

The mechanism that actually works ties the review trigger to a step teams already do rather than inventing a new one they will skip. Architecture decision records are the natural attachment point: if a design proposal changes a trust boundary, adding a threat-model review as a required section of that ADR — not a separate meeting scheduled later — means the review happens at the moment the relevant knowledge is freshest and the cost of catching a problem is lowest, before the design is built rather than after.

The same logic applies to a pull request that adds a new external dependency or a new inbound integration: a lightweight checklist gate at that point, asking whether the change alters any trust assumption in the existing model, catches drift continuously rather than in a periodic sweep that arrives too late or too early.

Trigger                              What in the model it invalidates
-----------------------------------  --------------------------------------
New third-party integration          Adds a boundary the model never drew
Endpoint moved public <-> internal   Changes who the attacker could be
Auth mechanism changed               Invalidates every mitigation assuming
                                      the old identity check
New dependency with broad access     New elevation-of-privilege path
Data classification changed          Information-disclosure severity shifts

Staleness is not the same failure as being wrong from the start

It's worth separating this from a threat model that was incomplete or wrong when it was written, because the fix is different. A stale model was accurate once and the system moved past it — the fix is a better trigger. A wrong model never matched reality, often because the review happened on paper without anyone who actually understood the deployed system's quirks, and the fix is a better review process, not a faster one. Conflating the two leads to a team that reviews more often without ever improving what the review actually checks, which produces a false sense of currency: a threat model reviewed last week can still be wrong in a way frequency cannot fix if the people reviewing it never had visibility into what actually changed.

The honest caveat, and the one worth volunteering, is that even a threat model triggered at exactly the right moments only catches threats within the categories the team thinks to model. It will not surface a genuinely novel attack pattern nobody on the team has seen before. That is not an argument against the discipline — it is why threat modeling is paired with monitoring, incident response and periodic red-teaming rather than treated as a one-time guarantee that closes the question.

A threat model does not decay on its own; it is invalidated by a specific change, so the only reliable way to catch staleness is to make the change itself the trigger for the review, not the calendar.

---

© 2026 Preptima. Originally published at preptima.com.