Threat modeling is a structured exercise for analyzing a system, integration, or process before building or changing it, to identify what could go wrong, who would have an interest in it, where an attack would come from, and what to do about it. It is security applied at the design stage, before delivery.
The cheapest vulnerability to fix is one that never exists. Changing an architectural decision on paper costs a meeting; after production, it costs a project.
The window for remediation afterward has also shrunk. The M-Trends 2026, from Google Cloud, estimates that the average time to vulnerability exploitation reached approximately negative seven days, meaning vulnerabilities were exploited before a fix was released.
Which questions does modeling answer?
Whatever the method, threat modeling answers four questions, as proposed by the Threat Modeling Manifesto. What we are building: components, data, flows, access, and trust boundaries, the points where data passes from a trusted environment into an untrusted one. What could go wrong: threats, component by component and flow by flow.
What we will do: mitigate, eliminate, transfer, or accept each significant threat, with justification. And whether the work was done well: review and validation, ideally through testing once the system exists.
The STRIDE method
The most widely used method for identifying what could go wrong is STRIDE, which organizes threats into six categories:
- Spoofing: someone impersonates a legitimate user or system.
- Tampering: someone modifies data in transit or at rest.
- Repudiation: someone performs an action, but there is no record to prove it.
- Information disclosure: data reaches someone who should not see it.
- Denial of service: someone takes the system offline or makes it unusable.
- Elevation of privilege: someone becomes able to do more than they should.
Applying the six categories to each component and flow makes the analysis an exercise that does not depend on someone's memory. Methods more focused on business risk, such as PASTA, begin with business objectives and the attacker's profile.
Who should participate
The method matters less than the people in the room: whoever designed the system, whoever will operate it, and someone with an offensive perspective. Without an attacker's viewpoint, the exercise tends to find only the obvious. For a system or integration, a few working sessions are usually enough.
Fictional example: the integration with excessive access
A fintech plans to integrate its platform with a credit analysis partner. The initial design provides an API key so the partner can query the records of customers applying for credit.
During threat modeling, STRIDE reveals that the key provides access to the entire customer database and that the partner's queries are not logged. If the key leaks, anyone who has it can read every customer's data without leaving a trace. The redesign limits queries to the customer who granted authorization, uses a narrowly scoped, short-lived key, logs every query, and alerts on unusual volumes.
From system to business
The same logic applies to the entire company: map threat actors with an interest in the business against the events they could cause and critical assets to develop risk scenarios with likelihood and impact. Threat modeling is recommended before building systems that handle sensitive data, integrating with third parties, making significant architectural changes, and deploying AI systems that access data or perform actions.
Threat modeling does not replace pentesting: it prevents design flaws, while pentesting finds those that slipped through, including implementation flaws.
Risk and threat modeling at Vultus
Vultus uses threat modeling to build the executive risk assessment for the security master plan and prioritized continuity plan scenarios. Explore Vultus risk and threat modeling.
