You can run a useful threat modeling workshop in 60 minutes by answering four questions: what are we working on, what can go wrong, what will we do about it, and did we do a good job. Draw one data flow diagram, walk STRIDE prompts across it, and leave with a short list of owned actions.
The four questions
The OWASP Threat Modeling Cheat Sheet, citing the Threat Modeling Manifesto, frames the work around these four questions and maps them to four steps: system modeling, threat identification and ranking, response and mitigations, and review and validation.
Roles and prep
Bring a facilitator, a scribe, and two or three engineers who know the feature. Pick a single feature, such as "password reset" or "file upload," not the whole product. Ask someone to bring the architecture as it actually runs.
Agenda
0 to 15: Draw it. The cheat sheet says the model is most often a data flow diagram showing data flows, trust boundaries, data stores and external entities. Draw those on a whiteboard. Mark where data crosses a trust boundary, because that is where most threats live.
15 to 40: What can go wrong. Walk each element and boundary with STRIDE. Microsoft's description of the model gives six categories:
- Spoofing: using another user's authentication information.
- Tampering: malicious modification of data, at rest or in transit.
- Repudiation: users denying an action when nothing can prove otherwise.
- Information disclosure: exposure to people who should not have access.
- Denial of service: making a service unavailable to valid users.
- Elevation of privilege: an unprivileged user gaining privileged access.
Ask one STRIDE question per element, and write each threat as a sentence: "An attacker could do X because Y."
40 to 52: What will we do. Rank threats by likelihood and impact, along with effort to fix. The cheat sheet lists four responses: mitigate, eliminate, transfer or accept. Pick one for each of the top items.
52 to 60: Did we do a good job. Read back the list. Ask what is missing, and whether each mitigation can be tested.
Outputs to capture
- The diagram, photographed or exported
- A list of threats, each with a response and an owner
- Two or three new tickets or test cases
- A date to revisit when the design changes
Common failure modes
The session drifts into design debate. The facilitator should park it. The group lists only exotic attacks, so push for dull ones such as a missing check. Nobody owns the actions, so assign names before the end.
Quick check
Do we need a security expert in the room?
It helps, but the people who know the feature matter more. A facilitator who knows the method can guide engineers through it.
Sources
Last reviewed: 19 October 2026.
