Threat modeling is one of the longer-standing and more widely recommended practices in application security, with Microsoft’s STRIDE dating back to a 1999 paper by Loren Kohnfelder and Praerit Garg, and guidance such as NIST’s Secure Software Development Framework (SSDF) calling on organizations to use threat modeling, attack modeling or attack surface mapping to assess the security risk of the software they build.
That said, recommending threat modeling and actually doing it continuously across an enterprise are two very different things, and the data shows most organizations are still threat modeling a fraction of their systems, with models that drift out of date shortly after they are created, all while AI is accelerating how fast software gets written and shipped.
In this piece I will be discussing why threat modeling matters, why it has historically been so elusive, how AI and AI-native frameworks such as MAESTRO are changing the equation, and how some teams, such as Resilient Cyber partner ThreatModeler, are tackling the problem of making threat models continuous and actionable across the entire enterprise.
So, let’s check it out!
Why Threat Modeling Matters
If you’ve been around cybersecurity for some time, you’ve inevitably heard of threat modeling, and as I wrote last year in my piece on MAESTRO, one of the clearer explanations comes from the Threat Modeling Manifesto, which describes it as analyzing representations of a system to highlight concerns about its security and privacy characteristics.
In practice it comes down to the four questions popularized by Adam Shostack, which ask what we are working on, what can go wrong, what we are going to do about it, and whether we did a good enough job. Even Adam is realizing threat modeling has to evolve for an AI paradigm, hence his upcoming book “Threat Modeling: Designing for Security in an AI World”.
It seems simple enough on the surface, and the Manifesto’s answer to who should threat model is simply you, and everyone, which puts developers and architects squarely in scope alongside security.
The value is in where it sits in the lifecycle. NIST’s SSDF ties this activity directly to Secure-by-Design, making the case that addressing security requirements and risks during design improves software security and development efficiency alike, which is a theme I covered in my piece Secure-by-Design Goes Prime Time.
During my conversation with the ThreatModeler team they made a similar point from the tooling side, which is that getting design right upstream reduces the volume of findings that SAST, DAST and other scanners surface downstream, and some have even explored using threat modeling to curate targeted SAST rules and cut down on noise.
As I said in my MAESTRO piece, threat models are great mental models for thinking about how systems and software can be exploited and, conversely, secured. Even so, the systems we’re modeling are now changing much faster underneath us than they used to.
I’ve written several times this year about the explosive growth in code volume, and GitHub’s latest Octoverse report shows commits across public and private repositories climbing from 12.9 billion to 34.3 billion in the year ending September 2026. There are great pieces discussing the modern SDLC with AI, such as Addy Osmani’s “The New Software Lifecycle”, which I shared earlier this year.
Just as the SDLC has changed due to AI, those of us in cyber need to update our approach to traditional and critical activities such as threat modeling to fit the new development paradigm our development peers now find themselves in.
Doing that well is hard, and threat modeling was already challenging in the traditional SDLC, when both volume and velocity were lower and slower than they are in the AI era.
Why It Has Been So Elusive
Despite all of that value, relatively few organizations threat model well or often, and part of the reason goes back to the method’s origins. Loren, the co-creator of STRIDE, later reflected on the method in his Threat Modeling Retrospective, acknowledging the most common criticism of it.
“The major criticism of threat modeling boils down to it being heavyweight: substantial training is required to practice the method effectively, capturing complex data flows accurately is time-consuming, and then considerable experience is needed to see and effectively prioritize the myriad potential threats identified.”
One of the creators of the most notable threat modeling methodologies is openly admitting how cumbersome it can be.
The community data shows that weight is still being felt.
The community-driven State of Threat Modeling 2024-2025 report from Threat Modeling Connect found that 93% of companies aren’t threat modeling all of their relevant systems, with 55% constrained by their threat modeling capacity, and on average companies dealt with 10 challenges either always or frequently. In the interest of transparency, the report is also published by IriusRisk, which is now part of ThreatModeler following its acquisition earlier this year.
The challenges themselves read like a list of what makes threat modeling feel manual and cumbersome, including the following.
52% citing an incomplete list of system components, data flows or assets
48% struggling to get the team that owns the system to dedicate resources to provide information
45% saying threat modeling is viewed as a one-off exercise
43% citing scaling
Staffing compounds it as well. The same report found 47% of companies have only 2-5 members of the security team supporting threat modeling, and 18% have a single person, which runs directly into what the Manifesto calls the “Hero Threat Modeler” anti-pattern, where the practice depends on the unique mindset of one individual instead of something everyone can do.
The ThreatModeler team put it in ratio terms during our conversation, noting that security teams are often supporting somewhere around 75 to 125 developers per security team member. Anyone in security knows that feels about right, and it has historically made not just threat modeling but broader AppSec and vulnerability management activities challenging as well.
There is also a visibility problem. The report found 52% of respondents don’t report threat modeling results to management regularly and only 25% have a threat model dashboard of any kind, so even where the work gets done, leadership often doesn’t see it.
It’s incredibly hard to demonstrate the value of an activity when you don’t have an effective way to present it to the executives and stakeholders required.
During my conversation with the ThreatModeler team, I shared an experience from my time in the federal space, where getting developers involved in threat modeling relied on executive force rather than a sustainable, scalable method. They often enjoyed the experience and walked away feeling like they learned from it, but it was also difficult to scale and sustain the activity.
I had an opportunity to see one of the best folks in the threat modeling space lead that effort in Robert Hurlbut, and even then I saw him run into some of the organizational constraints I mentioned above.
Krishna Bala, ThreatModeler’s Chief Technology Officer, made the point that static models simply can’t hold up when thousands of vulnerabilities are being disclosed daily, and I think that framing is right, as the snapshot-in-time model was always going to struggle once the pace of change outran the pace of review.
AI and the Velocity Problem
This is where AI enters the picture, and it cuts both ways.
Ben Oster, ThreatModeler’s Chief Product Officer, described the market as having turned upside down over the last nine months, with development cycles accelerating to the point where even UX teams are opening pull requests directly, and static architecture reviews and one-time threat models going stale after hundreds of PRs.
The broader industry trends line up with what Ben described. AI coding tools are quickly becoming the default for development teams, and the volume of changes flowing through pull requests has outpaced what human-paced security review was ever built to handle.
In that environment threat models drift out of date quickly, and the common practice of threat modeling once per release made more sense when releases were the natural unit of change.
I’ve written about this velocity problem throughout the year, such as in my piece AppSec in the Age of Agents, as well as my conversation with Katie Norton of IDC in Securing the Agentic SDLC, where we discussed how agentic coding tools are exposing the limits of human-paced security review.
On the other side of the coin, AI is also changing how threat modeling itself gets done. Threat Modeling Connect’s report, covering 2024, found only 7% of companies used AI regularly in threat modeling and 40% occasionally, and adoption has clearly grown since then as LLMs have become part of everyday security work, including AI built directly into threat modeling platforms.
ThreatModeler’s own launch materials cite Hanover Research data showing that for AI-generated code, threat modeling happens before the code is written 31% of the time, during 45% and after 24%.
I have been advocating throughout 2025-2026 that cyber needs to avoid being a laggard as we were with prior tech waves such as cloud and instead be an early adopter and innovator if we want to have any hope of keeping pace.
Using AI to help accelerate initial threat models as well as keeping them from going stale is a great example of this, with security using the technology to scale its own work, and it falls clearly on the “AI for security” side of AI’s dual nature.
AI-Native Frameworks and MAESTRO
AI is also changing what we’re building, with agents and multi-agent systems introducing threats that legacy frameworks weren’t designed for, and that is where AI-native threat modeling frameworks come in.
I wrote about one of these last year in a piece titled Orchestrating Agentic AI Securely, where I walked through MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome), created by Ken Huang and published by the Cloud Security Alliance (CSA).
At the time I joked that every threat modeling framework must have a mnemonic, and that some readers would be asking whether we really needed yet another framework (YAF).
MAESTRO’s creator Ken Huang’s argument was that frameworks like STRIDE, PASTA and LINDDUN leave gaps when applied to agentic AI, which he grouped into autonomy-related gaps, machine-learning-specific gaps, interaction-based gaps and system-level gaps, covering things such as agent unpredictability, goal misalignment, data poisoning, agent-to-agent interactions and supply chain risks for models and ML libraries.
MAESTRO addresses those gaps with a seven-layer reference architecture, spanning Foundation Models, Data Operations, Agent Frameworks, Deployment and Infrastructure, Evaluation and Observability, Security and Compliance as a vertical layer cutting across the others, and the Agent Ecosystem, along with cross-layer threats such as lateral movement and goal misalignment cascading from one agent to others.
What is relevant for this piece is that continuous threat modeling is baked into MAESTRO itself. One of its core principles is continuous monitoring and adaptation, the last step of Ken’s methodology is to continuously monitor for new threats and update the threat model as the system evolves, and he closes by framing MAESTRO as an iterative process.
The framework has also continued to gain traction, with OWASP’s GenAI Security Project applying it in their Multi-Agentic System Threat Modeling Guide, and CSA’s June 2026 paper AI Agents: Architecture and Control Plane expanding to a ten-layer reference architecture that CSA describes as the structural foundation for MAESTRO. I’ve also covered OWASP’s broader work in this area in my piece Agentic AI Threats and Mitigations.
This is also where the frameworks start to meet the tooling, as ThreatModeler includes CSA MAESTRO as one of its threat libraries for AI use cases, alongside CWE and MITRE ATT&CK.
I closed my MAESTRO piece by saying it of course is debatable whether we need another threat modeling framework, but that MAESTRO represents a great mental model and an additional tool for the practitioner’s toolbox. The harder question now is how to apply a layered framework like it continuously across hundreds of systems, instead of in a one-time workshop.
It’s been nearly 18 months since I originally wrote about MAESTRO, and it serves as a core part of how we think about threat modeling AI and agentic systems, and now the key is to make it actionable and iterative.
From Snapshot to Continuous
The idea that threat modeling should be continuous isn’t new. The Manifesto lists continuous refinement over a single delivery among its core values, along with valuing a journey of understanding over a security or privacy snapshot, and its principles call for threat modeling to align with how an organization develops software and follow design changes in manageable iterations.
OWASP similarly says threat modeling is best applied continuously throughout a software project, with models updated after new features ship, after security incidents, and after architectural or infrastructure changes.
The challenge has always been the effort it takes to actually do that, and this is where the ThreatModeler team’s framing resonated with me. Ben described the goal as threat models that live and breathe with the software, acting as a current system of record for secure design that keeps pace with each change.
In practice, that means meeting developers where they already work. ThreatModeler connects with tools such as Atlassian, GitHub, GitLab and Cursor, offers an IDE integration that compares what’s being built against a design baseline, and provides an MCP server so threat modeling activities can be automated as part of developer and agent workflows.
This reminded me of how some of the early AppSec innovators tried to move into developer workflows when it came to finding vulnerabilities and how some are now doing that for the agentic SDLC, looking to help developers using AI coding tools write more secure code.
One capability I found especially interesting in the demo was pull request gating, where ThreatModeler evaluates architectural changes in a PR for security impact before deployment, ignoring cosmetic ones such as a button color change, so teams can flag net-new components or threats for security review before the merge. The key here is to get the nuance right, so we don’t unnecessarily slow developers down and have them dread the tool or process, while also ensuring we function as a real risk governance mechanism and don’t let haphazard changes through without review.
I like this approach because it focuses on architectural change, which is where threat models actually go stale, as opposed to piling more findings onto developers who are already drowning in backlogs.
Ben was candid that how this integrates depends on organizational maturity, with more structured organizations tying into formal approval workflows while smaller teams push changes straight to developers for same-day resolution.
Krishna and I also discussed the need to embed continuous threat modeling directly into developer workflows and IDEs instead of forcing developers into yet another separate dashboard, and Taylor Wilson, a Solutions Architect at ThreatModeler, made the case that organizations need to move away from checkbox threat modeling toward a full lifecycle approach, which echoes the Manifesto’s value of a culture of finding and fixing design issues over checkbox compliance.
Generation Is Cheap, Context Is Hard
The obvious objection to all of this is that anyone can now point an LLM at a code repository and get a reasonable-looking threat model back in minutes, which raises fair questions about the need for a dedicated platform.
I raised this with Ben, and we agreed that initial threat model creation is now essentially free and fast with AI. Where we landed is that what’s hard is everything that comes after, including a persistent knowledge layer that captures the context behind security decisions, audit management, and handling change consistently over time.
Ben put this well in ThreatModeler’s Nexus launch announcement.
“Finding flaws in code is cheap now. A frontier model can do it in minutes. The hard part moved to confirming what actually matters, catching what is missing, and proving it to the board. That takes a governed framework and a system of record, not another prompt.”
He also warned during our conversation about AI being garbage in, garbage out when it lacks secure architectural baselines to work from, which is a risk I think practitioners should take seriously as they experiment with general-purpose LLMs for threat modeling. If we don’t provide the right context we will inevitably get low-quality threat models on the other side of things, which diminishes the practice entirely.
ThreatModeler’s answer is to pair a multi-agent system with a deterministic framework, so AI accelerates the work while the platform governs the outcome. When Taylor walked me through the platform, the automated decomposition identified components, data flows, protocols, trust boundaries and controls, and mapped them consistently to ThreatModeler’s knowledge base instead of letting the model make uncontrolled decisions.
Ben also described what he calls compounding intelligence, where a decision made in one threat model applies broadly across others, and persistent knowledge that captures the reasoning behind a decision and not only an audit log entry that it happened.
This is the same type of separation I’ve been advocating for throughout 2026, such as in my piece AI Code Security and the Independent Control Plane, where the argument was that the model writing your code shouldn’t be the one validating it.
What really resonated as well was how it all can come together for a broader enterprise risk context, which I’ll discuss below.
Context Doesn’t Scale by Itself
Even organizations that threat model well tend to do it one application at a time, which leaves models siloed and makes enterprise-wide risk visibility difficult.
ThreatModeler addresses this with the Secure Design Graph, which it describes as a living system of record that gives teams a shared foundation of security knowledge across applications, where components, their threats and their security requirements can be defined once and reused across models so teams build on established work instead of recreating it for each application.
Ben used the example of a single IAM threat model shared across the microservices of a consumer application, so when a small component changes, the platform can track how that change propagates across every model that depends on it.
On the reporting side, all of the data is available via API for GRC tools, Grafana, Prometheus and ArmorCode, and there is an official Wiz integration, which matters given the Threat Modeling Connect finding that over half of organizations don’t regularly report threat modeling results to management.
The platform also maps to compliance frameworks such as the EU Cyber Resilience Act (CRA), NIST, CIS, PCI, ISO and IEC 62443. As I’ve argued before, compliance does not equal security, but connecting threat models to compliance evidence is one way to make the work visible to the people funding it.
This approach makes threat models valuable not just individually but as an enterprise-wide risk view, tying the disparate threat models together to show how, in aggregate, the risks impact the organization’s posture as a whole.
A Look at ThreatModeler Nexus
The latest addition to the platform is NexusAI, which ThreatModeler launched in October as the agentic threat modeling experience inside ThreatModeler Nexus, putting the Secure Design Graph’s security context to work as an agentic partner while leaving the judgment calls to your team.
For those unfamiliar, ThreatModeler announced its acquisition of fellow threat modeling vendor IriusRisk in January 2026, bringing IriusRisk under the ThreatModeler umbrella, and ThreatModeler Nexus became generally available in June as what the company calls a governed agentic threat modeling platform.
Model creation is what everyone tends to demo, and Taylor built one in front of me from a diagram and a requirements document, with NexusAI identifying components, data flows, protocols, trust boundaries and controls, mapping them to ThreatModeler’s libraries and flagging uncertain matches for review.
What I was more interested in was how much work it takes to keep that model useful once the software changes, and NexusAI can run scheduled checks against connected sources, explain architectural changes and stage model updates for review, with an email when a check has run, so you still assess the changes but spend far less time tracking them down and updating the model.
The MCP connections work in two directions, with NexusAI drawing on repositories, documents and work items from sources such as GitHub, GitLab, Google Workspace, Jira and Confluence, and the Nexus MCP server making platform capabilities available to tools such as Claude, ChatGPT, Cursor and VS Code with Copilot, as well as CI/CD pipelines.
That means a developer can create or update a model from the tools they already use, and for me the appeal is that architects can retain oversight without having to do all of the modeling work themselves.
ThreatModeler says its knowledge base includes 3,500+ security requirements, 1,500+ cataloged threats, 3,000+ modeled components and 180+ compliance frameworks, and the company says it holds 14 patents (and 3 pending), including one covering its nested threat model capability.
On outcomes, ThreatModeler’s published case study with Charles Schwab reports a 50% reduction in threat modeling effort and a 10X improvement in model production after the firm moved away from a manual process.
Given my own background in DoD and federal civilian environments, ThreatModeler Nexus achieving FedRAMP Moderate authorization in September matters for federal adoption at a time when, in my recent experience, agencies are still doing threat modeling through manual ad hoc efforts, if at all.
Overall, the ThreatModeler demo showed me a more AI-native approach to this trusted and proven methodology for securing digital systems, with real attention paid to the work around model creation, including keeping models current, bringing modeling into existing workflows and giving experts something to review, which are the very areas that have historically kept threat modeling manual and difficult to scale and led many organizations to skip it entirely, despite knowing they should.
Where It Still Gets Hard
None of this makes threat modeling easy, and I’d be doing folks a disservice if I suggested otherwise. It does alleviate a lot of the traditional pain points of doing threat modeling iteratively and at scale.
Faster modeling alone also won’t fix the remediation side of the equation, since organizations still have to act on the findings their threat models surface.
The systems being modeled now include the agents building them as well, and AI coding agents acting outside of organizational risk policies is an emerging challenge in its own right.
There is also the human side, which hasn’t scaled like AI budgets, remains a real constraint for many organizations, and still involves a large educational component around threat modeling as a practice.
Threat Modeling Connect found 48% of companies frequently deal with participants unfamiliar with the threat modeling approach, and the Manifesto still values people and collaboration over processes, methodologies and tools, which is a good reminder that tooling is there to support the people doing the work.
And the last of the four questions, whether we did a good enough job, still requires someone to own the answer.
Threat modeling is not entirely automated, and leveraging AI does not solve all of our problems, but using AI as a force multiplier is a theme I’m a strong advocate for, and threat modeling remains one of the most fundamental and critical activities we can do to secure our systems, so leveraging AI to do so seems like a win in my book!
Closing Thoughts
Threat modeling has long been one of those practices everyone agrees we should be doing and few organizations manage to do continuously or at scale, largely because it has been heavyweight, manual and dependent on a handful of people.
AI is changing that, both by accelerating the software we need to model and by making it possible to generate and update models at the pace of development, while frameworks such as MAESTRO give us a mental model for the agentic systems we are now building.
The hard part has moved past generating the model, and the teams that get this right will be the ones who pair AI’s speed with governed context, enterprise visibility and a workflow developers actually use, which is the problem Resilient Cyber partner ThreatModeler is working to solve.
Stay resilient.