Participants build a security-relevant view of the system, identify credible threats and misuse paths, choose responses, and check whether the resulting requirements are adequate. It is most useful early in design and should evolve with the system.
The model may cover assets, users, data flows, dependencies, trust boundaries, privileges, assumptions, and potential adversaries. Teams can use methods such as Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege (STRIDE), attack trees, misuse cases, or risk-centered approaches; no single method is correct for every system.
Key points
Core questionsWhat are we building, what can go wrong, what will we do about it, and did we examine the system and responses well enough?
Useful outputsDiagrams or other system models, documented assumptions, prioritized threat scenarios, security requirements, owners, accepted risks, and testable validation criteria.
Working practiceInvolve engineering, operations, product, privacy, safety, and domain stakeholders as relevant, then review the model when architecture, dependencies, data, use, or threats change.
Important limitationA threat model reflects its scope, participants, evidence, and assumptions; it cannot enumerate every future attack. It does not scan running systems, prove implementation quality, or replace code review, security testing, or operational monitoring.