Update a threat model whenever the design changes in a way that moves data, trust boundaries or who can act, and review it lightly on a regular rhythm even if nothing obvious changed. Guidance from OWASP and Microsoft treats it as living work, refined along with the system, not a one time document.
What the sources say
The OWASP Threat Modeling Cheat Sheet says a model should be maintained, updated and refined alongside the system, and integrated into normal SDLC processes. Microsoft's SDL page says threat modeling should be part of the routine development lifecycle, with the model refined progressively. The Threat Modeling Manifesto values continuous refinement over a single delivery and says to update the model in small, manageable iterations.
None of them gives a fixed number of months. That is deliberate: the right trigger is change.
Triggers that should reopen the model
- A new external integration or a new user type
- A new data store, or new kinds of data in an existing one
- A change to authentication, authorization or session handling
- A new trust boundary, such as moving a component to another network or account
- A new way of deploying, such as adding a queue or a third party service
- A security incident or near miss that the model did not predict
A light rhythm on top
| Cadence | What to do | Time |
|---|---|---|
| Per change | Ask "does this touch the diagram?" in design review | Minutes |
| Quarterly, as a suggestion | Skim the model, close finished items, check owners | 30 minutes |
| After an incident | Add what the model missed and why | One session |
The quarterly figure is a practical suggestion, not a requirement from any source. Pick a rhythm your team will keep.
How to spot a stale model
- The diagram shows components that no longer exist, or misses ones that do.
- Threats are marked non-mitigated but have no ticket or owner.
- Accepted risks have no date to look again.
- Nobody on the current team has opened it.
Tools can help. The pytm framework, for example, has a staleness check that shows how far a model has drifted from the code it describes. See what pytm does.
Make updating cheap
Keep the model in the repository, ask the diagram question in pull request templates, and update only the part that changed. Small edits that happen beat large rewrites that never do.
Quick check
Is an annual review enough?
Not by itself. The sources tie updates to change in the system. A yearly review can sit on top of change driven updates but should not replace them.
Do I redo the whole model each time?
No. Update the affected part. Small iterations are what the manifesto recommends.
A note on tooling
Safeguard watches the other side of change: continuous dependency scanning, SBOMs and policy gates flag new risk as code changes. A free scan shows the current state of a repository.
Sources
- OWASP Threat Modeling Cheat Sheet
- Microsoft SDL: Threat modeling
- Threat Modeling Manifesto
- pytm on GitHub
Last reviewed: 19 October 2026.
