A threat model is a structured representation of the security risks to a system: what assets it holds, who might attack them, through which paths, and which controls reduce the danger. Among the security fundamentals of cybersecurity, it is the reasoning that connects abstract goals such as the CIA triad to concrete design decisions, so that defenses are chosen for the threats that actually matter instead of by habit.
The term covers both the activity of threat modeling and its result, usually a diagram plus a list of threats, ratings and mitigations. A threat model is never finished: it is revised whenever the architecture, the data handled or the attackers’ capabilities change.
The questions a threat model answers
Most methods reduce threat modeling to four core questions: what is being built, what can go wrong, what will be done about it, and whether the analysis was good enough. Answering them in order prevents the common failure of listing threats without ever deciding on controls.
| Element | Question answered | Typical content |
|---|---|---|
| Assets | What must be protected | Customer data, credentials, availability of a service |
| Threat actors | Who could cause harm | Criminal groups, insiders, automated bots, nation states |
| Trust boundaries | Where privilege or control changes | Internet to web tier, application to database |
| Threats | What can go wrong | Spoofed identity, data tampering, denial of service |
| Mitigations | What reduces each threat | Authentication, encryption, rate limiting, logging |
| Assumptions | What is taken as given | The cloud provider isolates tenants correctly |
Trust boundaries deserve particular attention, because most serious threats appear where data crosses from a less trusted zone into a more trusted one. The set of such entry points forms the attack surface, and a good threat model makes it explicit.
How threat modeling is carried out
A practical threat modeling session follows a repeatable sequence and usually takes from one hour for a small feature to several days for a complex platform.
- Define scope and security objectives, including which assets matter and any regulatory requirements.
- Draw a data flow diagram showing processes, data stores, external entities, flows and trust boundaries.
- Identify threats systematically for each element, often with a checklist such as STRIDE.
- Rate the risks by likelihood and impact so that effort goes to the worst problems first.
- Decide on responses: mitigate, transfer, accept with justification, or eliminate the feature.
- Validate and track mitigations as engineering tasks, and revisit the model after major changes.
The best results come from mixed teams: developers who know how the system really works, security specialists who know attack techniques, and operations staff who know the deployment. A model produced by a security team alone tends to miss real data flows.
Common threat modeling methods
Several established methods structure the work. They differ mainly in what they put at the center: system components, attackers, risks to the business or privacy.
| Method | Focus | Best suited for |
|---|---|---|
| STRIDE | Six threat categories per system element | Software and architecture reviews |
| PASTA | Seven-stage, risk-centric process | Business-critical applications |
| Attack trees | Goal decomposed into attacker steps | Analyzing one high-value target |
| LINDDUN | Privacy threat categories | Systems processing personal data |
| MITRE ATT&CK mapping | Known adversary techniques | Detection and defensive coverage planning |
STRIDE is the most common starting point. Its categories map neatly onto security properties, which makes it easy to check whether each element of a diagram has been considered.
| Category | Violated property | Typical mitigation |
|---|---|---|
| Spoofing | Authentication | Strong authentication, mutual TLS |
| Tampering | Integrity | Signatures, hashes, access control |
| Repudiation | Non-repudiation | Tamper-evident audit logs |
| Information disclosure | Confidentiality | Encryption, least privilege |
| Denial of service | Availability | Rate limits, redundancy, quotas |
| Elevation of privilege | Authorization | Input validation, sandboxing, least privilege |
Threat models in relation to other security concepts
A threat model is the analytical core that gives other security fundamentals their purpose. The CIA triad defines what security means, while the threat model determines which violations are plausible for a given system and how much protection each deserves.
Design principles such as least privilege and zero trust are typical outputs of threat modeling rather than substitutes for it. A risk assessment, by comparison, is usually broader and organizational, whereas a threat model is tied to a specific system or feature.
Pitfalls that weaken threat models
Threat models fail less often from wrong techniques than from poor scope and follow-through. The table lists frequent weaknesses and remedies.
| Weakness | Consequence | Remedy |
|---|---|---|
| Model done once and filed | Outdated after the next release | Review on every significant design change |
| Diagram does not match reality | Real flows remain unanalyzed | Build it with the engineers who run the system |
| Only external attackers considered | Insider and supply chain risks missed | Include insiders, vendors and dependencies |
| Threats listed without decisions | No change in the product | Track each mitigation as a work item |
| Unstated assumptions | Hidden single points of failure | Write assumptions down and test them |
Another trap is aiming for completeness. No threat model lists every conceivable attack; its value lies in finding the most consequential threats early, while changes are still cheap.
Stripped to the essentials
A threat model is thinking like a burglar before building the house. The team asks what is valuable, who would want it, how they might get in, and which locks, alarms or walls would stop them.
Doing this on paper first is far cheaper than discovering the weak spots after a break-in. The main benefit is spending security effort where the real risks are rather than everywhere at once.
Where it is applied
A health clinic plans a patient portal where patients view lab results and message their doctors. Before development, the architect, two developers and a security engineer spend an afternoon drawing the data flows: the browser, an API gateway, the portal application, the records database and an email notification service, with trust boundaries at the internet edge and the database.
Walking through STRIDE, the team identifies that notification emails could disclose lab results if they contained details, that account recovery by email could be spoofed, and that missing audit logs would make disputes impossible to resolve. The resulting decisions are concrete: emails contain only a link, recovery requires a second factor, and every record view is logged. These three changes cost days at design time instead of weeks after launch.