Train architects and tech leads in secure design by teaching them to ask four questions of every design: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. Practise on real designs, in short sessions, with the whole team present.
Why this group needs its own training
Code level training reaches the people who write functions. Design decisions are made earlier, by a smaller group, and they are costly to reverse. A tech lead who chooses a shared service account or an open internal endpoint sets a risk that no later code review fully removes.
The Threat Modeling Manifesto states the aim directly: to improve the security and privacy of a system through early and frequent analysis.
The four questions
These come from the Manifesto and make a good backbone for any design review.
- What are we working on? Draw it. Boxes, data stores, trust boundaries, who talks to whom.
- What can go wrong? List threats, not solutions. Different viewpoints help, so include people who did not design it.
- What are we going to do about it? For each threat, decide: fix, reduce, accept or drop the feature.
- Did we do a good enough job? Check the result against the first three answers, and note what you would revisit.
What the Manifesto values
It prefers a culture of finding and fixing design issues over compliance for its own sake, people and collaboration over tools, a journey of understanding over a one time snapshot, doing threat modeling over talking about it, and continuous refinement over a single delivery.
For trainers, that is useful direction. Do not teach a heavyweight method that produces a document nobody reads. Teach a habit the team repeats when the design changes.
A training format that works
| Step | Time | What happens |
|---|---|---|
| Warm up | 10 min | Walk through one small example together |
| Real design | 30 min | The lead brings a current design, the group models it |
| Actions | 10 min | Each threat gets an owner and a decision |
| Retro | 10 min | What was missing from the picture? |
Run it three times over a quarter with different designs. By the third round, leads should be running it themselves.
Anti-patterns
The Manifesto lists patterns to avoid, including relying on a single hero threat modeler and overfocusing on adversaries. In practice:
- One security person doing every model while engineers watch. Skills stay with that person.
- Long sessions that drift into debating attacker motives instead of fixing the design.
- Models that live in a slide and never change when the system does.
Measuring whether it worked
Count designs reviewed before build, threats that led to a design change, and how many leads run sessions without help. Avoid counting attendance alone.
Where Safeguard fits
Design decisions meet reality in dependencies, exposed services and policy. Safeguard supports asset discovery, dependency scanning and policies and gates, which can show whether what was built matches what was designed. It does not offer training courses. Free scan: gold.safeguard.sh/scan. See also our 60 minute workshop guide.
Quick check
Do architects need a formal threat modeling method?
Not to start. The four questions are enough for the habit. Add a named method later if the team wants more structure.
How often should a design be revisited?
When it changes in a way that alters data flows, trust boundaries or exposed surfaces, rather than on a fixed calendar.
Sources
- Threat Modeling Manifesto: threatmodelingmanifesto.org
Last reviewed: 19 October 2026.
