Cybersecurity glossary
What is Threat Modeling?
Learn what threat modeling is, how teams identify attack paths before release, and how structured models turn design decisions into practical security work.
Definition
Threat modeling is a structured security practice for identifying likely threats, abuse cases, trust boundaries, and mitigations in a system before attackers can exploit design weaknesses.
Why threat modeling matters
Security defects are cheapest to address while the design is still flexible. Threat modeling gives teams a repeatable way to ask how attackers might cross trust boundaries, misuse features, or turn ordinary workflows into abuse paths.
The value is not the document itself. The value is shared understanding, better engineering decisions, and a backlog of mitigations that reduce risk before vulnerable code reaches production.
What a useful threat model captures
Assets
The data, capabilities, identities, and business processes that need protection.
Trust boundaries
The places where identity, network location, privilege, or data ownership changes.
Abuse paths
Realistic sequences an attacker could use to cause harm, not just isolated bugs.
Mitigations
Design changes, controls, tests, and monitoring that reduce or accept the modeled risk.
How to run threat modeling in practice
Define the scope
Choose the feature, service, workflow, data class, and release decision the model must inform.
Map the design
Draw components, data flows, identities, external dependencies, and trust boundaries.
Identify threats
Use STRIDE, abuse cases, ATT&CK knowledge, or incident history to find credible attack paths.
Prioritize risk
Rank threats by business impact, exposure, attacker effort, and whether existing controls already apply.
Assign mitigations
Turn decisions into backlog items, tests, defaults, logging, or explicit risk acceptance.
Review after change
Refresh the model when architecture, dependencies, permissions, or data flows change.
Threat modeling methods compared
| Method | Best for | Caution |
|---|---|---|
| STRIDE | Systematic review of data flows and trust boundaries | Can become checklist theater if threats are not tied to real abuse paths |
| Abuse cases | Product workflows where attackers misuse intended features | May miss lower-level technical threats without engineering detail |
| Attack trees | Breaking a high-value objective into possible attacker steps | Requires discipline to avoid speculative branches with no decision value |
| Kill chain / ATT&CK mapping | Operational systems where known tactics and detections matter | Maps observed techniques better than early product design assumptions |
Threat modeling checklist
- Name the security decision the model is supposed to support.
- List sensitive assets and the business impact if each is compromised.
- Draw trust boundaries instead of only drawing deployment boxes.
- Include human workflows, admin actions, and support tooling.
- Treat third-party services and CI/CD systems as part of the design.
- Capture assumptions so future changes can invalidate them deliberately.
- Convert mitigations into owned work items with acceptance criteria.
- Revisit the model after incidents, major refactors, or new data exposure.
The practical takeaway
Threat Modeling turns vague security concern into concrete engineering choices. It is most effective when teams model what matters, record why controls were chosen, and keep the output connected to delivery work.
Use it early enough to change the design, and revisit it often enough that the model still describes the system attackers will actually face.
Related security terms
Attack Surface
The exposed paths and entry points that threat models evaluate.
Insecure Design
A weakness category that threat modeling is meant to prevent early.
Secure by Default
A design outcome where safer choices are the normal path.
Code Review
A later checkpoint that can verify mitigations from a threat model.
Vulnerability Management
The operational process that tracks discovered risks to closure.
Frequently asked questions
What is threat modeling in simple terms?
It is a structured conversation about what can go wrong in a design, who could cause it, how likely paths work, and which controls should be built before release.
When should threat modeling happen?
Start during design, revisit before major releases, and update it when architecture, data sensitivity, trust boundaries, or attacker incentives change.
Is threat modeling only for security teams?
No. Product, engineering, operations, and security should participate because useful models depend on real design context and practical mitigation ownership.
What is STRIDE?
STRIDE is a Microsoft threat classification method covering spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
Does a threat model need a diagram?
A diagram is not mandatory, but data flow diagrams, sequence diagrams, and architecture maps make trust boundaries and assumptions easier to challenge.
How is threat modeling different from penetration testing?
Threat modeling reasons about design risk before or during implementation. Penetration testing exercises a running system to find exploitable weaknesses.
What should a completed threat model produce?
It should produce prioritized threats, agreed mitigations, accepted assumptions, owners, and follow-up work that fits into the normal delivery backlog.
References
Explore authoritative guidance and frameworks related to threat modeling.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.