Four anti-patterns sink most threat modeling efforts: relying on a hero, admiring the problem, overfocusing, and chasing one perfect diagram. The Threat Modeling Manifesto names all four. If your sessions feel like a chore that produces no changes, check this list first.
Hero Threat Modeler
The manifesto describes this as assuming success depends on one person's innate talent or mindset. It also states that everyone can and should threat model.
In practice the hero is the one security engineer who joins every session, sees every flaw and becomes a bottleneck. The fix is to teach the four questions to developers and let them run sessions, with the security team coaching. Champions are a good vehicle for this.
Admiration for the Problem
This is stopping at analysis without pursuing practical, relevant solutions. A long threat list that never becomes tickets is the classic symptom.
Close the loop in the same meeting. For each threat that matters, name a response and an owner before everyone leaves. If the list is too long, rank it and only commit to the top few.
Tendency to Overfocus
The manifesto describes losing sight of the big picture, or overemphasizing adversaries, assets or techniques. A team may spend an hour on an exotic attack on the cryptography library and never ask whether the admin panel is exposed.
Time box each area. Return to the data flow diagram and make sure every trust boundary got at least a few minutes.
Perfect Representation
Seeking a single ideal view of the system. The manifesto notes that multiple representations reveal different problems. A data flow diagram shows trust boundaries. A sequence diagram shows ordering problems. A list of user stories shows abuse of intended features.
Draw something rough, use it, and improve it next time. The data flow diagram guide covers a simple starting notation.
The positive values behind the warnings
The manifesto values:
- A culture of finding and fixing design issues over box ticking compliance.
- People and collaboration over processes, methodologies and tools.
- A journey of understanding over a point in time view.
- Doing threat modeling over discussing it in the abstract.
- Continuous refinement over a one off deliverable.
Each anti-pattern is the opposite of one of these. If you want a quick self check, read the values aloud at the start of a session and ask which ones you are practicing.
A short retrospective
After each session, ask three questions. What did we change because of this? Who ran it, and could someone else next time? What did we skip that we should not have? Write the answers next to the model so the next session starts with them.
Spotting the patterns in the wild
Hero: the same name appears on every model. Admiration: the model has forty threats and two tickets. Overfocus: half the page covers one component. Perfect representation: the diagram has been in draft for a month. Look at your last three models and count which of these apply. Most teams find at least one, and naming it is half the fix.
Quick check
Is it bad to have a security expert in the session?
No. The anti-pattern is depending on that expert. Invite them as a coach and make sure developers can run the session without them.
Sources
Last reviewed: 19 October 2026.
