# Threat Modeling

> Threat modeling is a structured analysis of a system's design that identifies assets, trust boundaries, possible attackers and the threats they pose, and derives countermeasures and test cases. It answers four questions: what are we building, what can go wrong, what do we do about it, did we do a good job. Methods such as STRIDE and attack trees give it structure; in automotive the formalised variant is the TARA of ISO/SAE 21434.

Threat modeling is the structured search for what can go wrong in a system before it is built. The four questions, STRIDE and attack trees, and how it feeds a pentest.

Source: https://zyberum.com/glossary/threat-modeling · Updated: 2026-10-07

## What is threat modeling?

Threat modeling is the practice of looking at a system from the attacker's side before the attacker does. The Threat Modeling Manifesto summarises it as four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?

The working material is a model of the system, usually a data flow diagram with processes, data stores, external entities, data flows and trust boundaries. For every element and every boundary you ask what an attacker could do. STRIDE gives six categories to check: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Attack trees take one attacker goal and break it down into the steps and alternatives that reach it. The output is a list of threats with their severity, the countermeasures you decided on, and the open items that become requirements and test cases.

## Where is it defined?

There is no single standard; several bodies describe the practice. OWASP maintains the Threat Modeling Cheat Sheet and the community page with methods and tools. Microsoft documents STRIDE and its Threat Modeling Tool. The Threat Modeling Manifesto (2020) records the values and principles agreed by practitioners. In regulated domains the practice is formalised: ISO/SAE 21434 Clause 15 turns it into the TARA with fixed rating scales for road vehicles; IEC 62443-3-2 requires a risk assessment per zone and conduit for industrial systems; the Cyber Resilience Act requires in Article 13 that manufacturers undertake a cybersecurity risk assessment and keep it as part of the technical documentation.

## What it means in practice

A threat model pays off twice. During design it removes whole classes of findings at the cost of a whiteboard session: keys that should never have been on the device, an admin interface that should never have faced the network, a trust relationship between two ECUs that nobody questioned. Before a penetration test it becomes the test plan: the tester attacks the paths the model considers critical first, and checks whether the countermeasures the model claims actually exist.

In our ECU and IoT projects the second use is the common one. For an infotainment platform the model listed the TEE, the kernel drivers reachable from unprivileged apps, DoIP and SOME/IP as the critical boundaries, and the fuzzing campaign followed that list. For an ESP32 communication module the model identified the shared MQTT credential as a single point of failure for the entire fleet, before any test had run. The best threat models we see are short, drawn by the people who built the system, and updated when the design changes.

## Common misunderstandings

Threat modeling is not a tool run and not a compliance document. A generated list of 300 generic threats is less useful than 20 specific ones with named owners. It is also not finished when the list exists: the "did we do a good job" question needs verification, which is where code review, fuzzing and penetration testing come in. And it does not replace them. A model says what should be true about the system; a test shows whether it is.

## FAQ

**When should we do threat modeling?**

As early as there is an architecture to draw, and again whenever it changes materially: a new interface, a new trust boundary, a new deployment model. A threat model made after the product ships still has value as the test plan for a penetration test, but the cheap fixes (not storing the key there, not exposing that port) are gone by then.

**Which method should we use: STRIDE, PASTA, attack trees?**

The method matters less than doing it with the right people and a precise diagram. STRIDE is a good checklist per data flow for software systems. Attack trees are better for showing how several weaknesses combine, which is what matters in embedded products. For vehicles ISO/SAE 21434 prescribes the TARA structure. We usually combine a data flow diagram, STRIDE per boundary and attack trees for the top risks.

**Do you need source code or the hardware for a threat model?**

No. A threat model works on the design: architecture diagrams, interface descriptions, deployment and the list of assets. Code and hardware come in when the threat model is verified, in a code review or a penetration test. That is also why a threat model is a good first step before any testing: it tells the tester where to spend the time.

## Sources

- [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html)
- [OWASP Community: Threat Modeling](https://owasp.org/www-community/Threat_Modeling)
- [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/)
- [Microsoft: Threats in the Threat Modeling Tool (STRIDE)](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats)

## Related

- [TARA (Threat Analysis and Risk Assessment)](https://zyberum.com/glossary/tara)
- [Attack Surface](https://zyberum.com/glossary/attack-surface)
- [Penetration test](https://zyberum.com/glossary/penetration-test)
- [Secure Coding in Embedded C: Five Bugs We Keep Finding](https://zyberum.com/insights/secure-coding-embedded-c)
- [Secure code from the first commit.](https://zyberum.com/secure-development)

---
Zyberum GmbH. Canonical page: https://zyberum.com/glossary/threat-modeling