A threat model that survives the architecture review
Most threat models are produced once, filed, and never consulted again. A model earns its place when every ranked attack path is attached to an architectural decision someone has to make.
What a useful threat model produces
A threat model is not a diagram and not a spreadsheet of STRIDE categories. It is a short set of ranked attack paths, each one attached to a decision: an architectural mitigation the team will build, a risk the business accepts with a named owner, or an open question with a date attached.
That framing sets a hard test for the exercise. If the session ends and no engineering ticket, design change or recorded acceptance exists, the model has produced documentation rather than security. The Threat Modelling Manifesto puts the same point as a value: a culture of finding and fixing design issues matters more than checkbox compliance.
The reason to insist on this is economic. Design defects are the most expensive class to repair and the least likely to be found by scanners. A missing trust boundary is not a bug in a line of code; it is a property of how the system is arranged, and by the time the arrangement is in production the cost of changing it has usually multiplied.
Start from attacker positions, not a list of threats
Teams often begin by brainstorming threats. This produces long lists and weak prioritisation, because a threat without a position is untestable. “Someone could tamper with the message queue” is only meaningful once you say who, from where, and with what they already hold.
Begin instead by naming the positions the architecture intends to resist:
- an unauthenticated party on the internet;
- an authenticated customer of another tenant;
- a compromised first-party service inside the deployment;
- a developer or operator with legitimate console access;
- a supplier whose code or model your build consumes;
- a person with physical access to a device.
Each position comes with a starting set of credentials, network reachability and knowledge. Attack paths then become derivable rather than imagined: from this position, which boundary can be reached, and what does crossing it yield? MITRE ATT&CK is a useful prompt for techniques once positions are fixed, but it is a vocabulary, not a substitute for the positional analysis.
Be explicit about the positions you are not resisting. A design that assumes a trusted operator is a legitimate design; a design that silently assumes it is a liability, because nobody downstream knows the assumption exists.
Draw the boundaries you actually enforce
The most common finding in an architecture review is not a missing control. It is a boundary that exists on the diagram but not in the deployment. Two services separated by a line on a whiteboard often share a VPC, a service account, a database role and a secrets store.
For every boundary crossing, record three things: what authenticates the caller, what authorises the specific operation, and what the callee would do if the caller were compromised. The third question is the one that exposes phantom boundaries. If a compromised reporting service can read every tenant’s records because authorisation is performed only at the edge, then the boundary between reporting and data is decorative.
Annotate the credential at each crossing as well. Long-lived shared secrets, wildcard database roles and ambient cloud instance identity are where most lateral movement becomes possible, and they are invisible in a component diagram that shows only arrows.
Rank by reachability and consequence, not by severity label
Severity labels imported from a scanner do not survive contact with an architecture discussion, because they describe a vulnerability class rather than this system. Rank each path on two axes instead:
| Axis | What to establish | Evidence that settles it |
|---|---|---|
| Reachability | What must already be true for this path to work? | Network route, held credential, required user action, feature flag state |
| Consequence | What does success give the attacker? | Data classes exposed, actions available, blast radius across tenants |
A path that needs only internet reachability and yields cross-tenant data is the first thing to fix. A path that needs a compromised operator credential and yields a single record is worth recording and not worth redesigning around. Making the reachability conditions explicit also gives the team something testable: each condition becomes an assertion an engineer can try to falsify.
Where a path depends on a weakness class rather than a design property, the CWE Top 25 helps name it precisely enough for a remediation ticket—“missing authorisation” rather than “access control issue”.
Attach every path to a decision
This is the step that distinguishes a model that changes the product from one that does not. Walk the ranked list and force each item into one of three outcomes:
- Architectural mitigation. The design changes: a boundary moves, a credential narrows, a component is split, a dependency is removed. This becomes a design decision record and engineering work.
- Accepted risk. The path is understood and tolerated, with a named owner, a stated reason and a review trigger. Acceptance without an owner is not acceptance; it is deferral.
- Open question. Something material is unknown—how a supplier handles keys, whether a library validates what it claims. This gets an owner and a date, not a placeholder.
Nothing else is allowed. “Monitor” is not an outcome unless someone has said what the detection is, who receives it and what they do; otherwise it is acceptance with extra words. NIST’s Secure Software Development Framework expresses the same discipline in its design practices: threats are identified, mitigations are designed and the analysis is documented as part of the development process rather than alongside it.
Keep the model alive through delivery
A threat model decays for predictable reasons: a new integration appears, a boundary is relaxed under deadline pressure, a dependency changes what it does with data. Rather than scheduling an annual refresh, connect the model to the events that invalidate it.
Useful triggers are a new external interface, a new data class, a change in who may call a service, a new supplier in the build, a change to the deployment topology, and any incident that used a path the model did not contain. Each trigger asks one question: does this change a reachability condition or a consequence in the ranked list?
Keep the artefact small enough to reread. A two-page ranked list with boundary annotations gets consulted during design discussions; a forty-page document does not. CISA’s secure-by-design material makes ownership the point: the burden of security belongs with the organisation building the software, which means the model has to be something that organisation’s engineers actually use.
The measure of the exercise is not whether a document exists. It is whether, six months later, someone can point at a line in the architecture and say which threat-model decision put it there.