Threat Modelling Studio
A guided threat-modelling workspace that turns system purpose, exposure, data sensitivity and trust boundaries into an initial risk view and prioritised threat-register actions.
Who this Lab is for
Designed for
- Security and platform engineers
- Service teams preparing a design review
- Architects defining trust boundaries
Use it when
- Designing a new service or material data flow
- Changing authentication, exposure or tenancy boundaries
- Preparing focused questions for a security review
A complete run, step by step
Describe the system
State the business purpose, principal assets and important data without relying on an architecture diagram alone.
Classify exposure
Identify how untrusted users reach the service and what protection sits in front of it.
Classify data
Use the highest sensitivity of credentials, personal data or business information processed.
Count trust boundaries
Include identity, network, tenant, organisational and third-party boundaries where assumptions change.
What you will need
Prepare the following information before starting. Use measured evidence where possible; defaults are examples and should not be treated as recommendations.
System under review
Name the service and its business purpose.
Internet exposure
How directly can untrusted clients reach it?
Choices: Directly exposed · Via gateway / WAF · Private network only
Data sensitivity
Highest classification processed.
Choices: Restricted / credentials · Confidential · Internal or public
Trust boundaries crossed
Networks, identities, tenants and third parties.
What the result tells you
Your report includes
- An initial exposure and sensitivity score
- Priority threat categories to investigate
- Recommended next controls and evidence
How it is determined
The Lab combines exposure, data sensitivity and boundary count to prioritise investigation. It uses these signals to recommend areas such as identity, spoofing, data disclosure, boundary validation and abuse resistance.
Exposure, sensitivity and boundary count prioritise review only; they do not identify vulnerabilities or calculate formal risk.
Model assumptions
- • The highest data classification is selected.
- • All material trust boundaries are counted.
- • Existing control effectiveness is not included in inherent risk.
Customer identity API
Situation
An internet-reachable API processes authentication tokens and profile data through a gateway across three trust boundaries.
Result
The result prioritises credential handling, boundary validation, authorisation and abuse controls for detailed review.
Use the result with engineering judgement
- It produces an initial register, not a complete threat model.
- It does not test the implementation or verify controls.
- High-risk or regulated systems still require qualified security review.
Questions before you begin
Do I need a data-flow diagram?
You can start without one, but a data-flow diagram makes trust boundaries and data stores substantially easier to review.
Is the score a vulnerability rating?
No. It is a prioritisation signal based on context, not evidence that a vulnerability exists.
When should the model be updated?
Update it when exposure, data, identity, dependencies or trust boundaries materially change.
Threat Model is under review
This legacy judgement-based Lab has been retired. Existing saved reports remain available, but new execution is disabled.
Open deterministic utilities