STRIDE vs PASTA vs LINDDUN: Choosing a Threat Modeling Methodology You Will Actually Run

Ask five security engineers which threat modeling methodology to use and you will get a comparison of frameworks. That is the wrong altitude. STRIDE, PASTA, and LINDDUN are not three competing answers to one question; they are answers to three different questions, and picking between them without noticing that is how teams end up with a methodology they admire and do not run.

The three questions, plainly:

• STRIDE answers: what can go wrong in this design?
• PASTA answers: which attacks matter to this business, and how would they actually unfold?
• LINDDUN answers: how does this system harm the privacy of the people whose data it processes?

Everything else in this guide follows from that distinction.

STRIDE: the diagram methodology

STRIDE came out of Microsoft in 1999, from Loren Kohnfelder and Praerit Garg, and it remains the default for a reason. It gives you six categories of threat (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) and one instruction: walk the elements of your system diagram and ask which categories apply to each one. Processes attract all six. Data flows attract tampering, information disclosure, and denial of service. Data stores, external entities, and trust boundaries each have their own profile. Microsoft's own documentation still describes the category-to-element mapping in these terms.

The strength is repeatability. Because threats anchor to diagram elements, two engineers modeling the same system converge on similar lists, coverage is measurable (which elements have been walked, which have not), and the exercise is teachable in an hour. The prerequisite is honest: you need a real data flow diagram, with trust boundaries drawn, not a marketing architecture slide. If your team cannot produce that diagram, that is the actual problem to fix first, and it is a bigger one than methodology choice.

The weaknesses are equally honest. STRIDE says nothing about which threats matter most; a spoofing threat on an internal metrics endpoint and one on your payment API rank identically until you add business context. The categories overlap (a successful tampering attack is often an elevation of privilege), which bothers purists and does not matter much in practice. And STRIDE has no opinion about privacy: a system that lawfully-collected data flows through in ways users never expected passes a STRIDE review clean.

PASTA: the risk methodology

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage methodology published by Tony UcedaVélez and Marco Morana in their 2015 book Risk Centric Threat Modeling. Where STRIDE starts from the diagram, PASTA starts from the business: define objectives, define the technical scope, decompose the application, analyze threats, find vulnerabilities and weaknesses, model attacks, and analyze risk and impact. The output is not a list of design flaws; it is an argument, traceable from business impact through attacker capability to specific attack paths, about which risks deserve money.

When PASTA is right, nothing else does its job. If you need to convince a board that a threat is worth a seven-figure remediation, a STRIDE spreadsheet will not do it; an attack simulation tied to revenue impact will. Regulated industries and high-value targets (payments, trading, critical infrastructure) get real value from stages that simulate how a motivated attacker chains weaknesses.

The cost is the honest problem. Seven stages is a program, not a working session. PASTA assumes threat intelligence input, attacker profiling, and analyst time that most product teams do not have per feature. Teams that adopt PASTA wholesale for routine design work tend to quietly stop threat modeling within two quarters, because every model is a project. The pattern that works is borrowing: PASTA's early stages, business objectives and impact, belong in your review intake (they are what a business impact analysis is), and the full simulation machinery is reserved for the systems whose tier justifies it.

LINDDUN: the privacy methodology

LINDDUN comes from the DistriNet research group at KU Leuven and is the only widely adopted methodology built for privacy rather than security. Its seven categories (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance) are walked over the data flow diagram much like STRIDE, which makes the two natural companions. The methodology, threat trees, and the lightweight LINDDUN GO card variant are published at linddun.org.

The point most teams miss: privacy threats are not security threats with a GDPR sticker. A system can be perfectly secure, every flow encrypted, every access authenticated, and still let an insurer link "anonymous" wellness data back to individuals. That is working-as-designed harm, invisible to STRIDE because nothing is broken. Notice also that non-repudiation, a goal in STRIDE's world, is a threat in LINDDUN's: sometimes users need plausible deniability. If your system processes personal data at any meaningful scale, or you run data protection impact assessments, a LINDDUN pass finds a class of problem nothing else in your toolchain is looking for.

The limitation is scope, and it is by design. LINDDUN does not replace a security methodology; it assumes one is already running.

The three side by side

How to actually choose

Notice what this decision path optimizes for. Not analytical depth; operational survival. The methodology that wins is the one still running in eighteen months, after the champion who introduced it changed jobs. In our experience the failure mode of threat modeling programs is almost never that the methodology missed threats. It is that the methodology asked for more effort than the organization would pay, so the organization stopped paying.

The methodologies you did not ask about

Four others show up in every comparison listicle, so here is the honest one-line verdict on each. DREAD is a scoring rubric for ranking threats you have already found, not a way of finding them; Microsoft moved away from it because scores varied too much between raters (more in the FAQ below). Attack trees are not a rival but a complement: when STRIDE surfaces a threat that worries you, an attack tree is a fine way to decompose how it would actually be achieved. OCTAVE operates at a different altitude entirely, assessing organizational risk rather than the design of a system, so it does not belong in this comparison even though it keeps getting put there. VAST and Trike you will encounter in vendor marketing and academic papers respectively; neither has the practitioner community, published threat trees, or tooling ecosystem of the three above, and choosing a methodology your next hire has never heard of is a real cost.

Three ways teams get this wrong

The comparison itself has failure modes, and they are more expensive than picking the "wrong" framework:

• Methodology shopping as procrastination. A quarter spent evaluating frameworks is a quarter of designs shipping unreviewed. The differences between running STRIDE adequately and running PASTA adequately are smaller than the difference between running something and running nothing. Decide in a week.
• Letting the tool choose. Teams buy a platform first and inherit whatever methodology it encodes, at whatever depth its workflow allows. Choose the question you need answered, then the methodology, then the tooling that runs it well; the reverse order is how you end up simulating attacks on a marketing site.
• Modeling once and calling it done. Every methodology here produces a snapshot. The system keeps changing after the snapshot, and a threat model whose diagram no longer matches production is worse than none, because it radiates false confidence. Whatever you run, decide what re-triggers it: a changed trust boundary, a new data flow, a new external integration.

What makes a methodology runnable

Whichever you choose, three properties decide whether it survives:

• It anchors to an artefact you already produce. STRIDE and LINDDUN work because the data flow diagram is (or should be) a standard output of design work. A methodology that requires new artefacts per model compounds its own cost.
• The output lands somewhere with consequences. A threat list in a spreadsheet is a finding; a threat mapped to a control, tracked to a live unmitigated count, with an owner, is a decision. If threats do not connect to your risk register and your build backlog, the model decays into documentation.
• A non-expert can contribute. If every model needs your most senior security architect in the room, the methodology's real capacity is that person's calendar. The analysis framework should be simple enough that engineering can draft and security can judge.

That last property is where tooling earns its place, and where we should disclose our interest: we build threat modeling software that runs STRIDE on a live diagram, with threats anchored to elements, controls mapped from your catalog, and an AI studio that drafts the model for a human reviewer to approve or reject batch by batch. The methodology stays the same; the cost of practicing it is what drops.

Pick the question you need answered, pick the lightest methodology that answers it, and spend the effort you save on running it everywhere. Coverage beats sophistication. It is not close.