Threat modeling occupies a strange place in the security architect's year. Everyone agrees it's foundational. Most frameworks require it. Auditors ask for it. And yet the median threat model produced in a large enterprise in 2026 still looks a lot like one produced in 2016 — a lightly-edited STRIDE checklist pasted into a Word document, reviewed once, referenced never.

This guide is not a restatement of what threat modeling is. You already know. What it tries to do is give a grounded read on where the practice actually stands in 2026: which methods have held up, which ones quietly got abandoned, how the new wave of AI-assisted tooling changes the workflow, and what a practical, audit-ready threat modeling program looks like when it's not just theater.

The quick summary

STRIDE is still the workhorse at the component and dataflow level, largely because it's simple enough that a senior engineer can run it in their head during a whiteboard session. PASTA is taught widely but rarely executed end-to-end — most organizations use its risk-centric ideas without committing to the seven-stage process. LINDDUN has gained real ground in the past three years, driven almost entirely by privacy regulation, and has become the default for anything touching regulated personal data. MITRE ATT&CK is increasingly used as a complement to STRIDE rather than a replacement: STRIDE tells you where threats exist; ATT&CK tells you how adversaries will actually chain them.

Meanwhile, the market of automated threat modeling tools has matured considerably, but the gap between "tool output" and "ARB-ready deliverable" remains wide. The interesting change in 2026 isn't that AI can generate threat models — it's that, for the first time, AI-generated threat models are crossing the quality threshold where a senior architect can use them as a real first draft instead of a curiosity.

What actually changed between 2020 and 2026

Three shifts, in order of impact.

Privacy caught up with security

A decade ago, threat modeling was a security exercise. Privacy was a legal concern that sat somewhere adjacent. GDPR, the California Privacy Rights Act, Quebec's Law 25, and the wave of state-level U.S. privacy laws changed that. By 2026, most serious enterprise architectures need to answer privacy threats alongside security ones, and those threats don't map cleanly onto STRIDE.

LINDDUN — Linkability, Identifiability, Non-repudiation (as a threat, not a property), Detectability, Disclosure of information, Unawareness and unintervenability, Non-compliance — was designed exactly for this gap. The framework is older than the regulatory wave it now serves, but it's only in the past three or four years that teams have started using it in anger. Healthcare, fintech, and any SaaS processing EU data should expect LINDDUN alongside STRIDE on every model.

The adversary model got harder

STRIDE implicitly assumes a motivated external attacker with some plausible access path. That's still the dominant model. But by 2026, most threat models also need to address two adversary classes that STRIDE handles awkwardly: compromised insiders with legitimate access, and supply chain compromise through trusted third-party components.

The first is not new, but it's gotten sharper. The second is almost entirely a post-2020 concern, accelerating after SolarWinds and the subsequent flurry of package-registry attacks. STRIDE can accommodate both — Elevation of Privilege covers insider escalation, and Tampering captures supply chain injection — but the categories are loose enough that a lazy model misses them. MITRE ATT&CK's explicit coverage of Initial Access, Supply Chain Compromise, and Trusted Relationship techniques has become a useful cross-check: run STRIDE per component, then walk the top ATT&CK tactics and confirm each has a corresponding threat listed.

The compliance frameworks got more specific

NIST CSF 2.0, released in 2024, and CIS Controls v8.1 both put more explicit weight on threat modeling than their predecessors. The CSF 2.0 Govern (GV) function, in particular, expects organizations to document a threat-driven basis for their security investments. Auditors increasingly want to see not just a threat model, but a mapping showing how each identified threat flows into a specific safeguard, and how that safeguard maps back to a framework subcategory.

That has two practical effects. First, threat models are no longer standalone artifacts — they're linked documents that feed risk registers, policy libraries, and investment decisions. Second, the expected level of specificity has gone up: "apply a WAF" no longer cuts it when the auditor wants to see which CIS v8 safeguard that WAF satisfies and how it was selected.

The frameworks, ranked by where they earn their place

No single framework answers every threat-modeling question. Here's the working breakdown most mature programs have settled on by 2026.

STRIDE: the default for component-level analysis

STRIDE remains the right choice when you're modeling an individual component, service, or data flow. Its power is that it gives you six orthogonal lenses — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — and forces you to consider each one for every target. Most real threats fall cleanly into one or two categories.

STRIDE struggles when the system gets large. A microservices architecture with forty components and a hundred data flows produces a STRIDE matrix that nobody will read, let alone maintain. The answer in 2026 is not to abandon STRIDE but to apply it selectively: model the untrusted-to-trusted data flows and the components handling sensitive data at STRIDE granularity, and use a higher-level framework for the architecture as a whole.

PASTA: the right ambition, the wrong execution

PASTA — Process for Attack Simulation and Threat Analysis — is intellectually the most complete framework in the field. Its seven stages move from business objectives through technical decomposition to attack simulation with impressive rigor. In practice, almost no one runs PASTA end-to-end. Stage-seven attack simulation alone can consume more consulting hours than most organizations budget for the entire threat modeling exercise.

What survives of PASTA in most programs is the spirit of its early stages: start with business objectives and data sensitivity, not with the architecture diagram. That instinct — business context first, technical threats second — is the right one, whether or not you run the full PASTA process.

LINDDUN: the privacy specialist

LINDDUN is what you run when the system handles regulated personal data. It maps cleanly onto data flow diagrams (the authors published LINDDUN-GO specifically for faster application), and its seven threat categories catch issues STRIDE silently misses: unnecessary data retention, insufficient consent granularity, third-party data sharing without oversight.

If you're subject to GDPR, HIPAA, or any of the major state-level U.S. privacy laws, you should expect to produce a LINDDUN model for systems in scope. Don't try to bolt privacy threats onto STRIDE — the categories don't translate, and auditors who know privacy will notice.

MITRE ATT&CK: the adversary cross-check

ATT&CK isn't strictly a threat modeling framework — it's a living catalog of documented adversary tactics and techniques. But as a cross-check on STRIDE, it's become indispensable. Once you have a STRIDE-based threat register, walk through the top ATT&CK tactics — Initial Access, Execution, Persistence, Lateral Movement, Exfiltration — and confirm you have a representative threat in each one. If you don't, either the system genuinely doesn't have that attack surface (rare) or you missed something.

Everything else

Trike, VAST, OCTAVE, Attack Trees — each has a niche, none has meaningful market share in 2026. Attack trees are still a useful visualization technique inside a model regardless of framework; we use them in our generated outputs for exactly that reason. The rest have largely lost ground.

Where AI-assisted tooling actually helps

Automated threat modeling has been promised for at least a decade. Most of that decade, what existed was rule-based engines that produced uniformly mediocre output: too generic to be useful, too confidently worded to flag the fact.

The 2024–2026 wave of large language model tooling has changed this meaningfully. Done badly, it's still slop — a machine-generated checklist of generic threats, padded with plausible-sounding controls that don't match the actual system. Done well, it produces a first draft that a senior architect can refine in an hour instead of building from scratch over a day.

The quality question is entirely a prompt engineering question. Three things separate useful AI-generated threat models from the noise:

Grounded decomposition. The model needs to understand the actual architecture before it starts enumerating threats. That means a structured intake — components, data flows, trust boundaries, data classifications — not just "describe your system." Skip this step and you get generic output, every time.

Framework discipline. A good generator applies one framework (or a documented combination) consistently, rather than producing a random mix of STRIDE-flavored and ATT&CK-flavored threats. Inconsistent framework application is the clearest tell of unreliable output.

Existing-controls awareness. A threat that's already mitigated by an existing control shouldn't appear in the top-priority list. Most automated tooling treats each assessment as greenfield and ignores what the organization already has deployed. A model that factors in existing controls produces dramatically more useful prioritization.

Where AI assistance still falls short: genuinely novel architecture patterns. If your system is sufficiently unusual — an experimental cryptographic protocol, a novel privacy-preserving computation, a custom consensus mechanism — a language model will either over-rely on pattern-matching to familiar architectures, or invent threats that don't apply. The failure mode is confident plausibility. Senior review is not optional.

What a working threat modeling program looks like in 2026

For teams moving from ad-hoc to mature, here's the shape we recommend.

Threshold the effort

Not every system warrants a full threat model. A rough tiering we've seen work:

• Tier 1 — any system handling regulated data (PII, PHI, PCI, classified): full STRIDE + LINDDUN where privacy applies, reviewed annually and at each major architecture change.
• Tier 2 — internet-facing systems, systems handling internal confidential data: STRIDE-only, reviewed every 18 months or at architecture change.
• Tier 3 — internal-only, non-sensitive: lightweight review at design time, no formal model required.

This tiering cuts effort dramatically without missing the high-risk systems. Most organizations over-invest in Tier 3 and under-invest in Tier 1.

Integrate with the architecture review board

Threat models that live in a shared drive and never surface again are worse than useless — they create a compliance artifact without a compliance outcome. In mature programs, every architecture review board submission includes the relevant threat model excerpt, and the ARB evaluates whether high-priority mitigations have been designed in. This is where threat modeling stops being documentation and starts being a control.

Make the output usable

The most valuable thing a threat model produces is not the threat list — it's the prioritized mitigation roadmap with clear effort estimates and owners. If your threat model doesn't end with "these three things get done in the next 30 days, these five in the next 90," it's not actionable. This is the single biggest gap between threat modeling theater and threat modeling that moves the needle.

Version and diff

Systems change. Threat models that don't change with them decay fast. In 2026, the expectation — and increasingly the audit expectation — is that threat models are living artifacts tied to the system's architecture repository, re-evaluated when the architecture materially changes, with a clear diff showing what threats are new or resolved.

This is one of the areas where modern tooling helps most: re-running a model against an updated architecture description takes minutes, not hours, and produces a visible delta. Teams without tooling support often let this lapse, and the model goes stale within a year.

Where to start if you're behind

If your organization's threat modeling practice is closer to "nobody has done this in a while" than "well-oiled program," here's the fastest path to a defensible baseline.

First, inventory the Tier 1 systems. Not all of them — the top five by risk. These are the systems where a breach would have existential consequences: customer-data-holding production systems, revenue-generating externally-facing systems, systems subject to regulatory examination.

Second, produce a STRIDE model for each of those five. The first one will take longer than you expect — plan on a day, possibly two, with a senior architect. The second will take four hours. By the fifth, you'll have a template.

Third, map the top three mitigations per system onto your existing controls and planned investments. The goal is not comprehensive coverage — it's to demonstrate that the program is threat-driven, with traceable mappings from identified risks to funded controls. Auditors and boards want to see the chain of reasoning, not every possible threat.

Fourth, and only once you have five real models in hand, consider automation. Starting with tooling before you understand what good output looks like leads to exactly the generic-slop problem discussed earlier. Once you have a sense of the quality bar, the right tooling accelerates your program enormously.

The honest bottom line

Threat modeling in 2026 is more useful than it was in 2016, and harder to fake. The frameworks are mature, the integrations with compliance frameworks are tighter, and the tooling has finally crossed the threshold where it can produce real first drafts rather than just gestures at them.

What hasn't changed is that a threat model's value comes from the thinking it forces, not the document it produces. The document is the artifact; the analysis is the point. Any tooling, process, or framework that loses sight of that tradeoff — that optimizes for speed of producing artifacts at the cost of the underlying analysis — is making the wrong trade.

The organizations that will get value from threat modeling in the next few years are the ones that treat it as a continuous practice tied to architecture decisions, not an annual ritual tied to audit cycles. Framework choice, tooling choice, and even the specific methodology matter much less than whether the practice actually influences what gets built.

---

This is the first in a series on enterprise cybersecurity architecture. For hands-on threat modeling on a specific system — generated in 60 seconds, mapped to NIST CSF 2.0 and CIS Controls v8 — see Attack Path.