Threat Modeling Insider (NO INDEX)

Threat Modeling Insider - June 1 2026 - Toreon

Jordan Hardy — Mon, 01 Jun 2026 22:00:00 GMT

53rd Edition – June 2026

Welcome!

Welcome to this month’s edition of Threat Modeling Insider!

In this issue, Amir Kavousian from DevArmor explains why threat modelers need to focus less on static documents and more on code.

He breaks down how policies, rules, tests, and fitness functions can make threat models truly live within the systems they describe.

Next over on the Toreon Blog, Sebastien Deleersnyder expands on the proposed ENISA draft for a Security-by-Design playbook, sharing key insights from our OWASP community input.

We also have plenty of other actionable insights for you, including a core threat modeling lesson from BIML, the story behind a $10,000 iPhone heist, and a practical tip on how to better target your threat models.

Settle in and let’s get started!

Read our previous newsletters

Welcome!

Welcome to this month’s edition of Threat Modeling Insider!

In this issue, Amir Kavousian from DevArmor explains why threat modelers need to focus less on static documents and more on code.

He breaks down how policies, rules, tests, and fitness functions can make threat models truly live within the systems they describe.

Next over on the Toreon Blog, Sebastien Deleersnyder expands on the proposed ENISA draft for a Security-by-Design playbook, sharing key insights from our OWASP community input.

Settle in and let’s get started!

Read our previous newsletters

In this edition

Guest Article
From findings to guardrails: Closing the threat model enforcement gap

Toreon Blog
ENISA’s secure by design playbook: Good start, hard questions

Curated content
No security meter for AI

Curated Content
How easy is it to steal $10,000 from a locked phone?

Tips & tricks
Consider realistic attacker personas

Training update
An update on our training sessions.

Guest Article

From Findings to Guardrails:

Closing the Threat Model Enforcement Gap

What Is The Enforcement Gap

Here is a scene most security practitioners will recognize: a cross-functional team spends two hours in a room with a whiteboard. They map data flows, identify trust boundaries, brainstorm threats using STRIDE, and walk out with a sense of accomplishment. The resulting threat model (a PDF, a Confluence page, maybe an export from a tool) gets filed somewhere reasonable. And then nothing happens.

The threats identified don’t become work tickets with acceptance criteria. The mitigations discussed don’t become policy gates in CI/CD. The architectural constraints agreed upon don’t become linter rules that gate a bad build. Six months later, a penetration test discovers the exact vulnerability the team identified on that whiteboard.

This is what we call “the enforcement gap”: the space between producing a threat model and operationalizing it as guardrails that live in developer workflows. And in my experience building security tooling for engineering teams, it is where the vast majority of threat modeling value is lost.

Why the Gap Exists

The enforcement gap is essentially a systems design problem. Three structural forces keep threat model outputs from becoming enforceable controls:

Abstraction mismatch.
Threat models speak in the language of risk: “An attacker could exploit insufficient input validation on the API gateway to achieve privilege escalation.” Developers need implementation-level specificity: “All endpoints in /api/v2/admin/* must validate JWT claims against the RBAC policy before processing requests.” The translation between these two levels of abstraction is manual, error-prone, and rarely prioritized.
No feedback loop.
A threat model is typically a point-in-time artifact. The system it describes evolves continuously with new endpoints, new data stores, and new integrations. Without a mechanism to detect drift between the threat model and the live system, mitigations that were once adequate become irrelevant, and new attack surfaces emerge unnoticed.
Wrong handoff point.
Threat models are often handed off as documents to development teams who are already deep in implementation. By the time a developer reads “consider rate-limiting this endpoint,” the endpoint has been in production. The output arrives too late to influence design and too early to inform a specific pull request.

What "Enforceable" Actually Means

When I say enforceable, I don’t mean “written down more clearly.” I mean threat model findings that are translated into automated controls that prevent non-compliant code from reaching production. Specifically:

Generation guardrails that enforce the mitigation plan the threat model defined at code generation time
Policy gates that block a merge if a security requirement isn’t met
Architecture fitness functions that detect structural drift from the threat model’s assumptions
Security tests derived directly from identified threats, running on every commit as integration test, penetration test, and later on as bug bounty scope

The goal is to make it harder to violate the threat model than to comply with it. Not through bureaucracy, but through automation. This is the spirit of “secure-by-design” and “secure-by-default”.

A Practical Framework: Threat-to-Guardrail Pipeline

Over the past two years, I’ve been working with security teams to close this gap. The pattern that works is a pipeline that transforms threat model outputs into enforceable artifacts at each stage of the SDLC.

Stage 1: Structured Threat Outputs

The first requirement is that your threat model produces structured, machine-readable outputs, not just prose. Each identified threat should have:

A unique identifier (for traceability)
The component or trust boundary it applies to
The specific security property at risk (confidentiality, integrity, availability, etc.)
One or more mitigations, expressed as testable requirements

This is where most processes break down immediately. If your threat model output is a paragraph describing a risk in natural language, there is no automated system that can act on it. Structured output is the bridge.

Stage 2: Mitigation-to-Policy Translation

Once you have structured mitigations, the next step is translating them into policies that your CI/CD system can evaluate. This is where Policy-as-Code frameworks like Open Policy Agent (OPA) become essential.

Consider a concrete example. Your threat model identifies: “The application stores PII in the user-profile service database. An insider threat could exfiltrate this data if encryption at rest is not enforced.”

The structured mitigation becomes: “All databases in theuser-profile namespace must have encryption at rest enabled.”

The OPA policy becomes:

package infrastructure.database

deny[msg] {

input.resource.type == “aws_rds_instance”

input.resource.labels.namespace == “user-profile”

not input.resource.config.storage_encrypted

msg := “TM-042: Database in user-profile namespace must have encryption at rest (threat: insider data exfiltration)”

}



Notice the TM-042 reference: it traces directly back to the threat model finding. When this gate fires in a pull request, the developer sees exactly what they need to do (“encryption required”), but they also see why, linked to the specific threat.

Stage 3: Architecture Fitness Functions

Some threat model assumptions are structural: “The payment service must never directly access the user database” or “All external API calls must route through the API gateway.” These are architectural invariants.

Architecture fitness functions encode these as automated tests. Tools like ArchUnit (Java), dependency-cruiser (JavaScript), or custom linter rules can enforce these controls on every commit:

// dependency-cruiser rule derived from threat model boundary TM-017

{

name: “payment-service-isolation”,

severity: “error”,

comment: “TM-017: Payment service must not directly access user-db (threat: lateral movement after payment service compromise)”,

from: { path: “^src/services/payment” },

to: { path: “^src/services/user/db”, severity: “error” }

}



When a developer inadvertently introduces a direct database import in the payment service, the build fails because a specific threat model boundary has been violated.

Stage 4: Threat-Derived Security Tests

Every threat in your model implies a test case. “An attacker could bypass authentication by manipulating the session token” implies a test that attempts exactly that. These are more than just traditional unit tests; they’re abuse cases encoded as automated tests.

The most effective pattern I’ve seen is generating test scaffolds directly from the threat model. These tests can loosely follow threat categories, although that is not a requirement:

Spoofing threats → authentication bypass tests
Tampering threats → input validation and integrity tests
Repudiation threats → audit logging verification tests
Information Disclosure threats → data leakage boundary tests
Denial of Service threats → rate limiting and resource exhaustion tests
Elevation of Privilege threats → authorization boundary tests

The true value starts to be realized when these tests become part of the CI pipeline, running on every pull request and raising an alert if a mitigation control is violated.

Stage 5: Continuous Reconciliation

The final piece is a mechanism to detect when the live system has drifted from the threat model’s assumptions. This includes:

Automated architecture discovery that compares actual service dependencies against the threat model’s data flow diagram
New surface detection that flags new endpoints, new data stores, or new integrations that weren’t covered in the last threat model
Mitigation regression alerts that fire when a previously-passing security test starts failing

This creates the feedback loop that keeps the threat model alive as a living set of constraints that the system continuously validates against.

A Real-World Example

Let me share a concrete case. A fintech team I worked with had produced a thorough STRIDE-based threat model for their payment processing system. Among the findings: “An attacker who compromises the notification service could pivot to access payment transaction data through a shared database connection pool.”

In the old world, this would live as a line item in a triage spreadsheet. Maybe someone would eventually create a Jira ticket.

Instead, the team:

Created an OPA policy that denied any infrastructure-as-code change granting the notification service’s IAM role access to the payments database
Added a dependency-cruiser rule preventing code in the notification service from importing payment data models
Wrote an integration test that verified the notification service could not establish a connection to the payment database, even with valid network access
Set up drift detection that would alert if a new IAM policy was attached to the notification service role

Three months later, during a sprint to add payment confirmation notifications, a developer naturally reached for a direct database query to the payments table. The build failed at three different points: the dependency rule, the OPA policy (when they tried to update the IAM role), and the integration test. Each failure message referenced the original threat model finding, explaining why this boundary existed.

The developer understood the threat, redesigned the feature to use an event-driven approach, and the payment service boundary remained intact.

Getting Started: The 80/20 Path

You don’t need to implement all five stages at once. Here’s the progression I recommend:

Step 1: Structure your outputs.
Pick your most recent threat model and restructure its findings into a machine-readable format. JSON, YAML, even a well-structured spreadsheet. Each finding needs an ID, component, security property, and testable mitigation.

Step 2: Pick your top 3 threats and write policies.
Choose the three findings with the highest risk and clearest mitigation path. Write OPA policies, linter rules, or CI checks that enforce them. Run them in “warn” mode first.

Step 3: Promote policies to blocking.
Once you have tuned out false positives, flip the warnings to hard blocks. Your first enforced threat model findings are now live.

Step 4: Build the feedback loop.
Add drift detection for covered components. Expand coverage to more findings. Iterate.

The Cultural Shift

The technical implementation is the easy part. The harder shift is cultural: moving threat modeling from a “security team activity that produces documents” to a “collaborative process that produces enforceable code.”

When developers see their builds fail with a message like TM-042: Database must have encryption at rest (threat: insider data exfiltration), they start to internalize the threat model. It’s no longer an abstract document, but it’s a constraint they interact with daily. Over time, they start designing with those constraints in mind from the start.

This is the real win. Not that you caught a violation, but that the next developer doesn’t create one in the first place because the guardrails made the threat model’s reasoning visible and immediate.

Conclusion

The threat modeling community has made enormous progress on the production side: better methodologies, better tools, better training. But until we close the enforcement gap, we’re leaving most of that value on the table.

The path forward is not more documents or data flow diagrams. It’s fewer documents and more code: policies, rules, tests, and fitness functions that make threat models live in the systems they describe. The whiteboard session is where understanding begins. The CI/CD pipeline is where it becomes durable.

About the Author:

Amir Kavousian is the founder and CEO of DevArmor, an AI-native platform that helps security teams create threat models and turn them into enforceable guardrails. He can be reached onLinkedInor atamir@devarmor.com.

Browse Trainings

Handpicked for you

ENISA’s Secure by Design Playbook: Good Start, Hard Questions

ENISA deserves credit.

Its Security by Design and Default Playbook tackles a problem many product teams already face: how to translate high-level secure-by-design expectations into practical engineering work. The playbook provides SMEs and manufacturers with concrete actions, release gates, and evidence expectations rather than another abstract security framework. That matters under the Cyber Resilience Act, where “we thought about security” will not be enough. ENISA’s draft maps secure-by-design and secure-by-default principles to lifecycle activities, practical playbooks, and CRA-related evidence expectations.

The question is not whether the playbook is useful. It is.

The harder question is whether teams will use it to improve product security, or whether it becomes another checklist that product teams complete without changing design decisions. That distinction is where threat modeling matters.

Read the blog

Curated Content

NO SECURITY METER FOR AI

Your AI scored 92% secure — please enjoy this beautifully calibrated false sense of safety.” Relevant for our readers because this BIML paper lands squarely on a core threat modeling lesson: security is not a leaderboard score, a benchmark result, or a shiny “AI safety” badge. It argues that AI security is an emergent system property, so teams need to model architecture, data provenance, agent behavior, assurance processes, and failure modes rather than trusting black-box benchmark scores as a proxy for real resilience.

How easy is it to steal $10,000 from a locked phone?

The $10,000 “Express” Leak – In a sleek collaboration with MKBHD, Veritasium demonstrates a “nerdy David Blaine” stunt siphoning $10,000 from a locked iPhone by exploiting Apple’s Express Transit mode. For threat modelers, it’s a masterclass in trust boundary erosion: a feature designed for $2 subway fares was tricked into authorizing a high-value heist because the design assumed “transit” always meant “low-risk.” It’s a reminder that when we bridge a gap for convenience, we often build the exact path an attacker needs to bypass our strongest authentication.

Watch video

Handpicked for you

ENISA’s Secure by Design Playbook: Good Start, Hard Questions

Read the blog

Curated Content

NO SECURITY METER FOR AI

How easy is it to steal $10,000 from a locked phone?

Watch video

TIPS & TRICKS

Consider realistic attacker personas

Model threats from the perspective of realistic attacker personas relevant for your system. The same system has different risks depending on whether the attacker is an insider, external cybercriminal, competitor, hacktivist, or nation-state actor.

Go to channel

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

3-Day Training: AI Whiteboard Hacking aka Hands-on Threat Modeling Training, in-person, OWASP Global AppSec EU, Vienna Austria

22-24 June 2026

Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort

June 2026

AI Whiteboard Hacking aka Hands-on Threat Modeling Training, TROOPERS, Heidelberg

22-23 June 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort

September 2026

2 Day Training: Beyond Whiteboard Hacking: Embracing AI-Assisted Threat Modeling, in-person, OWASP Global AppSec USA, San Francisco

3-4 November 2026

Book your spot

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

3-Day Training: AI Whiteboard Hacking aka Hands-on Threat Modeling Training, in-person, OWASP Global AppSec EU, Vienna Austria

22-24 June 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort

June 2026

Book your spot

AI Whiteboard Hacking aka Hands-on Threat Modeling Training, TROOPERS, Heidelberg

22-23 June 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort

September 2026

Book your spot

2 Day Training: Beyond Whiteboard Hacking: Embracing AI-Assisted Threat Modeling, in-person, OWASP Global AppSec USA, San Francisco

3-4November 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort

September 2026

Book your spot

Upcoming Events/Webinars

Webinar – Threat Modeling in the Age of Mythos:
What Threat Modelers Need to Do Differently
June 30 | 8 AM – 8:45 AM (EDT), Webinar together with QA

Join Toreon and our partner QA for a timely discussion on how AI-enabled security capabilities, including Anthropic’s Mythos, are changing the way organizations approach application security, product security, and secure-by-design practices.

Conference – ThreatModCon Vienna
26 – 27 June | Meliá Vienna

Gather with the world’s leading security architects and engineers in the heart of Vienna. Join us for a full day of uncompromising, deeply technical focus.

More info

Threat Modeling Insider - February 2026 - Toreon

Jordan Hardy — Sun, 01 Mar 2026 23:00:00 GMT

51st Edition – February 2026

Welcome!

Welcome to this month’s edition of Threat Modeling Insider!In this edition, Dimitri Van Landuyt shares his view on usign LLM tools for complete threat models.

Next, on the Toreon Blog, Georges Bolssens shares his take on “Managing unknowns assumptions in Threat Modeling”. Very interesting read on hidden risks.

There’s plenty of other actionable insight ahead, so settle in and let’s get started!

Read our previous newsletters

Welcome!

Welcome to this month’s edition of Threat Modeling Insider!In this edition, Dimitri Van Landuyt shares his view on usign LLM tools for complete threat models.

Next, on the Toreon Blog, Georges Bolssens shares his take on “Managing unknowns assumptions in Threat Modeling”. Very interesting read on hidden risks.

There’s plenty of other actionable insight ahead, so settle in and let’s get started!

Read our previous newsletters

In this edition

Guest Article
Dimitri Van Landuyt shares his take on the usage of LLMs when generating complete threat models.

Toreon Blog
The Hidden Risk in Your Security Design: Managing Unknowns and Assumptions in Threat Modeling, by Georges Bolssens

Curated content
Securing Agentic AI: New Risks Require New Safeguards

Curated Content
Agent Skills for Continuous Threat Modeling

Tips & tricks
the C4 model for diagramming / aiming for a certain abstraction level

Training update
An update on our training sessions.

Guest Article

Should we generate complete threat models with LLM tools?

In a relatively short time frame, Large Language Model (LLM) technology has emerged, matured, and proven itself not only to be applicable but actually transformational for a wide range of practices. The core capability to ingest large volumes of information, to reason, and to generate structured or unstructured outputs on demand, at volume, and at velocity provides a unique and unprecedented value proposition. There is no doubt today: LLMs represent a paradigm shift.

On paper, this value proposition translates well to the specific context of threat modeling, which starts from collecting and reconciling different information elements about the system under design to construct a comprehensive system model. In the threat elicitation step, concrete potential threats –situations in which the security or privacy of the system may be harmed– are actively envisioned, articulated, and evaluated. This specific step, perhaps the actual heart of the overall threat modeling process, requires a unique blend of expertise, experience, system and domain knowledge and creativity. For these reasons, threat elicitation in practice remains a costly and time-consuming activity.

We have witnessed integrations of the LLM capabilities into diverse threat modeling methods and tools, in a variety of initiatives, some academic and some commercial in nature.

The growing landscape of LLM-based tools and methods

The well-known 4Q-model divides the overall threat modeling process into four steps, centered around four key questions:

What are we working on? (System description)
What can go wrong? (Threat elicitation, and threat prioritization)
What will we do about it? (Threat mitigation)
Did we do a good job?

The below table provides overview of the identied threat modeling tools that have currently integrated LLM capabilities in support of the overall threat modeling process. The table make distinction between which of these steps of the threat modeling process are targeted with LLM automation, and furthermore indicates whether the tool provides complete automation rather than LLM-based assistance to the human threat modeling.

Tool	System description	Threat elicitation	Threat prioritization	Threat mitigation
Auspex	Assistant	Full	Not supported	Assistant
IriusRisk Jeff	Assistant	Assistant	Assistant	Assistant
Threatmodeler WingMan	Assistant	Assistant	Assistant	Assistant
ThreatModelCompanion	Full	Full	Full	Full
SecureFlag ThreatCanvas	Not supported	Not supported	Not supported	Assistant
StrideGPT	Full*	Full	Not	Full
Fabric-Miessler	Not supported	Full	Not supported	Not supported
Dragon-GPT	Not supported	Full	Not supported	Not supported
PILLAR (Simple, Go, Pro)	Full*	Full	Full	Full
ThreatModelinLLM	Full	Assistant	Not supported	Assistant
AWS threat-designer	Asssistant	Assistant	Assistant	Not supported

As shown, many of these integration focus on supporting the threat elicitation activity, either by automating the process altogether or by providing the threat modeler with access to a supportive generative sparring partner. A number of these currently-available tools implement and provide complete automation of the threat elicitation step.

But, are these LLM-based threat elicitation tools legitimate replacements of human threat modelers in the performance of threat elicitation?

A scientic evaluation of the automated threat elicitation capability

Or, the same question phrased differently: do the LLM capabilities to incorporate, process, evaluate, summarize and reason lead to sufficient results to actually take over the job the human threat modeler?

To address this question, we have conducted a scientic evaluation study involving the publicly-available tools that automate the threat elicitation step: StrideGPT, PILLA-Go, and PILLA-Simple, FabricMiessler, Dragon-GPT, and ThreatModelingCompanion.

The study is based on two complex and contemporary application cases that involve the use of biometry in support of recognition and authentation, once in the context of a personal device (face-based phone unlock), and once in a shared enviroment (access control in a shart building such as an appartment complex or oce building). The data ow diagram (DFD) for the phone unlock system is shown below.

For each of these cases, we use the different LLM-based threat elicitation tools and collect their outputs. We furthermore explore the effect of using different LLMs, a mix of local and hosted models, and in total process 56 distinct threat models generated by automated tools.

We compare these outputs against a set of ground truth baselines, created by human threat modelers. In these baselines, we further distinguish between threats identied by novices and experts, and we further take into account the amount of agreement among the human threat modelers about the identied threats as a weight or penalty factor. This allows for in-depth evaluation of the generated results against human threat analysis.

We use NLP technology –sentence transformers– to perform threat mapping, i.e. to decide whether a generated threat indeed refers to the same issue as one of the threats documented by the human threat modelers. More specically, the attack-BET sentence transformer is used, which was trained specically on security terminology, and not surprisingly proved most capable for this purpose. We calculate semantic similarity, which expresses the extent to which two threat descriptions refer to the same core issue, regardless of phrasing. Based on that, we quantify performance, expressed in precision, recall, F1-score.

Results and findings

In the above graph, the red line represents the semantic similarity threshold (0.85) used as the criterion for considering a generated threat equivalent to one of the ground truth. As shown, the majority of threats generated per tool fall below this threshold line, and t within the 0.5-0.75 similarity range. Close, but not cigar. While the LLM tools generate threats that look similar to the relevant threats, they are not quite at the same level as the threats identied by human threat modelers (yet). Despite the toolgenerated threats being more similar than dissimilar to the relevant threats, overall performance is low.

For over 60% of the threats generated by the LLM-based threat elicitation tools, their closest baseline match was identied by novice threat modelers. Threat recall is very low for the threats uniquely elicited by the experts. LLM tools are not (yet) replacing threat modeling experts.

Overall, and in large part due to generating large volumes of less applicable threats, the absolute precision and recall of relevant threats remains lower than that performance of human threat modelers.

Tools with more more sophisticated prompting techniques score better on the more complex distributed building access control case, but such advantages are not seen in more the simpler application case. This suggests that the appropriate prompting technique may depend highly on the specics of the application case: there is no single-size-ts-all solution to instruct LLMs for threat modeling.

While there are notable dierences between the tools (which can mainly be considered to be a set of LLM prompt instructions, and conguration settings such as LLM temperature), a similar effect on performance results can be seen when changing the actual LLM models being used. The choice of underlying LLM model is of equal important to picking the right tool. In our study, the best results were consistently attained with Google’s gemini2.0-flash model.

Want to know more?

Complete details can be found in the scientic publication: A comparative benchmark study of LLM-based threat elicitation tools, Dimitri Van Landuyt, Majid Mollaeefar, Mario Raciti, Stef Verreydt, Abdulaziz Kalash, Andrea Bissoli, Davy Preuveneers, Giampaolo Bella, Silvio Ranise, Future Generation Computer Systems (special issue on Generative AI in Cybersecurity), Volume 177, 2026, ISSN 0167-739X, https://doi.org/10.1016/j.future.2025.108243.

(https://www.sciencedirect.com/science/article/pii/S0167739X25005370)

Additional materials such as case description, benchmark code, detailed results, and more can be found in the supporting materials package: https://zenodo.org/records/17305023

Browse Trainings

Handpicked for you

Toreon Blog: The Hidden Risk in Your Security Design: Managing Unknowns and Assumptions in Threat Modeling

In the world of cybersecurity, what you know can protect you, but what youassume can destroy you. Threat modeling is a foundational pillar of secure design, yet even the most rigorous models are often built on a shaky foundation of “unknowns” and “unspoken assumptions”.

Whether you are “shifting left” leveraging modern DevOps processes or managing a legacy monolith, understanding how to document and validate these gaps is the difference between a resilient system and one waiting for a breach.

Most security teams follow the industry-standard “DICE framework” for threat modeling. However, this approach does (by far) not prevent assumptions from being made.

Read the blog

Curated Content

Securing Agentic AI: New Risks Require New Safeguards

Autonomous AI agents require a shift in threat modeling: treat them as “digital employees” requiring behavioral boundaries, not just traditional software.

Key Attack Vectors & Mitigations

Unbounded Autonomy: Mitigate rogue actions with human-in-the-loop (HITL) oversight, utilizing dynamic escalation or mandatory approvals for high-risk operations.
Compromised Agent Blast Radius: Contain lateral movement and unauthorized access using application sandboxing, Just-in-Time (JIT) provisioning, and strict least-privilege enforcement.
Training Data Poisoning: Implement rigorous data validation. The threshold for compromise is alarmingly low: injecting just 5 malicious texts into a dataset of millions can achieve a 90% manipulation success rate

Agent Skills for Continuous Threat Modeling

This MIT-licensed repository provides agent-agnostic tools to automate Continuous Threat Modeling within developer workflows, integrating directly with AI coding assistants like Claude Code and OpenAI Codex.

Available Core Skills:

pytm: Automatically generates comprehensive threat models, outputting both structural diagrams and actionable security findings.
ctm: Monitors code commits to evaluate and flag security-notable changes in real-time.
4qpytm: Facilitates an interactive, four-question threat modeling session guided by user input.

Toreon Blog: The Hidden Risk in Your Security Design: Managing Unknowns and Assumptions in Threat Modeling

Most security teams follow the industry-standard “DICE framework” for threat modeling. However, this approach does (by far) not prevent assumptions from being made.

Read the blog

Curated Content

STRIDE-GPT As an MCP Server: A Composable Tool That AI Agents Can Use Autonomously

STRIDE-GPT has been released as an MCP server, enabling AI agents to autonomously perform full threat modeling on a codebase or architecture while fitting seamlessly into agent-based workflows. It delivers STRIDE-based threat analysis, risk scoring, mitigations, and executive-ready reports, all composable with other MCP tools like GitHub and Terraform.

Key Takeaways are:

STRIDE-GPT turns threat modeling into an autonomous, composable AI workflow, integrating code, infrastructure, and security analysis in a single session
It provides comprehensive coverage, including all six STRIDE categories, DREAD risk scoring, attack trees, and OWASP LLM Top 10 (2025) AI/ML threats
The tool is free, open source, and flexible—usable interactively or fully autonomously—while supporting modern domains beyond web apps, such as cloud, APIs, IoT, and mobile

Global Risks Report 2026 - World Economic Forum

The Global Risks Report 2026 frames “Uncertainty” as the defining condition of a new Age of Competition, marked by weakening cooperation, rising multipolar rivalry, and eroding trust. The outlook is starkly pessimistic, with escalating geoeconomic conflict, accelerating AI risks, and long-term environmental threats reshaping how global and systemic risks must be understood.

Key Takeaways are:

Geoeconomic confrontation is now the top short-term global risk, pushing threat modeling to include infrastructure sabotage, supply-chain weaponization, and cyber-physical attacks on critical systems
AI has shifted from a tool-level risk to a systemic one, with concerns ranging from misinformation and deepfakes to adversarial data poisoning, automated escalation, and long-term governance failures
Cryptographic complacency, information warfare, and fragmented supply chains demand forward-looking models that account for quantum “harvest now, decrypt later” threats and the erosion of digital trust and strategic dependencies

the C4 model for diagramming / aiming for a certain abstraction level

The “C4 model” offers a structured and hierarchical way to visualize software architecture, which greatly facilitates threat modeling by clarifying system context, allowing to “zoom in” to increased levels of detail when needed. This clear depiction helps identify interactions and allows for identification of potential attack surfaces, forming a solid foundation for pinpointing (and mitigating) security risks.

Inspired by the C4-model’s philosophy, a diagram-as-code framework known as “Structurizr” was developed to accompany it, featuring native export to other formats, avoiding any type of tool lock-in.

The C4 model

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort

April 2026

Advanced Whiteboard Hacking – aka Hands-on Threat Modeling, NorthSec Training, Montreal

May 10-11 2026

3-Day Training: AI Whiteboard Hacking aka Hands-on Threat Modeling Training, in-person, OWASP Global AppSec EU, Vienna Austria

22-24 June 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort

March 2026

Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort

September 2026

Book your spot

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort

April 2026

Book your spot

Advanced Whiteboard Hacking – aka Hands-on Threat Modeling, NorthSec Training, Montreal

May 10-11 2026

Book your spot

3-Day Training: AI Whiteboard Hacking aka Hands-on Threat Modeling Training, in-person, OWASP Global AppSec EU, Vienna Austria

22-24 June 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort

June 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort

September 2026

Book your spot

Upcoming Events/Webinars

Supernova/Cybernova

You’ll be able to find us at both SuperNova on March 25th and March 26th, and CyberNova on March 24th. With Supernova being an internationally renowned event for tech and innovation, and this years first edition of Cybernova, focusing on all things related cybersecurity. Moreover we are also present at the Agoria boothspace.

Webinar Toreon x IriusRisk

This session is the first in our two-part series with IriusRisk and takes a maturity-based look at how threat modeling evolves as organizations scale from startup to enterprise.

You’ll learn how high-performing teams maintain consistent security standards while avoiding common pitfalls such as fragmented processes, inconsistent risk coverage, and duplicated or missed controls.

We’ll explore how the right mix of services, tooling, and best practices helps organizations build scalable, sustainable threat modeling programs, ensuring security keeps pace with business growth.

Uncover Hidden Security Design Risks: Improve Threat Modeling & Reduce Assumptions

Jordan Hardy — Wed, 25 Feb 2026 23:00:00 GMT

Exploring unknowns via the DICE framework

Most security teams follow the industry-standard “DICE framework“ for threat modeling. However, this approach does (by far) not prevent assumptions from being made.

Just to refresh everyone’s mind, here are the 4 phases of this framework:

D is for Description of the context (What are we building?)

I is for Identification of threats (What can go wrong?)

C is for Countermeasure definition (What are we going to do about it?)

E is for Evaluation (Did we do a good enough job?)

While most mature organizations have standardized the first three pretty well, validation of assumptions in the last phase is often overlooked. This makes sense, because to enable validation of unknowns and assumptions in the “Evaluation” phase, this obviously requires keeping track of them in the three phases that preceded it…

This article introduces the concept of an “assumption register” and explores how to piggyback its creation off of the four phases of the DICE framework.

What are we working on?

While seemingly a straightforward question, in threat models we create with our clients there’s rarely an all-encompassing answer.

When threat modeling a system that doesn’t exist yet, technical details have often not crystallized yet. While this is mostly a by-product of threat modeling “too soon” in the design phase, it does present us with an opportunity to start documenting unknowns and assumptions.

In existing / legacy systems the story is very different. Knowledge drain from staff churn and incomplete documentation often leaves significant gaps in knowing how the system actually functions.

What can go wrong?

This source of unknowns is different from the other ones, mainly because it doesn’t have the word “we” in it. Consequently, the unknowns here originate from others’ actions and are an artefact of “you don’t know what you don’t know”. Specialized security expertise helps, but it’s a luxury many teams simply don’t have. This is where assumptions must be made but also where some important misasumptions are born.

A few examples of these that we have come across in the past:

The “Good employee” fallacy: Assuming attackers only come from the outside. In reality, employees can be bribed, threatened, vengeful or in need of cash.

The “Security through obscurity” fallacy: Thinking “only we understand how this works” and/or “nobody would bother to figure this out”. Advanced adversaries use automated tools to uncover precisely what you think is hidden.

The “Nobody would actually do this” fallacy: Underestimating the technical sophistication or motivation of potential threat actors. People who have relatively little to lose, can act in extremely unpredictable ways.

The “Hypothetical attack; zero likelihood ” fallacy: A great example of “you don’t know what you don’t know”; we have literally heard this from multiple system engineers when discussing VM-to-host-escapes and VLAN-hopping during threat elicitation. This is the easiest one to debunk if documented cases are available. Sometimes, indeed, there just aren’t any documented cases, and the threat is effectively hypothetical. Then you go ahead with documenting predictive assumption statements along the lines of

“We assume that an exploit for breaking TLS1.2 will not to be developed during the lifetime of this IoT device”.

What are we going to do about it?

Misassumptions also happen here, but for different reasons.

The “Our cloud vendor surely takes care of this” fallacy Teams often assume that use of a major cloud provider solves all their security problems. This ignores the Shared Responsibility Model, where the vendor secures the “fabric” of their cloud, but you are responsible for securing your data in the cloud.

Together with the predictive claim about the perceived lack of an expoit, the real assumptions that support the “unhackability” of the TLS1.2 connection are in this “What are we going to do about it”-phase:

“We assume that our infrastructure team implements TLS1.2 according to the current industry standards”.

“We assume that our infrastructure team DOES NOT implement TLS/SSL versions that precede TLS1.2”

“We assume that the public-key-pinning mechanism prevents the IoT device from accepting any certificate other than the one we envisioned”

“We assume that the HTTP library in the IoT device doesn’t accidentally connect to the HTTP endpoint with its authentication token to then be redirected”

“We assume that HTTPS implementations of our infrastructure are being validated in our quarterly penetration tests”.

“We assume that Certificate Authority X will refuse CSRs for our domain”

Getting these assumptions down is important but the work it’s not done to come to an assumptions register; more on this in the next section.

The Rule of Thumb: If you don’t have a definitive answer, you have two choices:

If acquiring the answer is feasible in the short term, document it as an open question

If acquiring the answer is not feasible (anymore) document it as an assumption in (drum roll…)

The Assumption Register

A high-quality register could, for example, track the following properties for every assumption:

The Assumption: A clear statement (e.g., “We assume the end user has an antivirus installed”). If unclear from the assumption statement itself, a temporal nature can be added

Validation:A test that can prove the assumption is correct. (Not always feasible, like the case of a third party computer having A/V installed)

Confidence (+ Justification): How sure are you when stating this assumption? (e.g., “Almost guaranteed due to corporate environment policy”).

Consequence if it Fails: What happens if the assumption is wrong? (e.g., “The user downloads a virus via our platform and we have no server-side scanning to stop it”).

Owner:Person, department or role that owns the risk of getting the assumption wrong

Conclusion: Don’t Let Unknowns Be Your Downfall

Threat modeling is a continuous process of discovery. By identifying your unknowns and tracking your assumptions, you turn “blind spots” into a prioritized list of things to validate.

Next Step for Your Team: Review your current project’s architecture diagram. Pick one interaction across a trust boundary and ask yourself: “What are we assuming that, if true, makes this secure?”Converselyask the opposite: “What are we assuming that, if false, makes this insecure?”

Add those items to your Assumption Register.

About the Author:

Georges’ lifelong curiosity about ‘how stuff works’ culminated in a Master’s degree in Electro-Mechanical Engineering. With over 15 years of experience in technical and managerial roles within the biotech industry, he developed a deep proficiency in programming and a passion for cybersecurity.

This unique combination of engineering logic and coding expertise makes Georges an ideal Application Security expert; he relates to the daily challenges of software developers while fully understanding the adversarial mindset of hackers. Since transitioning to AppSec in 2017, he has consulted for a wide variety of business contexts.

Georges joined Toreon in 2021, where he currently serves as the Product Owner for Threat Modeling Consulting. He is also the Lead Trainer for Toreon’s globally recognized ‘Whiteboard Hacking’ training. Leveraging his background in electronics, Georges is a key member of the hardware penetration testing team, with specific expertise in threat modeling for embedded medical and non-medical devices.

Schedule a call

Get in touch with our experts for a no-obligation advisory conversation.

Contact an expert

Upcoming Events/Webinars

Supernova/Cybernova

Webinar Toreon x IriusRisk

This session is the first in our two-part series with IriusRisk and takes a maturity-based look at how threat modeling evolves as organizations scale from startup to enterprise.

We’ll explore how the right mix of services, tooling, and best practices helps organizations build scalable, sustainable threat modeling programs, ensuring security keeps pace with business growth.

Why Thinking Like a Defender Beats the Attacker Mindset

Jordan Hardy — Wed, 14 Jan 2026 23:00:00 GMT

By Sebastien Deleersnyder

“Think like an attacker.” It’s our industry’s favorite mantra, but for most engineering teams, it’s a setup for failure. It expects developers – who spend their days perfecting “happy flows” – to suddenly pivot into a destructive mindset that goes entirely against their nature.

This creates a bottleneck for organizations attempting to scale threat modeling, as engineers frequently find themselves paralyzed by “creator-blindness”—the natural cognitive inability to see flaws in a system they have specifically designed to succeed. To overcome this paralysis, many teams turn to GenAI for rapid answers, only to be caught in a validation gap where they lack the specialized security expertise required to distinguish between a helpful insight and a dangerous hallucination.

The truth is, you don’t need more “attackers” on your payroll. You need to lean into the Defender’s Advantage. Here’s why shifting the focus back to your own domain is the better way to make threat modeling stick.

The Myth of the "Attacker Mindset"

Telling a developer to think like an attacker is like telling a home cook to “think like a Michelin-starred chef”. In our threat modeling training, we often say: “When I’m in the kitchen, my wife saying ‘Think like Jamie Oliver’ doesn’t make me a better chef.” It’s a nice sentiment, but it isn’t prescriptive or clear.

Most people don’t know how an attacker spends their day or what tools they use. When we demand this mindset, we often just make engineers feel siloed or embarrassed that they “don’t get it”.

Saying “It would be helpful to you if you learned to think like an attacker” is exhorting people to learn that skill. Demanding that they do it, or implying that they’re stupid for not knowing how to do it is actively counter-productive.

Adam Shostack, 2008

Stop the “Attacker Mindset” struggle. OurThreat Modeling Training teaches engineers to secure what they build using the systems they already know.

Why a Defender Mindset Makes Threat Modeling Scalable for Developers

The “Defender’s Mindset” is built on what your engineers already know: their own software design. Instead of chasing an ever-evolving body of attacker knowledge, they focus on their span of control.

Leverage Domain Expertise: Your devs know their technology stack and the application architecture better than any external threat modeler.
Predictable Security: Focusing on security-by-design principles and best practices is a more stable way to improve security posture than reacting to the latest exploit.
Reduced Friction: It aligns security with DevOps speed by integrating it into existing workflows rather than imposing a “pull-down” requirement.

The GenAI Trap

Nowadays, when developers are told to think like attackers, they often turn to Generative AI. This can create a false sense of security, giving them a lot of “knowledge” on attacks without the ability to validate it. AI can list vulnerabilities, but it doesn’t make someone a threat modeler.

Training your team to be defenders allows them to use AI as a tool rather than a crutch, ensuring security is measured alongside your success objectives.

Our training doesn’t just teach you to find threats; it provides the structured framework necessary to validate AI outputs against your specific architecture, closing the dangerous ‘hallucination gap’ in automated security.

Bridging the Gap: Practical Steps

You don’t have to ignore attacks entirely. Use “thinking like an attacker” as a specific awareness tool to show how threats are realized in the real world. But for the day-to-day threat modeling, follow these steps:

Start with the diagram: Use structured methods, such as “STRIDE-per-interaction” to help people step outside their “creator-blindness”.
Focus on the stack: Train teams on the best practices for implementing security in their specific technology stack.
Empower, don’t outsource: Build the expertise internally in the product teams to reduce reliance on external experts.

Conclusion

Relying on the “attacker mindset” keeps security as an afterthought, driven by product compliance. By reframing threat modeling as a Defender’s Discipline, you empower your architects and engineers to take ownership of their security posture. This shift improves risk management, maintains compliance, and ensures you aren’t waiting for a breach to find your vulnerabilities.

Ready to empower your team to own their security?

Stop letting your architects and engineers feel siloed by unrealistic expectations. It’s time to move beyond the abstract “attacker” mantra and start “doing” with a practical, defender-first framework that actually fits your engineering workflow. By building this expertise internally, you bridge the validation gap and turn security from a bottleneck into a baseline.

Explore our Threat Modeling Trainging for teams

About the Author

Sebastien (Seba) Deleersnyder, co-founder and CTO of Toreon, combines software engineering expertise with a passion for holistic product security. After earning his Master’s in Software Engineering from the University of Ghent, with a thesis on “Hyphenation using neural networks,” he became a driving force in the security community as the founder of the Belgian OWASP chapter, a member of the OWASP Foundation Board, and co-founder of BruCON, Belgium’s annual security conference. His leadership of OWASP SAMM and his decade-long role as a highly rated Black Hat trainer have significantly impacted global software security, earning consistently outstanding feedback from participants. Currently, Seba focuses on adapting security models for DevOps and expanding awareness of AI Threat Modeling.

Connect with Sebastien Deleersnyder

Threat Modeling & Embedded Systems

Jordan Hardy — Tue, 16 Dec 2025 23:00:00 GMT

By Robert Hurlbut

In modern society, everywhere we look, we see examples of embedded systems at work: IoT devices in our homes, critical controllers in industrial facilities, medical devices, and all kinds of vehicles. Despite their ubiquity and importance, these systems often lack robust security frameworks comparable to those in traditional IT systems. This is where threat modeling becomes critical, providing a way to think about secure design and focusing on understanding and mitigating embedded system threats.

Embedded Systems Need Special Attention

Embedded systems present unique security challenges:

Resource Constraints: Typically, embedded devices have limited processing power, memory, and storage. This makes it challenging to implement robust security controls such as encryption or complex authentication mechanisms.
Long Lifecycles: Unlike other systems that may be replaced every few years (such as your laptop), embedded systems in industrial control systems or medical devices can remain in service for decades, often without regular security updates.
Physical Accessibility: Embedded devices are frequently deployed in locations that are easy to access physically, enabling attackers to gain direct access to hardware.
Real-Time Requirements: Many embedded systems utilize strict timing requirements when responding to inputs, which leaves little room for security overhead that might introduce latency.
Diverse Attack Surfaces: Embedded systems can be attacked through software vulnerabilities, hardware manipulation, side-channel attacks, supply chain compromises, and more.

Introducing MITRE EMB3D

The MITRE Embedded Device Security (EMB3D) Threat Model is a comprehensive framework specifically designed to address the unique security challenges of embedded systems. Released as an open-source knowledge base in September 2024, EMB3D (most recently updated to v2.0.1 in April 2025) provides a structured approach to identifying and mitigating threats throughout the embedded device lifecycle.

Key Threats in EMB3D

EMB3D organizes threats into a hierarchical taxonomy, which makes it easier to analyze embedded systems systematically:

Device Properties: High-level groupings of related threats (Hardware, Application Software, System Software, and Network – see Figure 1 below)
- Threats: Specific security concerns within each device property (cataloged through Threat Identifications – TIDs)
  - Mitigations: Countermeasures to reduce or eliminate threat impacts (cataloged through Mitigation Identifications – MIDs)

This structure allows security teams (and threat modelers) to methodically review potential threats and vulnerabilities rather than relying on ad-hoc analysis.

The EMB3D Framework Structure

Threat type

Examples

Hardware Threats

Hardware is one of the most challenging attack surfaces for embedded systems, as physical access can bypass many software protections.

Debug interface exploitation (JTAG, UART)
Side-channel attacks that extract secrets by analyzing power consumption or electromagnetic emissions
Fault injection attacks that use voltage manipulation to bypass security checks
Physical tampering with components or traces

Application and System Software Threats

Embedded systems run software that can contain vulnerabilities.

Buffer overflows and memory corruption in firmware
Insecure boot processes that allow malicious code to load · Inadequate code signing and verification.
Privilege escalation vulnerabilities
Insecure update mechanisms that could allow malicious firmware installation

Network and Communication Threats

As embedded devices increasingly connect to networks, they inherit all the network security challenges of traditional systems, often without defenses.

Unencrypted communications exposing sensitive data
Weak or default credentials
Vulnerable protocols and services
Interception attacks
Denial of service vulnerabilities

Using EMB3D in Your Threat Modeling Process

Here is a practical approach to using EMB3D for embedded system threat modeling:

1. Define Your System Scope

Document what you are analyzing. Create a system architecture diagram showing all components, interfaces, data flows, and trust boundaries. Identify what assets you are protecting (user data, cryptographic keys, control functionality, safety features) and document any assumptions about the operational environment.

2. Map to EMB3D Device Properties

Work through each EMB3D device property systematically. For each component in your architecture, ask which threats from the framework apply. Consider the entire lifecycle from development through decommissioning.

3. Assess Threat Severity

Not all threats pose equal risk. Evaluate each identified threat based on the likelihood of exploitation (considering attacker capability requirements, accessibility, and existing controls) and the potential impact on confidentiality, integrity, availability, and safety.

4. Identify Gaps and Mitigations

Compare your current security controls against EMB3D’s recommended mitigations. This gap analysis reveals where the embedded system is exposed to security threats and helps prioritize security investments. Document why you accept specific threats if you choose not to mitigate them.

5. Validate and Test

Threat models are only valuable if they reflect reality. Conduct penetration testing and security assessments focused on the threats you have identified. Review and update your threat model as the system evolves or new threats emerge.

Getting Started

Get started with MITRE EMB3D today! Here are five practical next steps:

1. Access the Framework:

Visit the MITRE EMB3D website to explore the complete threat taxonomy and documentation.

2. Train Your Team:

Ensure your security team, developers, and architects understand both general threat modeling principles and the specifics of embedded system security.

3. Start Small:

Begin with a pilot project on a single embedded system to learn the framework before rolling it out more broadly.

4. Integrate with Development:

Make threat modeling a standard part of your secure development lifecycle, not a one-time exercise.

5. Stay Current:

MITRE EMB3D continues to be updated with new or updated threats and mitigations.

MITRE EMB3D Terms of Use

One item to be aware of in using MITRE EMB3D is its Terms of Use. The EMB3D framework is free to use for internal business purposes, academic purposes by public or non-profit educational organizations, and for research. It is not to be used for commercial purposes (i.e., turned into or used as a “for-profit” tool). Please consider these requirements when using the framework.

Conclusion

Embedded systems are becoming increasingly critical to our infrastructure. Rigorous threat modeling is no longer optional. One solution is to check out MITRE EMB3D and its comprehensive, structured approach, specifically tailored to the unique challenges of embedded device security. By systematically working through hardware, software, and

network threats, security teams and threat modelers can identify threats and vulnerabilities before attackers do and implement effective mitigations.

Ready to master threat modeling?

Become a Certified Threat Modeling Practitioner today!

About the Author

Robert Hurlbut, a Principal Product Security Architect and Threat Modeling Trainer at Toreon, has over 30 years of experience in secure coding and software architecture. Before joining Toreon, he initiated and led threat modeling programs at Bank of America and Aquia. Robert is passionate about empowering teams to identify, communicate, and understand threats and mitigations, ultimately enhancing the security of workloads through effective threat modeling. He is an ISC2 Certified Secure Software Lifecycle Professional (CSSLP), holds a Master of Science in Cyber Security from Southern New Hampshire University, and is pursuing a Ph.D. in Space Cybersecurity at Capitol Technology University. Additionally, Robert is a co-author of the Threat Modeling Manifesto and the Threat Modeling Capabilities Model, and he co-hosts the Application Security Podcast. Globally recognized as an expert in threat modeling, he regularly contributes thought leadership and delivers workshops and training at industry events.

Connect with Robert Hurlbut

Threat Modeling and Threat Intelligence: Distinct and Complementary | Toreon

Hans Francken — Tue, 23 Sep 2025 22:00:00 GMT

By Robert Hurlbut

Threat modeling and threat intelligence are essential practices of a proactive security strategy. Occasionally, these terms can be confusing or mixed up because they sound similar (both start with “threat” – aren’t they the same?). Instead, these terms represent distinct and complementary approaches to understanding and mitigating cybersecurity risks. This blog post will explore their differences, how they complement each other, and how they can be integrated to provide a more secure posture for your organization.

What is Threat Modeling?

Threat modeling is a proactive approach to understanding, identifying, and addressing potential security threats to a system, application, or organization. It’s a security analysis technique that examines what could go wrong and how to prevent it.

Key Characteristics of Threat Modeling:

Preventive/Forward-Looking: Threat modeling is ideally performed during the design phase or ongoing for an existing system as new features are created and before vulnerabilities can be exploited.
System-Specific: The focus areas are on systems, applications, or business processes, analyzing their unique attack surfaces and potential weaknesses.
Structured Frameworks/Methodologies: Common frameworks include STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) for application/system-centric threats and LINDDUN for privacy threats. PASTA (Process for Attack Simulation and Threat Analysis) is a 7-step methodology.

The Threat Modeling Process:

Understand the System: Create detailed diagrams showing system architectures, data flows, and trust boundaries
Identify Threats: Use structured approaches to enumerate potential threats against each system component
Assess Risk: Evaluate the likelihood and impact of identified threats
Define Countermeasures: Develop specific controls and mitigations for high-priority threats
Validate and Iterate: Continuously update the model as the system evolves

What is Threat Intelligence?

Threat intelligence collects, analyzes, and disseminates information about current and emerging security threats. It analyzes raw data about threats and turns them into actionable insights that inform security decisions.

Key Characteristics of Threat Intelligence:

Data-Driven/Reactive: Based on observed threat actor behavior, attack patterns, and indicators of compromise from real-world incidents.
Contextual Information: Detailed threat actor motivations, capabilities, tactics, techniques, and procedures (TTPs).
Timeliness: It focuses on the current threat landscape and emerging trends that could impact the organization.
External Focus: This strategy typically reviews sources outside the organization, including commercial feeds, open-source intelligence, and industry sharing.

Key Differences Between Threat Modeling and Threat Intelligence

Threat Modeling	Threat Intelligence
Orientation	Future-focused, anticipates potential threats	Present and past-focused, analyzing current and historical threats
Scope/Context	Internal and system-specific	External and industry/threat-landscape focused
Methodology	Structured analytical process, uses established frameworks	Data collection, correlation, and analysis from multiple sources
Output/Application	Specific countermeasure/security controls	Contextual information to inform broader security strategy and operations
Stakeholders	Primarily used by developers, architects, and security engineers	Security operations teams, incident responders, and strategic decision-makers

How Threat Modeling and Threat Intelligence Complement Each Other

Threat Identification
Threat intelligence provides real-world context, making threat modeling more realistic and comprehensive by incorporating actual threat actor behaviors and attack patterns observed in the wild.

Prioritization of Threats
Threat intelligence helps organizations understand the most relevant threats to their industry, geography, or technology stack. This enables threat modelers to focus on credible attack vectors rather than on every conceivable threat equally.

Validation and Updates
As threat intelligence reveals new attack techniques or threat actor campaigns, existing threat models can be updated to reflect these evolving realities. This, in turn, creates feedback loops that keep threat models current and relevant.

Strategic and Tactical Security
Threat modeling provides a tactical approach to security, while threat intelligence provides the strategic context about the threat landscape.

Practical Integration Strategies

Improving Threat Models
Begin threat modeling exercises by reviewing any relevant threat intelligence reports. Understanding what threat actors target organizations like yours and their known TTPs can improve threat scenarios.

Validating Threat Models
Use threat intelligence to validate assumptions made during threat modeling. If your threat model assumes specific attack vectors are unlikely, check whether recent intelligence contradicts this assessment.

Updating Threat Models
Establish processes to update threat models based on new intelligence regularly. When threat intelligence reveals new attack techniques or threat actors targeting your industry, assess whether your existing threat models account for these developments.

Shared Risk Assessment Framework
Develop risk assessment criteria incorporating threat modeling outputs (system-specific vulnerabilities) and threat intelligence findings (threat actor capabilities and intentions).

Cross-Functional Collaboration
Foster collaboration between threat modeling teams and threat intelligence analysts. Use cross-team training so each set of teams understands the techniques and approaches of the other. Regular knowledge-sharing sessions can help each discipline inform and improve the other.

Conclusion

Threat modeling and threat intelligence represent distinct but complementary approaches to cybersecurity risk management. Threat modeling provides the systematic analysis needed to understand and secure specific systems, while threat intelligence offers the external context necessary to understand the evolving threat landscape.

You don’t have to choose between these approaches to apply—you can leverage both of them! By using threat intelligence to inform and validate threat models and threat modeling insights to guide intelligence collection and analysis, organizations can develop a more comprehensive and practical approach to cybersecurity.

Ready to master threat modeling?

Become a Certified Threat Modeling Practitioner today!

About the Author

Robert is a seasoned software developer, software architect, and recognized leader in application security and threat modeling. He is dedicated to helping developers, architects, project managers, and other stakeholders strengthen their understanding of secure software design and architecture through threat modeling and related security practices. A strong advocate for building and sustaining organizational Threat Modeling Programs and Security Champion Programs, Robert brings extensive experience in guiding teams to successfully launch, scale, and mature these initiatives.

Connect with Robert Hurlbut

Threat Modeling Insider - August 2025 - Toreon

Hans Francken — Wed, 27 Aug 2025 22:00:00 GMT

46th Edition – August 2025

Welcome!

Welcome to this month’s edition of Threat Modeling Insider! In our featured guest article, Elevation of MLsec: bringing threat modeling to machine learning practitioners, Elias Botterli Sørensen explores how gamification can make ML security risks tangible, helping cross-functional teams identify threats from data poisoning to model misuse in an engaging and practical way.

Meanwhile, on the Toreon blog, Robert Hurlbut explores Space Cybersecurity and Threat Modeling, uncovering the unique risks satellites and space systems face and how frameworks like SPARTA can help protect this critical frontier.

There’s plenty of other actionable insight ahead, so settle in and let’s get started!

Read our previous newsletters

Welcome!

Welcome to this month’s edition of Threat Modeling Insider! In our featured guest article, Elevation of MLsec: bringing threat modeling to machine learning practitioners, Elias Brattli Sørensen explores how gamification can make ML security risks tangible, helping cross-functional teams identify threats from data poisoning to model misuse in an engaging and practical way.

There’s plenty of other actionable insight ahead, so settle in and let’s get started!

Read our previous newsletters

On this edition

Guest article
Elevation of MLsec: bringing threat modeling to machine learning practitioners, by Elias Botterli Sørensen.

Toreon Blog
Space Cybersecurity and Threat Modeling, by Robert Hurlbut.

Curated Content
State of Threat Modeling 2024-2025. Community insights shaping threat modeling’s future.

Curated content
MITRE Adds Mitigations to EMB3D Threat Model.

Curated content
Threat modeling your generative AI workload to evaluate security risk.

Tips & tricks
Get started with our DFD library on draw.io.

Training update
An update on our training sessions.

Guest article

Elevation of MLsec: bringing threat modeling to machine learning practitioners

In 2024, I created the threat modeling card game Elevation of MLsec (EoML), which is a machine learning security extension of Adam Shostack’s well-known game Elevation of Privilege (EoP). Simply put, the cards in the game describe things that can go wrong during the whole lifecycle from machine learning (ML) training and engineering, to operations where models interact with the world.

I believe the game is highly relevant during a period where adoption of machine learning technology like large language models (LLMs) has taken off. Elevation of MLsec follows the same setup and rules as Elevation of Privilege, and can be combined with the original deck if you threat model holistic view of a system with multiple components.

In this article, I will expand upon a bit of the game’s backstory and technical background, as well as my current experiences with applying the game and sharing it with practitioners.

The magic of gamification

As a security professional reading this, you have probably felt the frustration of not being able to get people in the organization properly interested in threat modeling. By gamifying threat modeling in a card game, we remove many of the barriers of people who would otherwise be intimidated or disinterested in such a technical exercise. I see that we humans have a tendency to forget the play when we grow up. All young mammals play to learn.

However, there is very good reason to want to play, and we have good backing for it in academia. The gamification of work-related or academic topics (which involves designing games for an educational purpose outside entertainment), is known as serious games.

Serious games are an effective teaching tool, and can be a great way to direct the discussion of complex issues. When interacting with a game, more of the participants’ senses are activated. A game’s human-focused design nudges players to want to learn and understand more about the topic [1]. I firmly believe that the sensation we get from pulling out a card deck and having something physical in our hands gives us something of pedagogical value that computers can not.

To learn more about this topic, I can recommend Adam Shostack’s whitepaper about EoP [4]. The lessons learned and game design carry well over to the extension EoML.

Elevation of MLsec on GitHub

Backstory

During the autumn of 2022, I watched a lecture from Gary McGraw about his recent work in security engineering for machine learning. This lecture inspired in me a deep interest for machine learning viewed from a security and safety perspective. The work by Gary and his colleagues has been published through the Berryville Institute of Machine Learning (BIML), whose website has their reports available under the creative commons.

Then later in 2023, I got familiar with Elevation of Privilege through a presentation from a colleague who had used the game to teach threat modeling to his team. While I was already familiar with STRIDE, this was the first time EoP crossed my path. The presentation of this game gave me an idea; why not take the report from BIML and put it into a game like EoP? I worked on an initial draft of the game where I took some of the notable risks from BIML and got help designing a card surface. During this period, BIML published their 2024 report that targeted risks within LLMs. This influenced the game design, which aside from generic ML risks got a few cards that are specific to LLMs. As a nod to the OWASP crew, I also included a couple items from the OWASP top 10 list for LLMs. After several trials of playtesting, I officially announced the game roughly one year ago, in June of 2024. Since then I have been running several more play tests and workshops, and I am still actively collecting feedback from players.

The technical background from BIML

I like the BIML risk framework [2] because they offer a rigorous and holistic view of the ML lifecycle without hand-waving of fluffy terminology. Rather than talking about AI and using anthropocentric terminology, there is a focus on technical details as well as a critical view on the bigger picture. The game Elevation of MLsec applies the risk framework of BIML, who use nine components to describe a generic machine learning lifecycle. An important emphasis is put on the details of the training process, where seemingly harmless decisions can have subtle but dangerous consequences for security or other quality aspects of the system.

For the game, I used four of the components to get my four card suits. The lifecycle with respect to the card suits is shown in the figure below.

The cards suits come from the four objects: 3. datasets, 6. inputs, 7. model, and 9. outputs. The the ovals in components 1, 2, 4, 5 and 8 (and the polygon in component 1) are processes or data pools that form interfaces between the objects. Therefore their risks can be considered risks of the object with which they interface. Risks about the system as a whole can also be isolated to one component in our context as it usually is most present in one of the components.

Considering this lifecycle, let’s have a look a few risks to illustrate the range of things that can go wrong in machine learning (ML):

Data poisoning: Data is integral for the security of an ML system. That’s because an ML system learns to do what it does directly from data, and essentially becomes the data. If an attacker can intentionally manipulate the data being used by an ML system, the entire system can be compromised. Particularly with natural languagem, it is very hard to distinguish poison from “true” data.
Transfer learning attack: Model transfer leads to the possibility that what is being reused may be a Trojaned (or otherwise damaged) version of the model.
Transparency: It is easier to perform attacks undetected on a black-box system which is not transparent about how it works.
Error propagation: When ML output is input to a larger decision process, errors in the ML subsystem may propagate in unforeseen ways.
Input ambiguity: English, the main interface language for LLMs, is an ambiguous interface. Natural language can be misleading, making LLMs susceptible to misinformation.

These risks range from specific attacks from motivated threat actors, to subtle mistakes in engineering decisions made by the builder of an ML system. Both may have some negative consequence for the system that it might be worthwhile to consider. The risks in BIML are fundamental in nature, and address building blocks that are underlying most deep learning models. The ML lifecycle they published is a great way to organize our thinking about the full process of ML. Because of its generality, the BIML framework can very well be narrowed down and used for a particular machine learning system. For example, BIML took their 2020 work about generic ML[2] and applied it to generic LLMs [3].

Other ML security framework

BIML´s particular emphasis on the engineering part of machine learning contrasts MITRE ATLAS, which is a framework specifically listing various kinds of attacks. The OWASP top ten lists for machine learning and LLMs have a ,ore overlap with BIML. While the OWASP lists aren’t as extensive as BIML given their limitation of ten items, they are regularly maintained to incorporate new developments in the field.

Play testing

The last year has been spent sharing the game, and testing it with various participants, both university students as well as professionals in the industry. I have been running workshops where cross-functional teams with anything from management to tech have been working together to threat model a fictive system. The play tests suggest that the game is a promising way to start discussions about what can go wrong while building or using machine learning technology. The players reported that they were surprised at how engaging it was. Players with a non-technical background paired with technicals were able to threat model a system, and were able to get into the mindset of a security person.

Using it in practice

This game is one of many available tools that can enrich a product team’s threat modeling process. I think this game can be a good starting point for AI teams that would like to get starter with threat modeling. Playing will hopefully yield a nice and broad overview of what can go wrong in your system, and get you started thinking about AI more the way the people at BIML do. Because of its compatibility with Elevation of Privilege, I also think Elevation of MLsec is a good choice for teams that are already experienced with threat modeling, but need somewhere to start with all this new AI stuff. With the BIML lifecycle as a foundation for thinking about machine learning security, I think you will have a better time absorbing other frameworks, organizing their contents into the components of the generic ML lifecycle.

Intended audience

I have reflected on where such a game might be useful. In my opinion, it is very powerful to tackle design discussions in a cross-functional team with representation from various disciplines outside pure technological roles. Still, the following roles may find use for these cards as a way to get started with security engineering in an organization that is employing machine learning in some way:

Security practitioners can use this game to perform relevant threat modeling coaching with ML engineering teams or teams otherwise adopting AI.
ML practitioners and engineers may use this deck as part of their thread modeling process.
Software professionals integrating their “traditional software system” with an ML component can use these cards to get familiar with potential risks that come from integrating the ML component.

After using the game, it would be natural to explore the richer details of the BIML frameworks for ML in general [2], and for LLMs in particular [3].

The way forward

Moving forward, I am excited to see whether I can bring the game all the way into the heart of data science projects to get the developers started with threat modeling so they can reduce risk while building great things! I am also currently working on a second edition of the game that covers more ground, embeds some more modern developments, and fixes mistakes in the 1.0 version. I warmly welcome any feedback from people who have tried playing the game.

Elevation of MLsec on GitHub

References

Kowalski, S. J., Von Seth, E., & Zoto, E. (2023). Cs technopoly: A megagame for teaching and learning cybersecurity. Accelerating Open Access Science in Human Factors Engineering and Human-Centered Computing.
McGraw, G., Figueroa, H., Shepardson, V., & Bonett, R. (2020). An architectural risk analysis of machine learning systems: Toward more secure machine learning. Berryville Institute of Machine Learning, Clarke County, VA.
McGraw, G., Figueroa, H., McMahon, K., & Bonett, R. (2024). An architectural risk analysis of large language models: Applied machine learning security. Berryville Inst. Mach. Learn.(BIML), Berryville, VA, USA, Tech. Rep.
Shostack, A. (2014). Elevation of privilege: Drawing developers into threat modeling. In 2014 USENIX Summit on Gaming, Games, and Gamification in Security Education (3GSE 14).

CURATED CONTENT

Handpicked for you

Toreon Blog: Space Cybersecurity and Threat Modeling

State of Threat Modeling 2024-2025

Outer space is no longer just a realm of exploration. It has become critical infrastructure powering navigation, communications, weather forecasting and national defense. Yet the same systems that connect and protect us are increasingly exposed to cybersecurity risks. From GPS spoofing and satellite jamming to compromised supply chains and solar storms, threats to space assets can ripple across Earth.

In this article Robert Hurlbut examines the growing attack surface in orbit, the unique challenges of space system security and how frameworks like SPARTA and threat modeling can help safeguard our shared space future.

Read the blog

Threat modeling is steadily moving from a niche practice to an essential part of secure development. The first-ever State of Threat Modeling 2024–2025 report, based on insights from more than 60 organizations, highlights how teams are applying frameworks, tools, and collaboration to make it work in practice.

While STRIDE remains a cornerstone, most blend multiple approaches, and system diagrams have become a critical enabler. The report also uncovers where adoption stalls, how AI is beginning to play a role, and what maturity looks like for organizations leading the way.

MITRE Adds Mitigations to EMB3D Threat Model

MITRE announced the full release of the EMB3D Threat Model, which now includes essential mitigations mapped to security controls specified in the Industrial Automation and Control Systems standard.

Initially announced in December 2023 and officially released in May 2024, EMB3D is a framework offering information on the cyber threats targeting embedded devices used in critical infrastructure and other industries.

Threat modeling your generative AI workload to evaluate security risk

As generative AI models become increasingly integrated into business applications, it’s crucial to evaluate the potential security risks they introduce. A four-step threat modeling process: defining architecture, identifying threats, articulating them clearly, and assessing risks with mitigations, helps organizations systematically strengthen security. By following this approach, organizations can better equip themselves to maintain a high security bar as they adopt generative AI technologies.

You can now download our new, free DFD (Data Flow Diagram) template library for draw.io

We’ve created a ready-to-use library of Data Flow Diagram templates for draw.io to help you kickstart your threat modeling exercises. Whether you are mapping simple applications or complex architectures, these templates save time, ensure consistency, and make it easier to communicate security insights across your teams. And the best part: it’s completely free to download and use.

Once you start drawio, you can open the library through:
- File => Open Library from => Device … and select the downloaded library file.
- You should then see the DFD elements available in the left pane of the tool:

Download template

Our trainings & events for 2025

Book a seat in our upcoming trainings & events

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, Blue Team Con, Chicago, USA

4 -5 September 2025

AI Whiteboard Hacking, aka Hands-On 1-Day Threat Modeling Workshop, in-person, CyberSecurity Intersection, Orlanda, USA

10 October 2025

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, OWASP Global AppSec, Washington DC

4-5 November 2025

Book your spot

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, Blue Team Con, Chicago, USA

4 -5 September 2025

Book your spot

AI Whiteboard Hacking, aka Hands-On 1-Day Threat Modeling Workshop, in-person, CyberSecurity Intersection, Orlanda, USA

10 October 2025

Book your spot

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, OWASP Global AppSec, Washington DC

4-5 November 2025

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI

Cohort starting on 1 December 2025

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, NDC Security Manchester, UK

1-2 December 2025

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI

Cohort starting on 1 December 2025

Book your spot

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, NDC Security Manchester, UK

1-2 December 2025

Book your spot

Threat Modeling Insider Newsletter

Delivering the latest Threat Modeling articles and tips straight to your mailbox.

Threat Modeling Insider - June 2025 - Toreon

Laurent Dupont — Wed, 25 Jun 2025 22:00:00 GMT

45th Edition – June 2025

Welcome!

Welcome to this month’s edition of Threat Modeling Insider! In our featured guest article, Securing AI Agents: A Framework to Maximize ROI, Minimize Risk, Michael Novack explores AI agent threats, relevant mitigations, and strategies to focus your security efforts.

Meanwhile, on the Toreon blog, Sebastien Deleersnyder presents STRIDE-AI, our enhanced methodology for comprehensive AI threat modeling, along with our new 3-day AI threat modeling training.

But that’s not everything, so let’s dive in!

Read our previous newsletters

Welcome!

Meanwhile, on the Toreon blog, Sebastien Deleersnyder presents STRIDE-AI, our enhanced methodology for comprehensive AI threat modeling, along with our new 3-day AI threat modeling training.

But that’s not everything, so let’s dive in!

Read our previous newsletters

On this edition

Guest article
Securing AI Agents: A Framework to Maximize ROI, Minimize Risk, by Michael Novack

Toreon Blog
Mind the Gap: STRIDE-AI, by Sebastien Deleersnyder

Curated content
Threat Modeling as Code: Implementing STRIDE in DevSecOps

Curated content
Threat Modeling Guide for Software Teams

Tips & tricks
Securing HTTP based APIs

Training update
An update on our training sessions.

Guest article

Securing AI Agents: A Framework to Maximize ROI, Minimize Risk

In the evolving landscape of cybersecurity, AI agents present both opportunities and unique challenges. It’s crucial to understand the gaps in your cybersecurity program to effectively protect these advanced systems. This presentation will explore AI agent threats, relevant mitigations, and strategies to focus your security efforts.

The threats are novel enough according to the Cloud Security Alliance they made a new threat modeling framework called MAESTRO just for AI agents. We discuss if this is really needed.

What are AI Agents?

AI agents are advanced systems that utilize artificial intelligence to perform actions or make decisions, often with some degree of autonomy. They are designed to perceive their environment, process information, and take actions to achieve specific goals.

Understanding AI Agent Threat Modeling

The perspectives on the threat landscape for AI agents vary widely. Some believe existing cybersecurity programs are sufficient, while others express alarm about the inadequacy of current controls in an AI-driven world.

To highlight this disparity we will compare the AI agent threat modeling framework MAESTRO from the Cloud Security Alliance to a modified version of STRIDE.

We want to be clear that the point of this article is NOT to say MAESTRO is not needed. We acknowledge there are gaps with STRIDE which is why we have to modify it for an AI agent use case. We are using the widely-adopted STRIDE framework to illustrate how much of a gap MAESTRO is actually filling. Use what works best for your needs.

What is MAESTRO?

MAESTRO (Multi-Agentic System Threat Model) is a 7-layer reference architecture for agentic AI developed by the Cloud Security Alliance. This framework is designed to provide a structured approach to threat modeling for AI agents, addressing the limitations of traditional methods like STRIDE.

Why Does MAESTRO Exist?

Current threat modeling frameworks, like STRIDE, are not well-suited for AI agents. STRIDE, while a good starting point, doesn’t fully address the unique challenges posed by AI agents, such as adversarial attacks and risks associated with unpredictable learning and decision-making. MAESTRO provides a more tailored approach to threat modeling in this context.

A Modified STRIDE + ML

To better understand the gaps that AI creates in a cybersecurity program, let’s modify STRIDE so it can handle the unique challenges of AI agents. This is done by incorporating two new threat categories “Misunderstanding” and “Lack of Accountability” (ML), which can be employed.

Misunderstanding: This refers to models having undesirable assessments due to a lack of context or malicious intervention, leading to unexpected emerging behaviors.
Lack of Accountability: This occurs when actions are performed without clear governance or ownership, making it difficult to determine responsibility when issues arise.

Applying STRIDE + ML to AI Agents

Frameworks such as the OWASP Multi Agentic Threat Modeling Guide and the Cloud Security Alliance Agentic Threat Modeling Guide can be mapped into STRIDE + ML to provide a clearer view of AI agent threats. This mapping reveals that a significant portion of AI agent threats can be categorized using traditional STRIDE, but a notable percentage require the additional ML categories.

Source documentation:

AI Agent Threats and Mitigations

AI agent threats can be categorized, and mitigations can be mapped to these categories. Some threats can be mitigated using existing cybersecurity measures, while others require extending capabilities or implementing new mitigations.

We use the OWASP AI Agent threat taxonomy as it is more concise compared to the Cloud Security Alliance taxonomy. Almost all of the threats in the Cloud Security Alliance threat taxonomy can be categorized into the OWASP taxonomy.

Threats with Existing Mitigations:
- Spoofing (T9 – Identity Spoofing)
- Repudiation (T8 – Repudiation and Untraceability)
- Information Disclosure (T12 – Agent Communication Poisoning)
- Denial of Service (T4 – Resource Overload)
- Elevation of Privilege (T3 – Privilege Compromise)
Threats Requiring Expanded Mitigations: This category includes
- Spoofing (T13 – Rogue Agents)
- Tampering (T11 – Unexpected RCE and Code Attacks, T1 – Memory Poisoning)
- Denial of Service (T10 – Overwhelming HITL)
- Elevation of Privilege (T14 – Human attacks on MAS)
Threats Requiring New Mitigations: These are unique to AI agents
- Misunderstanding (T2 – Tool Misuse, T5 – Cascading Hallucinations, T6 – Intent Breaking & Goal Manipulation)
- Lack of Accountability (T7 – Misaligned & Deceptive Behaviour, T15 – Human Trust Manipulation)

Mitigation Options and AI-Specific Considerations

The cloud security alliance provides a good list of mitigations to focus on. Many of the mitigations should be part of any robust cybersecurity program regardless if AI is used or not. Below are the additional mitigations required specifically for AI systems.

Mitigation	Description	Example
Review internal governance and control frameworks	Train agents to be robust against adversarial examples.	During the model training process add in an example of prompts trying to get toxic responses about ageism. These should be labeled so the model knows that this type of prompt should not be answered.
Formal Verification	Use formal methods to verify agent behavior and ensure goal alignment.	Given the intent of an agent is only to provide information and analysis about a customer's bank account. Regularly audit that an agent is not attempting to do unexpected activity like transfer funds.
Explainable AI (XAI)	Improve transparency in agent decision-making to facilitate auditing.	Be able to explain why an insurance claim agent denied a specific customer's claim.
Red Teaming	Simulate attacks to identify vulnerabilities.	Researching the latest prompt injection techniques and seeing if they are successful or not on your system.
Safety Monitoring	Implement runtime monitoring to detect unsafe agent behaviors.	With a platform independent of the agent, verifying incoming prompts are not attempts of jailbreaking or trying to get the agent to do unethical actions like illegal or discriminatory behavior.

Focusing Your Efforts

The AI agent space is not as unique as many portray it to be, but we also cannot pretend that our existing cybersecurity control strategy is sufficient.

To effectively improve the ROI of your AI agent security efforts, focus on:

First look at your current capabilities to see how you can address ~⅔ of the AI threat space.
Look at the market for the emergent ~⅓ of AI threats, as these mitigations are being built now, so unlikely to exist with your current capabilities.

By understanding the nuances of AI agent threats and applying targeted mitigations, organizations can better protect these systems and maximize their return on investment in AI technologies.

CSA threats related to OWASP threats

The table below is a mapping of the threats defined in the OWASP AI Agent Threat and Mitigation Guide to the threats in the Cloud Security Alliance MAESTRO documentation. As most of the analysis of this blog is done using the OWASP threat taxonomy, I wanted to make sure you see how it relates to the CSA documentation, as it is the source of the MAESTRO threat modeling framework, and OWASP Mult-Agent Threat Modeling Guide references the CSA documentation.

OWASP AI Agent Mitigation Guide tries to only call out threats that are unique to AI Agents. (Section Reference Threat Model in OWASP AI Agent Threat and Mitigation Guide). It builds upon the existing OWASP documentation to reduce redundancy. Some of the CSA threats correspond to threats called out in other OWASP documentation.

STRIDE + ML	OWASP	CSA
Spoofing	T9 – Identity Spoofing	Agent Impersonation
T13 – Rogue Agents	Compromised Security AI Agents Compromised Agents
Tampering	T1 – Memory Poisoning	Data Poisoning Data Tampering Security Agent Data Poisoning
T11 - Unexpected RCE and Code Attacks	Input Validation Attacks
LLM03:2025 Supply Chain A06:2021-Vulnerable and Outdated Components API9:2023 - Improper Inventory Management	Supply Chain Attacks Compromised Framework Components Compromised Observability Tools Marketplace Manipulation Integration Risks Compromised Agent Registry Malicious Agent Discovery Agent Pricing Model Manipulation
A08:2021-Software and Data Integrity Failures	Compromised Container Images Infrastructure-as-Code (IaC) Manipulation Compromised RAG Pipelines Manipulation of Evaluation Metrics Poisoning Observability Data
Repudiation	T8 – Repudiation and Untraceability	Repudiation
Information Disclosure	T12 – Agent Communication Poisoning	Not called out as a unique threat, but in mitigations Secure Inter-Layer Communication
LLM02:2025 Sensitive Information Disclosure	Data Leakage Data Exfiltration Data Leakage through Observability Model Stealing Model Inversion/Extraction Model Extraction of AI Security Agents Membership Inference Attacks
Denial of Service	T4 – Resource Overload	Denial of Service on Data Infrastructure Denial of Service on Framework APIs Denial of Service (DoS) Attacks Resource Hijacking Denial of Service on Evaluation Infrastructure
T10 – Overwhelming HITL	No clear equivalent in CSA
Elevation of Privilege	T3 – Privilege Compromise	Lateral Movement Privilege Escalation Backdoor Attacks Orchestration Attacks Agent Identity Attack
T14 – Human attacks on MAS	No clear equivalent in CSA
Misunderstanding	T2 – Tool Misuse	Agent Tool Misuse Inaccurate Agent Capability Description
T5 - Cascading Hallucinations	Goal Misalignment Cascades Horizontal/Vertical Solution Vulnerabilities
T6 – Intent Breaking & Goal Manipulation	Agent Goal Manipulation
T7 – Misaligned & Deceptive Behaviour	Reprogramming Attacks Adversarial Examples Framework Evasion Evasion of Detection Evasion of Security AI Agents
Lack of Accountability	T15 – Human Trust Manipulation	Regulatory Non-Compliance by AI Security Agents Bias in Security AI Agents Lack of Explainability in Security AI Agents

OWASP threats justification for each STRIDE + ML category

STRIDE + ML	OWASP	Justification
Spoofing	T9 – Identity Spoofing	Attackers exploiting authentication mechanisms to impersonate AI agents or human users. By assuming a false identity, the attacker can then execute unauthorized actions under that guise.
T13 – Rogue Agents	An attacker might leverage identity spoofing techniques to impersonate a legitimate AI agent. By successfully authenticating as an existing agent or creating a new agent that masquerades as legitimate, the attacker can introduce a "rogue" agent into the system under a false identity. This rogue agent can then carry out malicious activities.
Tampering	T1 – Memory Poisoning	An attacker injecting malicious data or code into the memory space of an AI agent or the underlying system. This directly constitutes unauthorized modification, which is the core of the Tampering threat category.
T11 - Unexpected RCE and Code Attacks	The ultimate aim of an attacker exploiting an RCE vulnerability is to tamper with the system's intended state and behavior. By injecting and executing their own code, they are directly modifying how the AI agent operates, the data it processes, or the system it runs on.
Repudiation	T8 – Repudiation and Untraceability	This category deals with the ability of an attacker (or even a legitimate user) to deny having performed an action or transaction. Untraceability directly supports repudiation by making it difficult or impossible to link an action back to a specific individual or entity.
Information Disclosure	T12 – Agent Communication Poisoning	This category deals with the threat of an attacker gaining unauthorized access to sensitive information and potentially altering. You could make the case for this to be in Tampering as well. If communication between AI agents is not properly secured, an attacker eavesdropping on the network can gain valuable insights.
Denial of Service	T4 – Resource Overload	This category focuses on attacks that aim to make a system or service unavailable to legitimate users or processes. Resource overload, by its very nature, achieves this by consuming excessive system resources (CPU, memory, network bandwidth, storage) to the point where the AI agent or the underlying system can no longer function correctly or respond to legitimate requests.
T10 – Overwhelming HITL	The core of "Overwhelming HITL" is to flood the human operator with an excessive number of requests, alerts, or decisions, rendering them unable to effectively process and respond in a timely manner. This effectively makes the HITL component unavailable or significantly degrades its performance, leading to a denial of the intended service or oversight.
Elevation of Privilege	T3 – Privilege Compromise	This category focuses on the threat of an attacker gaining higher levels of access or permissions than they were originally intended to have. Privilege compromise is precisely the act of an attacker successfully obtaining these elevated privileges within the AI agent system or its underlying infrastructure.
T14 – Human attacks on MAS	In many scenarios, human attackers might not be exploiting technical vulnerabilities to gain new privileges. Instead, they might be leveraging their existing authorized access and the inherent trust the system places in human operators to perform actions that go beyond the expected or safe scope of their intended use.
Misunderstanding	T2 – Tool Misuse	An AI agent or user lacks sufficient context about a tool's function or is misled by malicious input, leading to a flawed assessment of its proper application. This flawed assessment results in the tool being used in unintended ways, causing unexpected and undesirable emerging behaviors in the AI system due to this fundamental misunderstanding of the tool's role or implications.
T5 - Cascading Hallucinations	An initial lack of context or a maliciously introduced falsehood leads an AI model to make an incorrect assessment, which then compounds in subsequent reasoning steps, generating further inaccurate outputs and unexpected behaviors. Each hallucination builds upon a prior flawed assessment, demonstrating a cascading "Misunderstanding" of the underlying information or task.
T6 – Intent Breaking & Goal Manipulation	A model's assessment of the user's intended goal is incorrect due to a lack of proper context or malicious prompting designed to mislead it. This "Misunderstanding" of the desired outcome results in the model exhibiting unexpected behaviors that deviate from or actively subvert the user's actual objective.
Lack of Accountability	T7 – Misaligned & Deceptive Behaviour	A model's assessment of appropriate action is flawed due to insufficient context regarding ethical guidelines or malicious prompting that manipulates its understanding of desirable behavior. This "Lack of Accountability" leads to unexpected emerging behaviors that are either not aligned with intended values or actively deceptive.
T15 – Human Trust ManipulationS	When a model's output, influenced by insufficient context or malicious prompting, leads a human to form an inaccurate assessment of the model's reliability or the situation it presents. This "Lack of Accountability" of the model's trustworthiness can result in unexpected and potentially harmful human behaviors based on that flawed assessment.

OWASP justify level of mitigations in the industry justification

Mitigation Availability	OWASP Threat	Justification
Existing	T9 – Identity Spoofing	Standard Identity Access Management (IAM) should be used
T8 - Repudiation and Untraceability	Standard logging methods will suffice.
T12 - Agent Communication Poising	There are established protocols to perform secure communication. If using new protocols they should have similar levels of cryptographic and authentication capabilities.
T4 - Resource Overload	There are robust mechanisms to throttle rate limits on a frequency and payload level. This just needs to be applied to APIs that utilize LLM capabilities.
T3 - Privilege Compromise	This calls out standard least privilege controls with strong authN/authZ systems and only granting the permission that is needed.
Expand	T13-Rougue Agents	We have ways to detect if infrastructure has been compromised. Now the activities a rogue agent would perform are more subtle, so these detection mechanisms should be improved.
T11 - Unexpected RCE and Code Attacks	Your infrastructure should already be limited to not execute arbitrary code. There are also some detection mechanisms for detecting and understanding code, but these capabilities will need to get better to comfortably full allow agents to generate and utilize code on the fly.
T1 - Memory Poisoning	The core mitigations are: - Session management to separate users memory and regularly clearing. - This in the expand category as normally memory management is more about performance than security.
T10 - Overwhelming HITL	We do have ways to mitigate DDoS attacks, but these are normally in the context of protecting technology workloads not people. That being said we can adopt some of those principles when routing traffic to people to resolve.
T14 - Human attacks on MAS	Apply a zero-trust mentality between agents. All actions should be fully validated if authorized and appropriate when communication between agents happen. As it might be hard to know what are valid actions we can apply a zero-trust mentality to get part of the way there.
New	T2 - Tool Misuse	The ecosystem of tools are actively evolving and the industry standards are being established. Things like MCP auto-discovery of tools is a new type of 3rd party risk. In theory an agent could use a new tool without anyone's knowledge. This a level of dynamic 3rd party management the industry has not done before.
T5 - Cascading Hallucionations	It will be hard to validate what is appropriate behavior for the agent as the potential scope output is too large. A new way of output validation and monitoring will be needed.
T6 - Intent Breaking & Goal Manipulationg	It will be hard to validate what is appropriate behavior for the agent as the potential scope output is too large. A new way of output validation and monitoring will be needed.
T7 - Misaligned & Deceptive Behavior	It will be hard to validate what is appropriate behavior for the agent as the potential scope output is too large. A new way of output validation and monitoring will be needed.
T15 - Human Trust Manipulation	It will be hard to validate what is appropriate behavior for the agent as the potential scope output is too large. A new way of output validation and monitoring will be needed.

CURATED CONTENT

Handpicked for you

Toreon Blog: Mind the Gap: STRIDE-AI

Threat Modeling as Code: Implementing STRIDE in DevSecOps

The security landscape is changing rapidly as AI integrates into every part of our lives – from smart assistants and recommendation systems to autonomous vehicles and vision technology. While traditional cybersecurity practices remain essential, AI-enabled systems introduce new types of threats that require a specialized approach. At Toreon, we’ve experienced this firsthand. That’s why we’re excited to launch STRIDE-AI, our enhanced methodology for comprehensive AI threat modeling, along with our new 3-day AI threat modeling training.

Read the blog

In the DevSecOps era, security is built into the development lifecycle, not bolted on after the fact. While traditional methods can slow delivery, Threat Modeling as Code (TMAC) enables automated, scalable, and continuous security assessments.

This article explores how to implement STRIDE, a Microsoft-developed threat classification framework, within DevSecOps. Learn how to automate threat modeling, integrate it into your CI/CD pipelines, and catch vulnerabilities early, before they reach production.

Threat Modeling Guide for Software Teams

Threat modeling helps teams understand how data moves through systems and spot risks that automated tools often miss. Instead of treating it as a one-time or standalone activity, teams should embed threat modeling into their development workflow through small, ongoing efforts. This article offers practical ways to get started, whether you’re focused on application development, infrastructure, or both. With rising cybersecurity threats and growing accountability, making threat modeling a regular habit is more important than ever.

Securing HTTP-based APIs

This UK NCSC guidance offers practical advice for securing HTTP-based APIs and is intended for technical teams involved in designing or building applications with API endpoints. Keep in mind that full security depends on performing threat modelling tailored to your specific architecture and use cases.

Learn more

Our Black Hat "Whiteboard Hacking" (hands-on threat modeling) training is going virtual!

While we’ll miss the in-person experience, this opens up the opportunity for more participants worldwide who might not be able to travel to Las Vegas.
Our training stands out due to its hands-on nature, small group work, collaboration, and exercises based on real-world situations.

This year, we’re covering hot topics including:

AI threat modeling, with exercises related to chatbots
Cloud, including storage and CI/CD pipelines
IoT, embedded devices, and systems

Robert Hurlbut will be delivering the training, so we’re looking forward to seeing you there!

Book your spot

Our trainings & events for 2025

Book a seat in our upcoming trainings & events

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, virtual, hosted by Black Hat USA, Las Vegas

2-5 August 2025

Threat Modeling Practitioner training, hybrid online, hosted by DPI

Cohort starting on 18 August 2025

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, Blue Team Con, Chicago, USA

4-5 September 2025

Book your spot

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, virtual, hosted by Black Hat USA, Las Vegas

2-5 August 2025

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI

Cohort starting on 18 August 2025

Book your spot

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, Blue Team Con, Chicago, USA

4-5 September 2025

Book your spot

Hands-on Threat Modeling AI, in-person, hosted by BruCON, Belgium

22-24 September 2025

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, OWASP Global AppSec, Washington DC

4-5 November 2025

Threat Modeling Practitioner training, hybrid online, hosted by DPI

Cohort starting on 1 December 2025

Book your spot

Hands-on Threat Modeling AI, in-person, hosted by BruCON, Belgium

22-24 September 2025

Book your spot

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, OWASP Global AppSec, Washington DC

4-5 November 2025

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI

Cohort starting on 1 December 2025

Book your spot

Advanced Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, NDC Security Manchester, UK

1-2 December 2025

Book your spot

Stay updated with high quality educational material every month.
No ads, no spam. Just pure learning.

Join 2000+ companies who learn about threat modeling every month!

Mind the Gap: STRIDE-AI - Your Clear Path to Understanding AI Vulnerabilities

Laurent Dupont — Wed, 25 Jun 2025 22:00:00 GMT

Your Clear Path to Understanding AI Vulnerabilities

Why Traditional STRIDE Isn't Enough for AI

The STRIDE threat modeling framework, originally created by Microsoft, has been fundamental to application security for many years. It classifies threats into six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. These categories remain relevant for AI systems. However, how these threats appear in an AI setting is significantly different, requiring a deeper understanding and customized countermeasures. AI systems aren’t just code; they learn, infer, and adapt, making them susceptible to unique attack vectors like data poisoning, adversarial examples, and prompt injection. This is where STRIDE-AI comes in, extending the classic framework to address the complexities of AI-specific risks.

Let’s examine how each STRIDE category applies, using real-world examples to highlight the urgency of this specialized approach.

STRIDE-AI: A Deep Dive into AI-Specific Threats

1. Spoofing: Impersonation in the Age of AI

Manifestation: Attackers impersonate users, AI services, or data sources to fool an AI system. Think deepfakes bypassing biometric authentication or forged sensor feeds misleading an autonomous system.
Real-World Example: The infamous case of criminals using AI to clone a CEO’s voice, authorizing fraudulent transactions worth hundreds of thousands of dollars. Another chilling example: a small piece of tape on a speed-limit sign caused Tesla’s image recognition to misread “35” as “85,” leading the car to accelerate dangerously. These are stark illustrations of AI spoofing – forged inputs accepted as genuine.
Our Approach: We emphasize strong authentication and validation. This goes beyond simple passwords, advocating for multi-factor authentication, cross-modal checks (like liveness tests for biometrics), and cryptographic authentication of AI model endpoints and data sources. Deepfake detection and anomaly detection are also crucial.

2. Tampering: Corrupting AI's Integrity

Manifestation: Unauthorized alteration of data or models in the AI pipeline. This includes data poisoning (injecting malicious data into training sets), model poisoning/backdooring (altering model weights), or adversarial input attacks (subtly manipulating inputs to cause incorrect outputs).
Real-World Example: In 2016, Microsoft’s Tay Twitter bot was quickly “poisoned” by users feeding it hateful inputs, forcing its shutdown. Similarly, placing tape on a road sign (tampering with the physical input) fooled a Tesla’s vision system. These incidents underscore how even subtle malicious modifications can compromise an AI’s integrity.
Our Approach: We focus on robust data and model integrity controls. This involves securing the entire AI training pipeline with trusted data sources, versioning, and validation (e.g., outlier detection for poisoned data). We also cover robust and adversarial training techniques and protect model files with encryption and digital signatures. Continuous monitoring of model performance is key to detecting tampering.

3. Repudiation: The Challenge of Accountability in AI

Manifestation: The lack of accountability or traceability in AI operations allows parties to deny actions. This occurs when insufficient logs or audit trails exist for model training, data access, or decision outputs.
Real-World Example: A deepfake audio clip used in a UK court to falsely incriminate someone, forcing the person to repudiate it – a clear demonstration of how AI can complicate accountability. Without proper logging, an autonomous agent making an unauthorized transaction could be easily denied, with “the AI” taking the blame.
Our Approach: We emphasize comprehensive AI audit logs that are tamper-evident, ensuring an immutable record. Digital signatures or watermarks on critical model outputs can prove authenticity, and clear accountability for AI actions is established by associating them with user or process IDs

4. Information Disclosure: AI as a Data Leakage Vector

Manifestation: Unauthorized access or exposure of sensitive data through AI systems (privacy leakage). Model reverse engineeringcontributes significantly here, enabling attackers to reconstruct sensitive training data or infer confidential insights from an AI model, essentially turning the AI into anunintentional data leakage vector. Attackers can exploit models to extract training data (model inversion, membership inference), or an AI system might inadvertently reveal confidential information in its responses.
Real-World Example: Researchers demonstrated how simple prompts could trick ChatGPT into revealing over 10,000 pieces of verbatim training data, including names, phone numbers, and addresses. Another instance involved attackers using membership inference to determine if a specific user’s data was part of a model’s training set, despite it being private.
Our Approach: We champion privacy-preserving AI techniques like differential privacy during training to reduce memorization. Strict access controls, output filters to redact sensitive data, and secure handling of trained models (treating them as sensitive assets) are also crucial to prevent information leakage.

5. Denial of Service (DoS): Crippling AI Availability

Manifestation: Disrupting an AI system or reducing its performance by overwhelming resources or exploiting worst-case behaviors. This can involve flooding an AI service with requests, creating expensive inputs, or even data poisoning aimed at availability.
Real-World Example:Sending prompts to Large Language Models (LLMs) that trigger extremely large outputs or infinite loops, leading to service slowdowns or crashes. The OWASP Top 10 for LLMs notes that overloading LLMs with resource-intensive tasks can disrupt service and significantly increase costs. For example, a single carefully crafted query to an LLM application has been shown to potentially result in a bill exceeding $1000 due to excessive token generation and processing.
Our Approach: We advocate for robust measures like rate limiting and input throttling on AI service endpoints. Input validation to reject unusually large or complex inputs, performance monitoring, and graceful degradation strategies are key to maintaining availability under attack.

6. Elevation of Privilege: Gaining Unintended Control via AI

Manifestation: Gaining higher privileges or capabilities via the AI system than intended. This can involve exploiting vulnerabilities in AI plugins to execute code on the host, or “jailbreaking” an AI’s safeguards to make it perform restricted actions.
Real-World Example: The “DAN” (Do Anything Now) exploit in ChatGPT, where users crafted prompts to bypass the model’s safety rules and generate disallowed content. Another example is an insecure AI plugin that allows malicious prompts to inject commands for execution on the server, leading to remote code execution (RCE).
Our Approach: We emphasize strict policy enforcement, segmentation, and sandboxing for AI systems. AI agents and plugins should operate with the least privileges possible within isolated environments. Robust input validation and prompt filtering are essential to neutralize malicious patterns and prevent the AI from becoming an attack vector for higher system access.

Beyond STRIDE-AI: A Holistic View

While STRIDE-AI forms the core of our methodology, we also integrate insights from other crucial frameworks:

NIST AI Risk Management Framework (AI RMF 1.0) provides comprehensive guidance for managing AI system risks throughout their lifecycle.
MITRE ATLAS (Adversarial Threat Landscape for AI): A knowledge base of adversary tactics and techniques specifically targeting AI systems.
OWASP Machine Learning Security Top 10 (2023) & OWASP Top 10 for LLM Applications (2024): Industry-focused checklists outlining common vulnerabilities and attack vectors in ML and LLM systems.
AI Incident Database (AIID): A valuable resource for understanding real-world AI failures and incidents, grounding our threat modeling in practical examples.

It’s crucial to remember that AI integration doesn’t negate the need for traditional application security (appsec). Since AI systems are often embedded within larger technological infrastructures, robust conventional security measures remain vital to protect the entire ecosystem.

Strengthen Your AI Security with Toreon's Expertise

Understanding these AI-specific threats is now essential. As organizations increasingly adopt AI, proactive and specialized security measures become crucial. At Toreon, we’ve created a 3-day AI Threat Modeling Training that provides security and engineering professionals with practical skills and a structured approach to identify, assess, and mitigate threats in AI applications.

Using our enhanced STRIDE-AI methodology, you’ll learn to systematically build robust security into your AI systems from the ground up. The training culminates in an engaging Red Team/Blue Team wargame, allowing you to put your newfound skills to the test in a realistic scenario.

Don’t let AI’s unique risks catch you off guard. Invest in your organization’s security in the future.

Ready to master AI threat modeling?

Explore our 3-day AI Threat Modeling Training today!

About the Author

Seba Deleersnyder is the editor of the Threat Modeling Insider newsletter and a passionate advocate for practical security solutions. With years of experience in the field, he continues to curate insights and build communities that make threat modeling more accessible to everyone.

Connect with Sebastien Deleersnyder

Threat Modeling: 5 Strategies to Sell Leadership on Security

Laurent Dupont — Thu, 08 May 2025 22:00:00 GMT

Picture this: your security team catches a major flaw before a product launch, saving $$$ and a PR nightmare. Still, many security leaders struggle with getting upper management to invest in threat modeling. In fact, a 2021 study found that 79% of security pros see threat modeling as a top priority, yet only 25% do it early in development. The gap is frustrating – leadership craves secure software but often balks at the upfront time or cost of threat modeling.

Sound familiar? You know threat modeling reduces costly late fixes, ticks compliance boxes, and ups customer trust – but how do you get the C-suite to see it? Maybe you’ve tried the usual slide decks and scare tactics, only to get lukewarm buy-in. What’s missing is influence – the psychology of persuasion, the art of speaking leadership’s language.

This post lays out 5 battle-tested strategies to influence leadership and get them on board with threat modeling. We’ll apply established influence techniques to threat modeling, drawing on a five-step framework for guiding leadership through change.By the end, you’ll have a conversational, no-fluff playbook to flip the script – from pleading for budget to inspiring action. Along the way, look for clear calls-to-action (CTAs) linking to resources like our Threat Modeling Training. Let’s dive in and unlock how to make threat modeling a no-brainer for upper management.

Ready to jumpstart change? Check out our Threat Modeling Training for actionable workshops and quick wins you can show leadership.

Learn More

1. Find Your Internal Champions (Identify Influential Leaders)

Every company has its movers and shakers – not just by title, but by who colleagues listen to. Our first tip: “Identify the influential leadership”. Start by mapping out formal decision-makers (CIO, CISO, Head of Development), and the informal influencers (that product manager everyone respects, the veteran architect with sway). These allies can become your internal champions for threat modeling.

Why It Works: Leadership is more likely to listen when the pitch comes from a trusted peer. If you can get, say, a DevOps manager excited about threat modeling’s efficiency boost, they’ll help sell it upstairs. It’s social proof in action – people follow the crowd, especially when the “crowd” includes respected voices.

Example: At one fintech company, a principal developer became the threat modeling advocate after seeing how it caught design flaws early. When she spoke up about saved development time and preventing a costly bug fix (640x cheaper to fix early!) at the next department sync, leadership took note.

Actionable Tip: Set up a casual brown-bag session to talk about a recent security win (or scare) and how threat modeling played a role. Invite a mix of roles – QA, Dev, Ops, Compliance. See who leans in with interest or questions. Follow up with them 1:1 to ask if they’d help champion a threat modeling initiative. This relationship-building mirrors “building relationships with those people” – a principle that emphasizes trust before influence.

Want to empower an internal champion fast? Our Threat Modeling Training isn’t just tech skills – we offer leadership-ready talking points to help you and your allies make the case.

Explore our Training Options

2. Speak Their Language: Align with Strategic Objectives

You might live and breathe security, but top executives juggle business goals, market competition, and compliance on top of security. To grab their attention, frame threat modeling as a solution to their problems. This aligns with the idea of connecting your approach to broader organizational goals—in our case, linking threat modeling to the key concerns and priorities that matter most to leadership.

Start with Why: Does your CEO obsess over market trust? Talk about how threat modeling prevents the next breach headline, protecting brand reputation. CFO worried about costs? Show data that fixing a vuln in production costs 30x more than fixing it in design – threat modeling is essentially a cost-saver. For compliance-focused leaders (think GDPR, ISO, or the new EU Cyber Resilience Act), emphasize threat modeling as a built-in way to meet regulations while simplifying audits.

Example: A healthcare startup’s CTO was lukewarm on threat modeling until the security lead reframed it: “This isn’t a security tax, it’s how we speed up HIPAA compliance checks and avoid reworking code later.” By linking threat modeling to avoiding regulatory fines and development churn, the CTO saw it as efficiency and risk management, not a hurdle.

Actionable Tip: Before your next pitch, list 3 top business objectives in your org (e.g., “Scale to new markets,” “Increase customer trust,” “Cut operational costs by X%”). For each, jot a note on how threat modeling supports it. Even better, gather any existing metrics or case studies: “After adopting threat modeling, Company X saw 15% faster security approvals, contributing to quicker market launches” (hypothetical example, but you get the idea!). Armed with this, your conversation shifts from technical jargon to business value – exactly what leaders want to hear.

3. Make It Personal: Align with Leaders’ Personal Goals

Beyond organizational goals, remember that leaders are individuals with personal drivers. It’s important to align change efforts with what matters to them personally. In practice, this means understanding what motivates your executives. Do they want to be seen as champions of innovation? Cost-saving leaders? Culture shapers?

Find the Hook: If a VP is eyeing a promotion, frame threat modeling as their chance to shine as a forward-thinking leader who introduced a practice that saved the company millions (yes, security can be a kingmaker!). If another leader is a tech enthusiast, pitch threat modeling as the “next cool thing” – it’s cutting-edge, it’s what top companies do (nobody wants to be left behind, and “everyone’s doing it” is a psychological nudge via social proof).

Example: Consider a CISO who deeply values mentorship and team development. By highlighting that threat modeling training will empower teams, making them less reliant on outside consultants (a common pain point) and more autonomous in decision-making, you appeal to that personal passion for team growth. Suddenly, threat modeling isn’t just a process – it’s part of their leadership legacy in building a stronger team.

Actionable Tip: Do a bit of homework on your execs. You likely know their professional KPIs, but what anecdotes have you heard in meetings? Did your CEO mention “customer trust” in the last town hall? Does your CIO talk about “sleeping better at night knowing X is handled”? Jot those down. In your proposal or chat, weave those exact phrases in: “I know keeping customer trust is huge for you – threat modeling directly feeds into that by preventing the kind of breach that loses users.” This isn’t flattery; it’s framing your ask in terms of what they already care about.

4. Use the Power of Story and Social Proof

Numbers are great, but stories seal the deal. Psychologically, humans are wired to remember and connect with stories more than spreadsheets. When persuading leadership, come prepared with relatable anecdotes and social prooffrom peers or industry leaders. This approach draws on a simple truth: influence is stronger when it taps into how people naturally think, feel, and make decisions.

Tell a “What If” Story: Paint a picture. What if we hadn’t threat-modeled our new app and missed a flaw? Imagine a critical vuln found days before launch, causing a month delay – and now picture the opposite: a smooth launch because threat modeling saved the day. Or recount a high-profile breach in your industry with a twist: “If only they’d threat modeled the system design, they might have caught that glaring hole.” These narratives create an emotional urgency beyond the cold facts.

Social Proof Matters: Highlight how industry leaders or competitors are already on the threat modeling train. “BigBank Corp just credited threat modeling for cutting security incidents by 40% this year” or “In our sector, companies that do threat modeling have a 20% faster compliance audit pass rate.” If you lack public examples, leverage quotes from respected sources: For instance, the CTO of Toreon emphasized that threat modeling “ensures vulnerabilities are recognized and remediated before they become a problem”. Knowing peers value something makes leadership more inclined to follow suit (nobody wants FOMO in business).

Actionable Tip: Craft a short case study or find a relevant one. Even a fictitious but realistic scenario works: “Last year, Team X spent 6 weeks fixing a late-discovered security flaw, costing €100K in dev time. Threat modeling those features upfront would have prevented that – saving time, money, and some grey hairs.” Share this story in an all-hands or a leadership 1:1. Also, look up industry reports or surveys to sprinkle in stats that back your story with evidence.

5. Lower the Barrier: Start Small and Show Quick Wins

One reason leadership hesitates on threat modeling? It sounds big – like an overhaul, expensive tools, training every dev, possibly slowing releases. So, make it small. Propose a pilot or a time-boxed trial where you can snag a quick win. This tactic is about reducing fear of change by proving it on a manageable scale.

The Foot-in-the-Door Technique: Psychologists note that getting someone to agree to a small step makes them likelier to agree to bigger steps later. So instead of “Let’s implement threat modeling everywhere forever,” try “How about a 2-week spike where one team threat models their next feature, and we see what value comes out?” When leadership sees a tangible result with minimal investment, it’s much easier for them to say, “Okay, let’s do more.”

What Does a Quick Win Look Like? It could be finding and fixing a significant security issue before code is written, preventing a costly fix later. Or achieving an “all clear” in a security review because threat modeling guided devs to build it right the first time. Or even just a dev team saying, “This actually helped us think deeper; we saved time in code review because we caught stuff earlier.” Those wins, however small, create positive momentum.

Example: A security architect in a SaaS company convinced leadership to let her run a one-day threat modeling workshop (with pizza – bribery by food works!). One product team identified 3 potential vulnerabilities in a planned feature and adjusted design on the spot. It barely impacted their timeline. That story was shared in the next exec meeting, and the CTO’s immediate response: “How do we roll this out more broadly?”

Actionable Tip: Identify a friendly team or a low-risk project to pilot threat modeling. Keep it informal and fun, if you can (gamify it, use sticky notes, whatever fits your culture). Document the outcome: what was found, how long it took, and any a-ha moments. Then package that into a one-page “success brief” and deliver it to leadership. It’s hard to argue with real, recent success inside your own company. It shows pragmatism (you’re not asking for the moon, just incremental improvement) and proof that threat modeling works for you.

To help you craft that pilot and rack up quick wins, consider our Threat Modeling Training – it’s designed to get teams hands-on experience fast, building confidence and results you can show off.

Get Started

Conclusion

Adopting threat modeling at scale can feel like pushing a boulder uphill – at first. But with these influence strategies, you’re not shoving alone; you’re enrolling others to help that boulder roll downhill. Let’s recap the game plan:

Find Allies: Don’t go it solo. Tap respected voices to champion threat modeling.
Frame Strategically: Map threat modeling to business goals (ROI, compliance, speed) so it’s a solution, not a cost.
Make It Personal: Speak to what individual leaders care about – their legacy, their fears, their aspirations.
Use Story & Proof: Facts tell, stories sell. Share powerful anecdotes and peer examples to make threat modeling real.
Start Small: Diminish the risk in leaders’ eyes by piloting and delivering a quick win, then scale up.

Overcoming Objections: You might still hear, “We don’t have time,” or “Won’t this slow us down?” Remind them that not doing threat modeling means risking far bigger delays and costs later. Show the stat about a prod vuln costing 640x more to fix – that usually raises eyebrows. If budget is a concern, emphasize that threat modeling isn’t about buying pricey tools; it’s about a mindset and practice that saves money. And if they worry about developer time, point out that integrating security early prevents fire-fighting later, freeing teams to innovate.

By now, you’re armed to turn skeptics into supporters. The key is a casual, confident conversation – you’re on their side, helping them win in their roles while making the company safer. Threat modeling isn’t a hard sell when it clicks that it’s really about smarter, smoother business.

Ready to make threat modeling a reality? Remember, you don’t have to do it alone. Bring in reinforcements, whether it’s data from this post, peers with success stories, or experts like us. We’ve helped many organizations break through the buy-in barrier.

Take the Next Step: If you’re looking for a structured way to get started and impress your leadership with immediate progress, check out our Threat Modeling Training. It’s designed to equip you (and your team) with the skills embed threat modeling into your culture. Let’s turn that uphill battle into a downhill roll – with you leading the charge!

Now go forth and influence – you’ve got this, and the benefits (secure, on-time projects; happy auditors; proud leadership) are totally worth it.

About the Author

Connect with Sebastien Deleersnyder

Threat Modeling Insider (NO INDEX)

Threat Modeling Insider - June 1 2026 - Toreon

Welcome!

Welcome!

In this edition

From Findings to Guardrails:

Closing the Threat Model Enforcement Gap

What Is The Enforcement Gap

Why the Gap Exists

What "Enforceable" Actually Means

A Practical Framework: Threat-to-Guardrail Pipeline

Stage 1: Structured Threat Outputs

Stage 2: Mitigation-to-Policy Translation

Stage 3: Architecture Fitness Functions

Stage 4: Threat-Derived Security Tests

Stage 5: Continuous Reconciliation

A Real-World Example

Getting Started: The 80/20 Path

The Cultural Shift

Conclusion

About the Author:

Handpicked for you

ENISA’s Secure by Design Playbook: Good Start, Hard Questions

Curated Content

NO SECURITY METER FOR AI

How easy is it to steal $10,000 from a locked phone?

Handpicked for you

ENISA’s Secure by Design Playbook: Good Start, Hard Questions​

Curated Content

NO SECURITY METER FOR AI

How easy is it to steal $10,000 from a locked phone?

TIPS & TRICKS

Consider realistic attacker personas

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

Upcoming Events/Webinars

Threat Modeling Insider - February 2026 - Toreon

Welcome!

Welcome!

In this edition

Should we generate complete threat models with LLM tools?

The growing landscape of LLM-based tools and methods

A scientic evaluation of the automated threat elicitation capability

Results and findings

Want to know more?

Handpicked for you

Toreon Blog: The Hidden Risk in Your Security Design: Managing Unknowns and Assumptions in Threat Modeling

Curated Content

Securing Agentic AI: New Risks Require New Safeguards

Agent Skills for Continuous Threat Modeling

Handpicked for you

Toreon Blog: The Hidden Risk in Your Security Design: Managing Unknowns and Assumptions in Threat Modeling

Curated Content

STRIDE-GPT As an MCP Server: A Composable Tool That AI Agents Can Use Autonomously

Global Risks Report 2026 - World Economic Forum​

TIPS & TRICKS

the C4 model for diagramming / aiming for a certain abstraction level

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

Upcoming Events/Webinars

Uncover Hidden Security Design Risks: Improve Threat Modeling & Reduce Assumptions

Exploring unknowns via the DICE framework

What are we working on?

What can go wrong?

What are we going to do about it?

The Assumption Register

Conclusion: Don’t Let Unknowns Be Your Downfall

About the Author:

Schedule a call

Upcoming Events/Webinars

Why Thinking Like a Defender Beats the Attacker Mindset

The Myth of the "Attacker Mindset"

Why a Defender Mindset Makes Threat Modeling Scalable for Developers

The GenAI Trap

Bridging the Gap: Practical Steps

Conclusion

ENISA’s Secure by Design Playbook: Good Start, Hard Questions

Global Risks Report 2026 - World Economic Forum