Most organisations threat model a handful of flagship systems and leave everything else unreviewed, because the work depends on a few experts with a whiteboard. Threat modelling tools promise to change that by giving every team a repeatable way to describe a system, generate likely threats and track the mitigations that follow. They range from diagram editors with threat libraries, to "threat model as code" approaches that live in the repository, to products that derive models from cloud and infrastructure definitions, and increasingly to AI assistants that draft threats from design documents. This vendor-neutral buyer's guide helps application security leads, architects and engineering managers decide which approach fits, what to test and what to avoid. The method itself is covered in the Threat Modelling Guide; this page is about buying tooling for it.
Key takeaways
- Buy for the process you will actually run. The Threat Modeling Manifesto values people and collaboration over processes, methodologies and tools. A tool should make the four questions faster to answer, not replace the conversation.
- Choose the input model first. Diagram-driven, code-driven and infrastructure-derived tools suit different teams. The wrong input model is the main reason tools sit unused.
- Threat libraries are the product. The quality, currency and editability of the rules that turn a model into threats matters more than the diagram canvas.
- Mitigations must leave the tool. OWASP guidance is to turn agreed mitigations into actionable security requirements; insist on two-way links to your backlog.
- Treat AI drafting as a junior reviewer. AI-generated threats can be plausible and wrong, which is the misinformation risk OWASP lists as LLM09:2025. Require human sign-off and keep design data inside agreed boundaries.
Define requirements
- Scale and coverage target: how many applications or services should have a current model in 12 months, and how many people will create them (a central team, security champions or every squad).
- Methodologies: which prompts you need. The OWASP Threat Modeling Cheat Sheet uses STRIDE for technical designs, LINDDUN for privacy harms, PASTA for business-impact analysis and attack trees or kill chains for specific adversary paths. See the Privacy Threat Modelling with LINDDUN Guide.
- System types: classic web applications, cloud-native and serverless workloads, APIs, mobile, OT, and AI systems such as agents and retrieval pipelines. Cloud-native estates bring dynamic infrastructure and ephemeral components that static diagrams struggle to track. See AI Agent Threat Modelling Guide and Threat Modelling RAG Systems.
- Compliance drivers: NIST SP 800-53 SA-11(2) Threat Modeling and Vulnerability Analyses, SA-8 security engineering principles, SA-17 developer security architecture, and the NIST SSDF practice PW.1.2 on keeping risk response decisions current. Decide which evidence auditors will ask for.
- Toolchain: source control, issue tracker, architecture repository, CI/CD, cloud accounts and infrastructure as code that the tool must read from or write to.
- Data sensitivity: a threat model is a map of your weaknesses. Decide where models may be stored and whether design content may be sent to an external AI service.
Capability areas
| Approach | How models are created | Strengths | Watch for |
|---|---|---|---|
| Diagram-driven | Data flow diagrams with processes, data stores, external entities, flows and trust boundaries drawn on a canvas | Accessible to architects and non-specialists; good for workshops | Diagrams drift from reality; hard to review in pull requests |
| Threat model as code | Model written in a text or code format kept beside the application source | Versioned, diffable, reviewable in the normal code review flow; runs in CI | Needs developer buy-in; harder for non-engineers to contribute |
| Infrastructure-derived | Model generated from infrastructure as code, cloud configuration or architecture metadata | Stays closer to deployed reality; covers many services quickly | Sees infrastructure, not business logic or abuse cases |
| Questionnaire-driven | Teams answer structured questions about the system; rules map answers to threats and requirements | Scales to many low-risk applications with little training | Shallow for complex designs; answers can be guessed |
| AI-assisted | A language model drafts components, threats and mitigations from design documents, diagrams or code | Fast first draft; lowers the blank-page barrier | Plausible but wrong threats; data handling; unrepeatable output |
Most mature programmes combine two approaches, for example questionnaires to triage the portfolio and diagram or code models for high-risk systems. Beyond the input model, compare these functions:
- Threat and mitigation libraries: coverage of STRIDE and other prompts, mappings to CAPEC, ATT&CK, OWASP ASVS requirements and cloud service specifics; the ability to write and version your own rules.
- Risk rating: configurable likelihood and impact scoring, with the accept, transfer, mitigate or eliminate decision and residual risk owner recorded per threat.
- Workflow: review and approval states, model versioning, change triggers when the design changes, and re-review reminders.
- Integrations: two-way sync with issue trackers, links from mitigations to tests, import of existing diagrams, and an API for reporting.
- Reporting: portfolio coverage, open high-risk threats, model age and evidence exports for audit.
Evaluation criteria
| Criterion | What to test | Evidence to request | Suggested weight |
|---|---|---|---|
| Fit with how teams work | A squad models a real service in its own workflow without security staff driving | Time to first model; participant feedback | 20% |
| Threat library quality | Generated threats for a known system compared with an expert model | Library content list, update cadence, framework mappings | 20% |
| Mitigation tracking | Mitigations become tickets and their status flows back | Live two-way integration with your tracker | 15% |
| Keeping models current | Change the design or infrastructure and see what the tool flags | Change detection and versioning demonstration | 15% |
| Custom rules | Add an internal standard, such as a rule for service account credentials, and see it fire | Rule authoring documentation; versioning of rules | 10% |
| AI controls | Repeat the same AI draft twice; check citations to rules; check data residency | Model provider, data retention and training terms; human approval step | 10% |
| Reporting and audit evidence | Produce coverage and residual risk reports for a portfolio | Sample reports mapped to SA-11(2) or your SDLC policy | 5% |
| Product security | Roles, SSO, export controls, API tokens | Security attestation; access model for model data | 5% |
Weights are a starting point; shift weight to AI controls if design documents are sensitive, or to integrations if engineering adoption is the main risk. Check that the tool's library treats non-human identities seriously: service accounts, API keys and workload tokens crossing trust boundaries are among the most common real findings, and a library that only knows about user logins will miss them. See the Threat Model Template for a baseline to compare output against.
Questions to ask vendors
- Where do your threat rules come from, who maintains them, how often are they updated, and can we see the full rule set before purchase?
- Can we write, test and version our own rules and mitigations, and do they survive product upgrades?
- How does a model stay current when the code, infrastructure or architecture changes, and what triggers a re-review?
- Show the round trip: a threat becomes a ticket in our tracker, the ticket closes, and the threat status updates.
- Can models be stored and edited as text in our repositories, and imported or exported in an open format?
- For AI features: which model provider is used, is our design data retained or used for training, can we run it in our region or tenant, and how do you stop invented threats reaching a final report?
- How are privacy threats and AI system threats handled, not just STRIDE for web applications?
- What happens to our models and history if we leave?
Red flags
- A fixed threat library you cannot inspect or extend.
- Generated threat lists of hundreds of generic items per model, with no ranking, which teams learn to ignore.
- Mitigations tracked only inside the tool, with no link to the backlog or to tests.
- AI output presented as final, with no review state, provenance or way to reproduce it.
- Diagrams stored in a proprietary format with no export, which locks in years of security knowledge.
- Pricing per model or per diagram that punishes the broad coverage you are buying the tool for.
Proof of concept
- Pick three systems: one with an existing expert threat model, one cloud-native service and one AI or agent workflow.
- Have the owning teams build models with minimal vendor help, and record time and friction.
- Compare generated threats against the expert model: count true positives, misses and noise.
- Add one custom rule from your own standards and confirm it fires on the right systems.
- Push mitigations to your tracker, close one, and check status flows back.
- Change the design of one system and confirm the tool flags the affected threats.
- If AI features are in scope, run the same prompt twice, review accuracy, and confirm data handling against your policy.
How NHI Mgmt Group can help
We provide independent application security and identity advisory, including threat modelling programme design and tool evaluation. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Threat Modelling Guide · Threat Model Template · AI Agent Threat Modelling Guide · Privacy Threat Modelling with LINDDUN Guide