The short answer
Threat modelling is a structured way of identifying how a system could be attacked or misused and deciding what to do about it. Teams map how data moves, mark the trust boundaries, list threats using a method such as STRIDE, then choose mitigations, ideally at the design stage before any code is written.
On this page
Threat modelling (threat modeling in US English) is a structured way of working out how a system could be attacked or misused and what you will do about it. It is usually done before code is written, so problems are fixed in the design rather than found later in a penetration test. Adam Shostack’s widely used framing reduces it to four questions: 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?
What is threat modelling?
Threat modelling is a design-level risk analysis for one specific system, such as an application, API, cloud environment, payment flow or AI agent. It asks where an attacker could break the assumptions the design relies on. The result, a threat model, is a short document: a diagram of the system, the threats that matter and what will be done about each.
What are the five steps of threat modelling?
The threat modelling process usually runs in five steps, which answer Shostack’s four questions in order:
| Step | What you do | Question it answers |
|---|---|---|
| 1. Scope the system | Agree which system, feature or change is in scope, what it protects and who uses it | What are we working on? |
| 2. Draw a data flow diagram | Map users, external systems, processes, data stores, the flows between them and the trust boundaries | What are we working on? |
| 3. Identify threats | Walk each element and boundary with STRIDE, or build attack trees for the outcomes you most want to prevent | What can go wrong? |
| 4. Decide mitigations | Mitigate, remove the feature, transfer or accept each credible threat, and record an owner and a date | What are we going to do about it? |
| 5. Validate | Check through code review and testing that the mitigations work, and update the model when the design changes | Did we do a good enough job? |
Step 2 is where most of the value appears. A trust boundary is any point where data crosses between zones of different trust, such as from the internet into your application or from your application into a payment provider, and drawing those boundaries often exposes the biggest design flaws before anyone looks for threats.
What is STRIDE?
STRIDE is a mnemonic for six threat categories, developed at Microsoft in the late 1990s. Each maps to a security property, which makes the STRIDE threat model a practical checklist for a data flow diagram.
| Threat | What it means | Property it breaks | Typical mitigation |
|---|---|---|---|
| Spoofing | Pretending to be another user or system | Authentication | Strong authentication, mutual TLS between services |
| Tampering | Changing data or code without permission | Integrity | Signing and integrity checks, access controls |
| Repudiation | Denying an action with no way to prove otherwise | Non-repudiation | Tamper-evident audit logs |
| Information disclosure | Exposing data to people who should not see it | Confidentiality | Encryption, least privilege, data minimisation |
| Denial of service | Making the system unavailable | Availability | Rate limiting, quotas, resilient design |
| Elevation of privilege | Gaining rights you should not have | Authorisation | Server-side authorisation checks on every request |
STRIDE threat model example: a login API
Take a simple login API: a client sends a username and password, and the API returns a session token. Walking it with STRIDE takes a few minutes and produces a concrete list:
| STRIDE category | Threat to the login API | Mitigation to build and test |
|---|---|---|
| Spoofing | Credential stuffing with passwords leaked from other sites | Rate limiting, checks against breached passwords, multi-factor authentication |
| Tampering | A user edits the session token to change their role or account ID | Signed tokens validated on the server, with unsigned or weakly signed tokens rejected |
| Repudiation | No record of who signed in, from where, or of repeated failures | Log successful and failed sign-ins with time, account and source to tamper-evident storage |
| Information disclosure | Different error messages reveal which usernames exist | One generic error for any failed sign-in, and tokens kept out of URLs and logs |
| Denial of service | A flood of requests, or deliberate lockouts of real users | Rate limits per account and per source, with progressive delays rather than permanent lockout |
| Elevation of privilege | The API trusts a role sent by the client | Roles read from the identity store on the server and checked on every request |
Each row becomes a design requirement for developers and a test case for the web application penetration test later.
What other threat modelling methods are there?
- Attack trees put the attacker’s goal at the root, such as “obtain card data”, and branch out into the ways of reaching it, showing which control blocks the most paths.
- PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centred method that ties threats to business impact.
- LINDDUN applies the same idea to privacy threats.
- MITRE ATT&CK is not a method but a catalogue of real attacker techniques, useful for keeping threat scenarios realistic.
OWASP’s threat modelling overview explains the four-question framework and where STRIDE and attack trees fit. Use the lightest method your team will keep up to date.
Which threat modelling tools are used?
A whiteboard and a shared diagram are enough to start, and many teams never need more. When models need to be repeatable or kept with the code, these free tools are widely used:
| Tool | What it is | Good for |
|---|---|---|
| Microsoft Threat Modeling Tool | A free Windows desktop application from Microsoft | Drawing data flow diagrams and generating a STRIDE threat list from them automatically |
| OWASP Threat Dragon | A free, open-source tool that runs in a browser or on the desktop | Diagrams and threats stored as files, so models can sit in the same repository as the code |
| pytm | An OWASP open-source Python framework | Threat modeling as code: describe the system in Python and generate diagrams and threats as part of a build |
Commercial platforms add libraries of threats, integration with ticketing systems and reporting across many applications. Whichever tool you choose, the value comes from the conversation between the people who know the system, not from the software.
When should you do threat modelling?
As early as possible, and again whenever the design changes:
- At the design stage, when changing the architecture is cheap.
- Before a penetration test, so a web application penetration test targets your trust boundaries, roles and abuse cases rather than a generic checklist.
- Before a code review, so a secure source code review concentrates on the code that enforces the model’s mitigations, such as authorisation checks.
- For AI agents and LLM features, where untrusted content can steer a model with real permissions. Map each tool the agent can call, the data it can reach, prompt injection routes and actions taken without human approval, then check them with agentic AI security testing.
- For payment software. PCI DSS Requirement 6 requires bespoke and custom software to be developed securely, with security considered at every lifecycle stage (6.2.1), and reviewed before release (6.2.3). It does not name threat modelling, but a threat model shows the design stage was covered. ISO 27001:2022 Annex A 8.25 (secure development life cycle) and 8.27 (secure system architecture and engineering principles) point the same way.
What does a threat model produce?
A useful threat model is short and current. It usually contains:
| Output | What it is used for |
|---|---|
| Data flow diagram with trust boundaries | A shared picture of the system for developers, testers and auditors |
| Threat list | Each credible threat, where it applies and its risk rating |
| Mitigations and owners | The control for each threat, who builds it and by when |
| Accepted risks | Threats deliberately left unmitigated, with the reason and a review date |
| Abuse cases and test cases | What code review and penetration testing should verify |
Why Sovereign Secure
A threat model is only a prediction until it is tested. Sovereign Secure tests web applications, APIs, cloud environments, source code and AI/LLM systems; share your threat model at scoping and we will aim at the boundaries and abuse cases that concern you most. We are a PCI SSC-approved QSA company and ISO 27001 certified. More terms are in the cyber security glossary.
Next step: request a penetration testing quote and include any threat model or design documents with your scope.
Your next step
- Scope your testChoose your test types and asset counts online to scope your penetration test.Scope your test
- Pen testing cost guideUK day rates, price ranges by test type and what drives the cost.Read the cost guide
- Talk to a testerTell us what you need tested. We aim to reply within one working day.Talk to a tester
Last reviewed October 2026 by the Sovereign Secure assessment team.
