Threat model a feature when it touches authentication, access control, business logic or a key flow, and again whenever its data flows or permissions change. You do not need a session for every ticket. A short trigger checklist lets the team decide in a minute during refinement whether a feature needs one.
What the guidance says
The OWASP Top 10 entry on insecure design advises threat modeling for critical authentication, access control, business logic and key flows. It adds that threat modeling should be integrated into refinement sessions or similar activities, and that teams should watch for changes to data flows and access control.
That gives you two kinds of trigger: what the feature is, and what changed.
A checklist you can paste into your template
Ask during refinement. If any answer is yes, schedule a session.
- Does it add or change how users sign in, reset credentials or manage sessions?
- Does it change who can see or modify what?
- Does it move money, credits, points or anything with value?
- Does it add a new way to get data in, such as an upload, webhook or API?
- Does it add a new place data is stored or sent, including a new vendor?
- Does it expose something that was previously internal?
- Does it handle a new type of sensitive data?
- Does it add an AI or automation step that acts on behalf of a user?
What does not need a session
Copy changes, layout work, internal refactors that keep the same flows, and bug fixes that do not alter trust boundaries. Skipping these is how you protect time for the sessions that matter.
Size the session to the change
- A small change to an existing model: ten to fifteen minutes, update the diagram and check the touched flows.
- A new feature in a known area: about an hour with the four questions.
- A new service or product: a longer session, possibly split across a few days.
The Threat Modeling Manifesto stresses early and frequent analysis and following design changes in manageable iterations. Many small updates beat one big review.
Make it part of the workflow
Add a field to the ticket template: "Threat model needed? Yes or no, and why." Make the answer visible on the board. When the answer is yes, link the diagram and the resulting tasks to the ticket.
Review the rule every quarter. If sessions keep finding nothing, tighten the triggers. If incidents happen in features that were skipped, widen them.
Who decides
The product team decides first, using the checklist. A champion or security contact can overrule in either direction. Keep the call light so teams do not feel gated.
An example decision
A team plans to add single sign on for enterprise customers. Triggers: it changes how users sign in, it adds a new vendor flow and it changes who can see what. Three yes answers, so schedule an hour. A different team plans to change the colors of a dashboard. No triggers, no session. The checklist keeps both decisions fast and consistent.
Quick check
Should every user story have a threat model?
No. Reserve sessions for features that match a trigger. Over-modeling burns goodwill and slows delivery.
What if the team disagrees about whether to model?
Default to a fifteen minute check. If the team finds nothing, record that and move on.
Sources
Last reviewed: 19 October 2026.
