Most articles comparing STRIDE, PASTA, and LINDDUN read like a feature matrix: here are the categories, here are the stages, pick whichever matches your compliance obligation. That framing is close to useless, because the real question a working architect faces is not "which framework is best" but "which one earns its place on this system, given the time I actually have." The answer is rarely one framework, and it's almost never the most rigorous one.

This guide gives the working version. Where each framework holds up, where it quietly falls apart, and how to decide in the time it takes to sketch a data flow diagram.

The short answer

STRIDE is the default. For the large majority of systems — a service, an API, a component handling data — STRIDE is the right tool, because it is simple enough to run in your head during a whiteboard session and structured enough to be defensible afterward. Reach for something else only when STRIDE demonstrably fails to cover the risk.

PASTA is the framework everyone respects and almost no one runs to completion. Its instinct — start from business impact, not the architecture diagram — is correct and worth keeping. Its full seven-stage process is a consulting engagement, not a repeatable practice, and treating it as one sets a bar the program will never clear.

LINDDUN is the specialist. It exists for one job — privacy threats against systems handling regulated personal data — and it does that job better than STRIDE can, because the threat categories STRIDE lacks are exactly the ones privacy regulators care about. If the system holds personal data in scope of a privacy law, LINDDUN is not optional; if it doesn't, LINDDUN is overhead.

STRIDE: the default, and why

STRIDE gives six orthogonal lenses — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — and forces each one against every element of the system. Its strength is not sophistication; it's that the categories are memorable and mutually exclusive enough that a competent engineer can apply them without a manual. That accessibility is the whole game. A framework that requires a facilitator and a two-day workshop gets run once; a framework a senior engineer can run at a whiteboard gets run every design review.

Where STRIDE breaks is scale. Applied naively to a forty-service architecture with a hundred data flows, STRIDE produces a matrix nobody will read and no one will maintain. The failure is real, but the fix is not to abandon STRIDE — it's to stop applying it uniformly. Mature programs apply STRIDE at full granularity only to the elements that matter: the untrusted-to-trusted data flows, the components handling sensitive data, the trust boundaries an attacker would actually target. The rest of the architecture gets a lighter pass. STRIDE-per-element is a technique, not a mandate to model every element identically.

The second weakness is that STRIDE's categories are loose enough to hide gaps. Insider escalation lands under Elevation of Privilege and supply chain injection under Tampering, but only if the modeler thinks to look. A lazy STRIDE pass will miss both while producing a document that looks complete. This is why STRIDE benefits from a cross-check — a topic the state of threat modeling in 2026 covers in more depth — rather than being trusted as a standalone guarantee of coverage.

PASTA: the right ambition, the wrong operating model

PASTA — the Process for Attack Simulation and Threat Analysis — is the most intellectually complete framework in common use. Its seven stages move deliberately from business objectives, through technical scope and application decomposition, into threat analysis, vulnerability analysis, attack modeling, and finally risk and impact analysis. Read on paper, it is the framework you would design if you started from "what should threat modeling actually accomplish" rather than "what fits on a whiteboard."

The problem is operational, not conceptual. The later stages — particularly attack simulation — assume resourcing that few organizations sustain. Running stage-seven attack modeling and impact analysis properly, across a portfolio of systems, on the cadence that architecture changes demand, is a full-time function with a budget most security programs do not have. The predictable result is that teams adopt PASTA with enthusiasm, complete the first two stages, and let the rest lapse. What ships is a business-context document with a threat-modeling label on it.

That is not a failure worth mourning, because the valuable part of PASTA survives the abandonment. Its first stages encode a discipline STRIDE lacks: define business objectives and data criticality before touching the architecture. A team that starts every model by asking "what would it cost the business if this system were fully compromised, and which data drives that cost" is doing the most important thing PASTA teaches — regardless of whether stages three through seven ever run. Borrow the front end. Do not pretend the back end is a repeatable process.

LINDDUN: the privacy specialist

LINDDUN covers seven threat categories built specifically for privacy: Linking, Identifying, Non-repudiation (treated as a threat to the data subject rather than a security property), Detecting, Data disclosure, Unawareness and unintervenability, and Non-compliance. Those categories catch failures STRIDE has no vocabulary for — unnecessary data retention, linkability across datasets that were meant to stay separate, consent that is too coarse to be meaningful, third-party sharing without oversight. STRIDE will happily declare a system secure while it quietly violates every one of them, because none of these are confidentiality, integrity, or availability problems in the classical sense.

The framework maps cleanly onto data flow diagrams, which is why it composes well with STRIDE rather than competing with it: run STRIDE for the security threats against a flow, then run LINDDUN against the same flow for the privacy threats. The authors published LINDDUN-GO — a lighter, card-driven variant — precisely because the full method was too heavy for routine use, and LINDDUN-GO is the version most teams should reach for first.

The decision to use LINDDUN is not aesthetic; it is driven by regulatory scope. A system processing personal data subject to the GDPR, HIPAA, or the growing body of U.S. state privacy laws should carry a LINDDUN model for the components in scope. Attempting to bolt privacy threats onto a STRIDE model instead is a common shortcut and a visible one — an auditor or privacy engineer who knows the space will spot that the privacy categories were never actually modeled, only gestured at. The corollary matters too: for a system with no personal data, LINDDUN adds ceremony without adding coverage. Run it where privacy risk lives, and nowhere else.

When to use each

The framework question is really a system-classification question. Classify the system first; the framework follows.

System profile	Run	Complement with	Skip
A single service, API, or component	STRIDE	ATT&CK cross-check for exposed surfaces	PASTA, LINDDUN
Large distributed architecture	STRIDE, applied selectively to high-risk flows	ATT&CK; a higher-level view for the whole	Uniform STRIDE across every element
Regulated personal data (GDPR / HIPAA / state laws)	STRIDE and LINDDUN-GO	—	STRIDE alone
Business-critical / high-value target	STRIDE, with PASTA's business-impact framing up front	ATT&CK; deeper attack modeling on the crown jewels	Full seven-stage PASTA as routine practice
Internal, low-sensitivity system	Lightweight STRIDE at design time	—	Any formal model

Two things fall out of this table. First, STRIDE appears in almost every row — it is the base layer, and the other frameworks are additions for specific risk profiles, not replacements. Second, the most common real-world mistake is misclassification, not misframework: teams run heavyweight process on low-risk systems to look thorough, and run nothing on the regulated system because no one owned the privacy question. Get the classification right and the framework choice is nearly automatic.

MITRE ATT&CK: the cross-check, not a fourth option

ATT&CK belongs in this conversation only to be placed correctly outside it. It is not a threat modeling framework — it is a living catalog of documented adversary tactics and techniques, organized by what real attackers do rather than by what a system could suffer. Trying to "threat model with ATT&CK" produces a technique inventory disconnected from the system's actual architecture.

Used as intended, though, it closes STRIDE's biggest blind spot. Once a STRIDE-based threat register exists, walk the top ATT&CK tactics — Initial Access, Execution, Persistence, Lateral Movement, Exfiltration — and confirm the register contains a plausible threat for each that applies. A gap means either the system genuinely lacks that attack surface, which is rare, or the STRIDE pass missed a category, which is common. That is a fifteen-minute check that materially raises confidence, and it is the single most useful thing to add to an otherwise ordinary STRIDE model.

Where AI-assisted tooling fits

Framework choice is exactly the kind of judgment that automated tooling gets wrong when it's built badly and right when it's built well. Bad tooling ignores the classification question entirely — it emits a generic STRIDE checklist for every system, including the ones where the real risk is privacy or business impact. Good tooling starts from the system's data classification and exposure, applies the appropriate framework consistently, and factors in controls that already exist so the priorities reflect residual risk rather than a greenfield fantasy. The discipline that separates useful output from noise is the same discipline that separates a good human model from a bad one; the machine just makes the failure faster and more confidently worded.

For teams that want a framework-appropriate first draft on a specific system — STRIDE where it fits, privacy threats surfaced where personal data is in scope, mapped to NIST CSF 2.0 and CIS Controls v8 — Attack Path generates one in about a minute, as a starting draft to refine rather than a finished deliverable.

The bottom line

The framework you choose matters far less than most comparison articles imply. STRIDE handles the overwhelming majority of systems; LINDDUN covers the privacy gap STRIDE cannot; PASTA contributes a business-first instinct worth keeping and a process worth not pretending to run; ATT&CK sharpens whatever you produce. The decision that actually determines the quality of a threat model is upstream of framework choice — it's whether the system was classified honestly and whether the resulting model influences what gets built. A perfectly-chosen framework applied to a model no one reads is worth less than a rough STRIDE pass that changes one design decision. Pick the framework in a minute, and spend the saved time making the output matter.

---

This is part of a series on enterprise cybersecurity architecture. For a framework-appropriate threat model on a specific system — generated in about a minute, mapped to NIST CSF 2.0 and CIS Controls v8 — see Attack Path.