Threat Modeling: STRIDE, PASTA & Process (2026)

Threat modeling is a structured way to look at a system through an attacker's eyes before the attacker does: you map what you are building, work out what can go wrong, decide what to do about it, and check that the fixes actually hold. Done at design time, it catches security flaws while they still cost pennies to fix, rather than the millions an average breach costs after launch. This guide covers the four questions every threat model answers, the process step by step, the methodologies you will actually reach for (STRIDE, PASTA, DREAD, VAST, and attack trees), the tools worth using, and a simple template to run your first session.

Updated: September 2026. Reflects the Threat Modeling Manifesto's four-question framing, the current OWASP methodology, model-as-code practices, and the 2026 tooling landscape (OWASP Threat Dragon, Microsoft Threat Modeling Tool, IriusRisk, pytm, Threagile).

The short answer

The line to remember: threat modeling finds design flaws (a missing authorization boundary, an unsafe trust assumption, an unlogged critical action) that scanners and pentests, which examine code that already exists, cannot see at the whiteboard stage.

The four questions

Strip away the framework branding and threat modeling is a design review with an adversarial lens. The durable core, formalized by the Threat Modeling Manifesto and taught by Adam Shostack, is four plain questions:

1. What are we working on? Diagram the components, data flows, and trust boundaries.
2. What can go wrong? Enumerate the threats against each component and flow, using a framework like STRIDE so you are not staring at a blank page.
3. What are we going to do about it? Decide on a mitigation for each threat that matters, and record the risks you knowingly accept.
4. Did we do a good enough job? Review and validate that the mitigations were built and tested, and that no threat was quietly dropped.

These questions are methodology-agnostic. They work whether your team uses sticky notes, a whiteboard, a formal tool, or code-based models, and everything below is a way of answering them more rigorously.

The threat modeling process, step by step

Most methodologies, whatever their branding, follow the same four phases, mapped directly onto the four questions. These threat modeling steps stay the same whether you spend an hour or a week on them.

Step 1: Decompose the system (what are we working on?)

Map the system before you hunt a single threat. Define the scope so the exercise does not sprawl, identify the assets worth protecting (sensitive data, keys, critical services), and draw a data flow diagram showing how data moves between processes, data stores, and external entities. Then mark every trust boundary, each point where data crosses from a lower-trust zone to a higher-trust one, such as user input hitting your API or a call to a third-party service. Trust boundary crossings are where attacks start, so they are where you will concentrate.

Step 2: Identify threats (what can go wrong?)

Walk each element and boundary and ask what an attacker could do: impersonate, tamper, read data they should not, or take the service down. This is where a methodology earns its keep, giving you categories to brainstorm against. STRIDE (below) is the most common choice; you apply its six prompts to each element rather than relying on inspiration.

Step 3: Rank and mitigate (what are we going to do about it?)

Not every threat deserves equal effort. Rank each by likelihood and business impact (a lightweight scoring model like DREAD, or CVSS-style severity plus exploitability, works here), then choose a response for each. Adam Shostack's four responses are the standard vocabulary:

• Mitigate — add a control (encryption, MFA, input validation, authorization checks) to reduce the risk.
• Eliminate — remove the feature or component causing the threat.
• Transfer — shift responsibility elsewhere (a provider, an insurer, the customer).
• Accept — knowingly live with the risk, with a named owner and documented reasoning.

Every mitigation should land as a real ticket in the same backlog as feature work. A risk accepted without a name attached is how findings quietly vanish.

Step 4: Validate (did we do a good enough job?)

Confirm the mitigations were actually built and tested, cross-reference the mitigation list against the original threat list so nothing was dropped, and update the model whenever the architecture changes. A model that ends in a list of fears nobody acted on is wasted effort. This is also where testing belongs: threats you mitigated should map to checks that stay on permanently, from CI security tests to a penetration test scoped from the model.

Data flow diagrams and trust boundaries

The data flow diagram (DFD) is the foundation of the whole exercise, and it needs only a handful of elements:

• Processes — components that act on data (services, functions, jobs).
• Data stores — databases, caches, file systems, queues.
• External entities — actors outside your control (users, third parties, partners).
• Data flows — how data moves between the above, including the protocol and whether it is encrypted.
• Trust boundaries — the dotted lines where data crosses between trust levels. Every crossing is a candidate threat.

If your first DFD takes longer than ten minutes to sketch, your scope is too big; model per feature, not per product. Whiteboarding is fine to start, but keeping the diagram in a tool or as code makes it easy to store, review, and update.

Threat modeling methodologies compared

STRIDE and PASTA get the most attention, but they are not the only frameworks, and they do different jobs. Choosing well is less about which is "better" and more about who needs to act on the output.

Mature teams often mix them: run STRIDE inside a sprint, score the results with DREAD or CVSS, and roll the findings up through a PASTA-style business lens for leadership.

STRIDE: the technical baseline

The STRIDE model, developed at Microsoft in the late 1990s, is the most widely adopted threat modeling approach in 2026 because the STRIDE methodology maps onto questions developers can actually answer about their own designs. It is a mnemonic for six threat categories, each the violation of a desirable security property. You walk each element of your DFD and ask which of the six apply.

STRIDE's strength is that it makes threat enumeration mechanical: a developer with no security background can walk a diagram element by element and produce a respectable threat list. Its weakness is volume without ranking, it tells you a threat exists, not whether anyone would bother, so you still need a prioritization pass. As a high-level process, STRIDE pairs well with MITRE ATT&CK and CAPEC for real attacker techniques and with CWE data to connect threats to concrete weaknesses.

PASTA: the risk-centric methodology

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric methodology that replaces STRIDE's per-component enumeration with a flow from business objectives down to risk-weighted countermeasures. The seven stages are:

1. Define objectives — business context, compliance drivers, risk tolerance.
2. Define the technical scope — system boundaries, technologies, dependencies.
3. Application decomposition — data flows, trust boundaries, components.
4. Threat analysis — threat intelligence, likely attacker profiles, historical incidents.
5. Vulnerability and weakness analysis — mapping to known weakness classes (CWE, CVE).
6. Attack modeling — attack trees and attack chains to model how an adversary reaches the objective.
7. Risk and impact analysis — business impact, prioritization, and countermeasure selection.

PASTA's defining feature is that it treats business risk as the organizing principle, which makes its output legible to leadership in a way STRIDE's is not. The trade-off is cost: a faithful PASTA engagement on a large system is measured in days or weeks and involves real threat-intelligence work, so teams reserve it for high-stakes systems (payment platforms, identity providers, anything handling restricted data). Many organizations run STRIDE per feature and a PASTA-grade analysis on the crown jewels once a year.

DREAD: scoring and ranking

DREAD is not a way to find threats; it is a way to rank the ones you already found. It scores each threat across five factors:

• Damage — how bad is a successful attack?
• Reproducibility — how reliably can it be repeated?
• Exploitability — how much effort and skill does it take?
• Affected users — how many users are hit?
• Discoverability — how easily can an attacker find it?

You rate each factor and combine them into a comparative score. DREAD is quick and easy to teach, which keeps it in use, but its scoring is subjective (two engineers often rate the same threat differently), and Microsoft itself moved away from it. Treat the DREAD threat model as a lightweight ranking aid, and prefer CVSS plus real exploitability where you need defensible, consistent numbers.

Attack trees

An attack tree is a hierarchical way to represent how an attacker could reach a defined goal. The goal sits at the root, and each branch is a step or alternative path toward it, with leaves as the concrete actions an attacker would take. Attack trees are excellent for reasoning about a single high-value target in depth: comparing alternative attack paths, identifying prerequisites, mapping controls to specific steps, and supporting tabletop exercises. They slot naturally into PASTA's attack-modeling stage, where the tree visualizes how an attack unfolds while PASTA supplies why it matters and whether it is viable.

Threat modeling tools

You can threat model with a whiteboard, but tooling helps you store, share, and maintain the model. The essentials in 2026:

The tool matters less than the habits around it. A markdown file plus OWASP Threat Dragon can support a world-class practice, while a full commercial stack can support a performative one. To populate the "what can go wrong" step with real-world threats, pair your tool with curated references like OWASP's threat libraries and MITRE ATT&CK rather than only theoretical brainstorming.

Threat modeling in the SDLC and DevSecOps

Security threat modeling delivers the most value shifted left, at design time, before code exists, because that is when the cheap fixes are still available. In a modern DevSecOps pipeline the pattern that survives is small and recurring rather than a heavyweight ceremony:

• Model per feature or epic, whenever a change touches a trust boundary (a new endpoint, integration, data category, or auth path). Thirty to sixty minutes, the engineers building it plus one security-minded facilitator.
• Treat the model as code. Store the DFD and threat list as JSON or YAML in the repo (Threat Dragon, pytm, Threagile), and review changes in pull requests like any other artifact. A CI check can flag when a design-touching file changed but the model did not.
• Map threats to tests. Each mitigated threat references the test that verifies it (for example, an IDOR threat maps to an integration test that attempts the attack and asserts it fails). This turns the model into an executable contract rather than a document, and is where automation genuinely changes the economics.

Be honest about the limits: fully automated threat modeling, where the pipeline generates the model and humans only review it, does not exist at useful quality in 2026. What works is automating the inputs and outputs of human modeling, with the design insight still coming from people who understand the system. Threat modeling is also the practice that generates the risk-assessment and control evidence that SOC 2 and ISO 27001 auditors expect, so it does double duty for compliance.

A simple threat modeling template to start

You do not need a 40-page document. A usable first session fits on one page:

1. Scope. One sentence on the feature or system under review.
2. Diagram. A whiteboard-grade DFD with trust boundaries as dotted lines (ten minutes maximum).
3. Threat table. For each trust-boundary crossing, walk the six STRIDE categories and record any that apply. Columns: element, STRIDE category, threat, likelihood, impact, response (mitigate / accept / transfer / eliminate), owner, ticket.
4. Validation. Note the test, scan rule, or pentest scope that will confirm each mitigation.

Keep the artifact to that diagram plus the table, put every mitigation on the sprint board, and revisit it when the design changes. That is a complete, living threat model, and it beats an impressive document nobody reads.

Common mistakes and best practices

The teams that build durable practice share a few habits, and avoid a few traps:

• Do scope sessions to features, use STRIDE as the default and reserve PASTA-grade analysis for the crown jewels, include engineers (not just security), and wire findings into the backlog and code review.
• Do not let the deliverable become the point (a long document is written once and outdated by the next sprint), let security run it alone (the builders should find the threats, the facilitator guides), skip backlog integration (findings in a wiki are findings scheduled for deletion), or force one framework onto every job.

Threat modeling vs penetration testing

Threat modeling and testing are complementary, not competing. Threat modeling finds design flaws (missing authorization boundaries, unsafe trust assumptions, unlogged critical actions) at a stage where no code exists to scan. A penetration test and automated scanners find implementation flaws in code that already exists, and cannot see a design-level gap that was never written down. The two feed each other: the model tells testers and scanners where to focus, and their findings reveal where the model was wrong. This is also why threat modeling complements, rather than replaces, manual penetration testing and your broader vulnerability management program.

Conclusion

Threat modeling is the highest-leverage security activity most teams still skip, because its payoff is invisible: the breach that never happened because a missing authorization check was caught on a whiteboard. Keep the four questions central, use STRIDE for routine changes and PASTA for the crown jewels, rank ruthlessly, turn every threat into a ticket or a named accepted risk, and wire the result into your tests. Do that per feature, as a thirty-minute habit rather than an annual ceremony, and you move security from something you bolt on after a pentest to something you design in from the start.

DeepStrike's penetration testing validates your threat model against a real adversary, confirming which design assumptions actually hold and turning your "what can go wrong" list into proven, prioritized findings. For US-based teams, see our US penetration testing services.

FAQ

What is threat modeling?

Threat modeling is a structured, repeatable process for analyzing a system from an attacker's perspective to identify and address security risks before they are exploited. It answers four questions: what are we building, what can go wrong, what will we do about it, and did it work. Done at design time, it catches flaws while they are cheap to fix rather than after a breach.

What are the four questions of threat modeling?

Formalized by the Threat Modeling Manifesto, they are: What are we working on? (map the system and trust boundaries), What can go wrong? (enumerate threats, often with STRIDE), What are we going to do about it? (choose a mitigation, or an explicit accepted risk, for each), and Did we do a good enough job? (validate that mitigations were built and tested). Every mainstream methodology is a variation on these.

What is the difference between STRIDE and PASTA?

STRIDE is a lightweight technical model that categorizes threats into six types (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) per component, and takes minutes to hours. PASTA is a seven-stage, risk-centric methodology that ties threats to business impact and simulated attacks, and takes days. Use STRIDE for per-feature reviews and PASTA for high-stakes systems; many teams combine them.

Which threat modeling methodology is best?

There is no single best methodology; the right one depends on who acts on the output. STRIDE suits engineers finding technical flaws during development, PASTA suits aligning risk with business leadership, DREAD ranks threats you already found, attack trees model a single high-value target, and LINDDUN handles privacy. Most mature programs default to STRIDE and add heavier methods only where the stakes justify them.

When should you do threat modeling?

At the design stage, before code is written, and again whenever a change materially alters the system, a new integration, data flow, endpoint, or trust boundary. Modeling early is far cheaper than retrofitting fixes, but a model that is never revisited goes stale, so treat it as a living artifact updated per feature rather than a one-time document.

What tools are used for threat modeling?

The most common are OWASP Threat Dragon (free, open source, model-as-code) and the Microsoft Threat Modeling Tool (free, with a built-in STRIDE threat library), plus commercial platforms like IriusRisk that automate threat generation from architecture. For threat-model-as-code in CI pipelines, teams use OWASP pytm (Python) and Threagile (YAML). A whiteboard and a threat table also work for a first session.