Threat modeling is a structured way to find, before you build, how a system could be attacked — and define the controls that prevent it. We map the system's assets, entry points and trust boundaries onto a data-flow diagram, then work systematically through the threats using STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), producing a prioritised list of threats and the mitigations for each. It finds design-level flaws at the point they are cheapest to fix — in the design, not after deployment. Threat modeling early and penetration testing before launch is the pairing that catches both design and implementation flaws. Where a business-risk-driven approach suits, we can use PASTA.
// 01 What is threat modeling?
Threat modeling is the discipline of thinking like an attacker about a system's design, on purpose and systematically, before the system is built or while it is being built. Instead of waiting for a finished product to test, it asks the question early: given what this system does, what it holds, and how data flows through it, how could someone attack it — and what would stop them? The answer is a structured model of the threats and the controls that address them, produced at the stage where changing the architecture costs a conversation rather than a re-build.
The economic case is compelling. A design flaw caught in a threat-modeling session is a whiteboard edit; the same flaw discovered by a penetration test after launch is a re-architecture, and discovered by an attacker is a breach. Threat modeling moves security decisions to the cheapest possible point in the lifecycle.
// 02 Threat modeling vs penetration testing
They are complementary halves of application security — one looks at the design, the other at the build.
| Aspect | Threat modeling | Penetration testing |
|---|---|---|
| When | Design / build stage | After the system exists |
| Looks at | The design & architecture | The running implementation |
| Finds | Design-level flaws proactively | Exploitable implementation flaws |
| Cost to fix findings | Low — still on the whiteboard | Higher — already built |
| Best | Together — model early, test before launch | |
// 03 The STRIDE method
We primarily use STRIDE, a proven and repeatable framework that ensures no category of threat is overlooked. Applied to a data-flow diagram of the system, each element is examined against the six threat types:
S — Spoofing: pretending to be someone or something else — countered by authentication.
T — Tampering: unauthorised modification of data or code — countered by integrity controls.
R — Repudiation: denying an action was performed — countered by logging and non-repudiation.
I — Information disclosure: exposing data to those who shouldn't see it — countered by confidentiality controls.
D — Denial of service: degrading or denying availability — countered by resilience and rate limiting.
E — Elevation of privilege: gaining capabilities beyond those granted — countered by authorisation.
Where a more business- and risk-driven approach fits the engagement, we can use PASTA (the Process for Attack Simulation and Threat Analysis) instead. The method is chosen to fit the system and team, but the goal is always systematic analysis rather than ad-hoc brainstorming.
// 04 How we run it
Understand the system
Work with your architects to map assets, entry points, data flows and trust boundaries into a diagram.
Identify threats
Apply STRIDE systematically to each element, enumerating how it could be attacked.
Prioritise
Rank the threats by likelihood and impact, focusing effort on what matters.
Define mitigations
Specify the controls that address each significant threat, integrated into the design.
Document & hand over
A clear threat model your team can act on and revisit as the system evolves.
// 05 When to threat model
Earlier is always better. The ideal time is during design, before code is written, when the architecture is still fluid — but threat modeling also pays off whenever you add a significant new feature, integrate a new system, or make a major architectural change. It is a natural part of a secure development lifecycle, and its output feeds directly into later assurance: the threats you identify define what a penetration test should focus on, so the two reinforce each other. For teams building products with real security requirements — and for anyone whose launch depends on getting security right — threat modeling early is the highest-leverage security activity available.
// 06 Frequently asked questions
What is threat modeling?
A structured process to identify how a system could be attacked, before it's built — mapping assets and data flows, applying STRIDE, and defining mitigating controls.
How is it different from a pentest?
A pentest attacks a system that exists; threat modeling reasons about a system's design before or during build. Proactive vs reactive — and complementary.
What methodology?
Primarily STRIDE applied to a data-flow diagram; PASTA where a business-risk-driven approach fits.
When should it be done?
As early as possible — during design, and for significant new features or architectural changes. Model early, test before launch.