Threat modelling with STRIDE
In short: Threat modelling is a structured way to find what could go wrong in a design before attackers do. You draw the system as a data flow diagram, mark trust boundaries, use STRIDE to list threats for each element, then choose and track mitigations.
Why threat model
Threat modelling is a team exercise that looks at a design and asks how it could be attacked or misused. It is cheapest during design, but useful at any time, especially before major changes. The output is a list of threats and agreed mitigations, which feeds requirements, tests and risk registers.
Step 1: draw the system
Use a data flow diagram (DFD) with four kinds of element:
- External entities: users, partner systems, anything you do not control.
- Processes: code that handles data, such as a web app or API.
- Data stores: databases, file shares, queues, caches.
- Data flows: arrows showing data moving, labelled with protocol, such as HTTPS or SQL.
Then draw trust boundaries wherever the level of trust changes: between the internet and your web tier, between the app and the database, between tenants, or between your system and a third party (see security zones and trust boundaries). Threats cluster where flows cross boundaries.
Step 2: apply STRIDE
STRIDE, created at Microsoft, gives six prompts. Walk through each element and each boundary-crossing flow and ask which apply.
| Threat | Example | Typical mitigation |
|---|---|---|
| Spoofing | Attacker logs in with stolen credentials | MFA, mutual TLS, strong session handling |
| Tampering | Order total changed in transit or in the database | TLS, integrity checks, signed data, input validation |
| Repudiation | Admin denies deleting records | Tamper-evident audit logs tied to individual identities |
| Information disclosure | Backup file in a public bucket | Encryption, access control, data minimisation |
| Denial of service | Flood of expensive search queries | Rate limiting, quotas, autoscaling, DDoS protection |
| Elevation of privilege | Normal user calls an admin API | Server-side authorisation checks on every request |
As a rule of thumb, processes can suffer all six, data stores mainly tampering, information disclosure and denial of service, and data flows tampering, disclosure and denial of service.
Step 3 and 4: decide and review
For each threat, choose a response: mitigate with a control, eliminate by removing the feature, transfer to another party, or accept with a recorded owner. Rate threats so effort goes to the biggest risks, using a simple likelihood and impact score or CVSS-style factors. Track each mitigation as a work item and test it.
- Keep the model with the design documents and update it when the architecture changes.
- Turn mitigations into test cases, such as "a normal user calling
/admin/usersgets HTTP 403". - Revisit after incidents: did the model miss the threat?
Other methods exist. PASTA is a risk-centred, seven-stage process; LINDDUN focuses on privacy threats; attack trees break one goal into the paths to reach it. MITRE ATT&CK helps you think about real attacker techniques. STRIDE remains the most common starting point.
Tip: keep sessions short and focused on one feature or flow. A one-hour session with a developer, an architect and a security person often finds more than a long, formal review.
Practice
Which STRIDE category covers a user denying they made a transaction?
Where in a data flow diagram should you look hardest for threats?
Name the four possible responses to a threat.
Key takeaways
- Threat modelling finds design flaws before attackers do.
- Draw a data flow diagram and mark trust boundaries.
- STRIDE: spoofing, tampering, repudiation, disclosure, denial of service, elevation.
- Mitigate, eliminate, transfer or accept each threat, and track it.
- Update the model when the design changes.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.