Threat Modeling
Identify security risks in application architecture before they become expensive problems.
Some security problems are bugs. Others are decisions — a trust boundary drawn in the wrong place, a service given more access than it needs, a data flow that crosses a line nobody noticed was there. Those are not found by testing the finished system, because the system is behaving exactly as designed.
Threat modelling examines the design itself. It is a structured conversation about what the system holds, who should reach it, where trust changes hands, and what could go wrong at each of those points — held while the answer is still a diagram rather than a migration.
The cheapest time to move a boundary is before it exists
A design decision made in an afternoon can take quarters to reverse once it is running in production with data in it. That asymmetry is the entire argument for threat modelling: not that design review finds more issues, but that the issues it finds are still cheap to act on.
It also produces something a test report cannot. A threat model is a shared understanding of the system — what matters in it, where the boundaries are, what is assumed. Teams that have one make better security decisions afterwards, without needing to be asked.
How this fits together.
CONCEPTUAL ARCHITECTURE — ASSEMBLES AS YOU READ
What a threat model covers
A design-level review, conducted collaboratively with your team. It describes what we examine, not how to attack a system.
How a threat model runs
- 01MAPUnderstand the architecture as it is, not as documented.
- 02IDENTIFYEstablish assets and trust boundaries.
- 03ANALYZEExplore what could go wrong at each boundary and data flow.
- 04PRIORITIZEAssess which threats matter for this system and this business.
- 05MITIGATEDefine controls and design changes that address them.
- 06VALIDATEReview the resulting design against the threats identified.
When Should You Model Threats?
Output your team can act on.
Which of these apply depends on engagement scope.
Weaknesses identified across the application in scope, with the reasoning behind each.
Reproduction detail so an engineer can confirm a finding rather than take it on trust.
What a finding means for this product, not a generic severity label.
Design-level issues that no single code change will resolve.
Practical direction, including where in the codebase or design the fix belongs.
An order of work that fits how your team actually plans.
Verification that addressed findings no longer reproduce, within the agreed retest scope.
Adjacent parts of the product surface.
Questions we get asked before an engagement.
Early enough that the design can still change — typically once the architecture is understood but before it is fully built. It is also worth revisiting when something significant changes, since a threat model describes a system that no longer exists otherwise.
No. Part of the exercise is establishing how the system actually works, and the gap between the documented architecture and the real one is frequently where the interesting findings are.
People who know how the system really works — usually engineers and architects, ideally with a product perspective in the room. It works best as a working session rather than a review we conduct alone and report back on.
A documented model: assets, trust boundaries, data flows, identified threats and prioritised mitigations. The lasting value is often the shared understanding it produces in the team, which outlives the document.
Explore Threat Modeling
Bring an architecture you are about to build, or one you are about to change significantly. That is where the exercise pays for itself.