The STRIDE threat model is a threat modeling framework that sorts security threats into six categories: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Security teams apply it to a STRIDE data flow diagram during design reviews, so a flaw gets caught on a whiteboard instead of in a breach report.
Its purpose is simple: catch security flaws while a system is still a diagram, when a fix is a design change instead of an emergency patch. That checklist approach is a large part of why STRIDE remains one of the most widely taught threat modeling methodologies in application security. This guide covers each category, the session process, worked examples, a free template, and how STRIDE compares to DREAD and PASTA.
What Is the STRIDE Threat Model?
The STRIDE threat model is a threat modeling methodology that Microsoft engineers Loren Kohnfelder and Praerit Garg built in 1999. Instead of an open-ended brainstorm about what might go wrong, it hands a team six specific categories to check against a system design.
Each category ties back to one security property, which is the whole reason the model has aged so well:
| STRIDE Letter | Category | Security Property It Breaks |
|---|---|---|
| S | Spoofing | Authentication |
| T | Tampering | Integrity |
| R | Repudiation | Accountability |
| I | Information Disclosure | Confidentiality |
| D | Denial of Service | Availability |
| E | Elevation of Privilege | Authorization |
That is the STRIDE threat model full form, and the reason it still holds up: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege are not six vague worries. Each one gives a finding a specific, defensible label instead of a shrug and a “this feels risky.”
It is also worth knowing that this is not a dusty framework nobody checks anymore. The FDA’s February 2026 final premarket cybersecurity guidance for medical devices names STRIDE directly as a recommended approach for manufacturers submitting cybersecurity documentation, right alongside attack trees. A 27-year-old security framework getting cited in the fresh 2026 federal guidance is a pretty good sign it is not going anywhere.
What Are the Six STRIDE Threat Categories?
Here is what each one actually means, with a real example and the standard fix.
| Category | What It Means | Real Example | Common Fix |
|---|---|---|---|
| Spoofing | Pretending to be a user, device, or system you are not | Logging in with stolen credentials and passing as a real employee | Multi-factor authentication, strong identity checks |
| Tampering | Changing data or code without permission | Editing a hidden price field before checkout | Digital signatures, checksums, strict write controls |
| Repudiation | Denying an action with nothing to prove otherwise | An employee deletes records and claims they never touched the system | Tamper-resistant, timestamped audit logs |
| Information Disclosure | Exposing data to someone who should not see it | An unencrypted backup left in a public storage bucket | Encryption at rest and in transit, least privilege access |
| Denial of Service | Disrupting access for legitimate users | A flood of requests knocks a login page offline | Rate limiting, traffic filtering, and redundant infrastructure |
| Elevation of Privilege | Gaining access beyond what was granted | A standard account reaches an admin page through a broken permission check | Server-side authorization checks, role-based access control |
Two of these are worth slowing down on, because they are the ones people underrate.
Repudiation rarely gets the attention it deserves because it does not feel like an “attack” in the traditional sense. It is really a question about proof. If a transaction gets disputed six months from now, can you actually show what happened, or are you taking someone’s word for it? Without a real audit trail, you cannot tell the difference between a mistake and fraud.
Elevation of privilege is usually the last domino, not the first. An attacker rarely walks in with admin access. They spoof a login or tamper with a request, and elevation of privilege is the step that turns a small foothold into real damage. It is often the difference between an incident that gets a Slack message and one that gets a press release.
Who Created the STRIDE Threat Model?
Loren Kohnfelder and Praerit Garg, both engineers at Microsoft, created STRIDE in 1999. The goal was less about academic rigor and more about giving a developer and a security engineer a shared, non-technical vocabulary. Two people could look at the same diagram, run through the same six letters, and actually agree on what counted as a real threat, instead of one side calling something paranoid and the other side calling it obvious.
That practical, checklist-first origin is why the Microsoft STRIDE model still favors clarity over complexity, even 25-plus years later.
Microsoft’s Role in STRIDE Today
STRIDE never became a side project that Microsoft walked away from. It is still baked into how the company documents and teaches security design.
- Folded into the Microsoft Security Development Lifecycle (SDL) as a required step since 2002
- Microsoft Learn’s own Azure documentation uses STRIDE as the default framework for threat modeling cloud architectures
- The free Microsoft Threat Modeling Tool (covered in the tools section below) builds STRIDE suggestions directly into the diagramming process, so teams do not have to apply the six categories entirely by hand
That level of ongoing, official support is part of why STRIDE remains the default starting point for teams new to threat modeling, rather than something that peaked in the early 2000s and got left behind.
How to Use the STRIDE Threat Model: The 5 Steps
Running a STRIDE session follows the same STRIDE threat modeling steps every time.
Step 1: Define the scope.
Pick one system, feature, or component, not your entire platform. A single login flow or one microservice is a better unit of work than “the whole app.”
Step 2: Build the data flow diagram.
Map four elements: external entities (users, outside systems), processes (the parts that do something with data), data stores (databases, caches), and data flows (the arrows connecting them). Most usable diagrams stay under 30 elements. If yours is bigger than that, you have probably scoped too wide.
Step 3: Mark the trust boundaries.
Find every point where data crosses from one privilege level to another, like the line between the open internet and your internal network. This is not a formality. Threats cluster at trust boundaries because that is exactly where assumptions about “who can be trusted” get tested.
Step 4: Apply STRIDE to each element.
Check the relevant categories against each process, store, and flow. Some teams call this STRIDE per element: checking each component on its own. Others run STRIDE per interaction, focused on the connections between components instead. Running both catches more than either alone, though, per element is the faster starting point if you are new to this.
Step 5: Document, score, and assign an owner.
Every threat gets a plain description, a rough severity, and a name attached to the fix. Skip the “owner” step, and you will find, months later, that half the list never actually got addressed. Nobody decided not to fix it. It just never had anyone’s name on it.
STRIDE Threat Model Tutorial
The five steps above are the overview. Here is the same process as a hands-on STRIDE threat model tutorial, the kind you can actually follow along with on your first session.
Step 1: Learn the symbols before you draw anything.
A data flow diagram only uses five marks. Get comfortable spotting them and the rest of the tutorial will make a lot more sense.
Step 2: Sketch your system using only those five marks.
Do not worry about making it pretty. A whiteboard photo works fine. Start from the outside in: who or what talks to your system first, then what that request touches next, and so on until you reach a data store.
Step 3: Draw the trust boundary lines.
Look at your sketch and mark every place where data crosses from one trust level to another. Public internet to your API is one. Your API to an internal admin service is often another. If you cannot find at least one trust boundary, you have probably drawn the diagram too small.
Step 4: Apply STRIDE, but only where it counts.
This is the step people overthink. You do not need to check all six categories against every single element. Use the matrix below as a shortcut: a process is worth checking against all six, but an external entity is really only worth checking for spoofing and repudiation.
Step 5: Write each threat down as a single sentence, plus a fix.
Keep it plain: what could happen, and what stops it. Resist the urge to write a paragraph. If a threat needs a paragraph to explain, it usually means the scope from Step 1 was too broad.
Step 6: Assign an owner and move on.
A threat with no name attached to it rarely gets fixed. Close the session once every threat has a person’s name next to it, even if the fix itself is scheduled for later.
Run through those six steps once, on one real feature, and the process stops feeling like a framework and starts feeling like a habit.
STRIDE Threat Model Example
Theory is fine, but a STRIDE threat modeling example makes it click. Take a basic login system: a user, a login service, and a user database.
Running STRIDE per element against the login service surfaces threats like these:
- Spoofing: an attacker logs in with a leaked password and passes as someone else. Fix: multi-factor authentication.
- Tampering: an attacker intercepts and edits a session cookie to stretch their access. Fix: signed, encrypted session tokens.
- Repudiation: a user resets their password and later denies doing it. Fix: logged, timestamped reset events.
- Information Disclosure: A login error message quietly confirms whether a given username exists. Fix: generic error messages on failed logins.
- Denial of Service: An attacker floods the login endpoint with junk requests. Fix: rate limiting and progressive lockouts.
- Elevation of Privilege: A broken role check lets a normal account reach an admin page. Fix: server-side authorization checks on every single request, not just the ones you remember to protect.
A full pass on a real application, including its database and any third-party services, usually turns up somewhere between 20 and 60 individual threats, depending on how big the system is. One login flow alone can trip all six categories. Most production systems have dozens of components exactly like it.
A login flow is a good starting point, but STRIDE looks a little different depending on what you are protecting. Here is the same six questions asked of two more systems, side by side:
| STRIDE Category | E-commerce Checkout | Cloud File Storage |
|---|---|---|
| Spoofing | A fake payment webhook claims a purchase succeeded | A stolen access key impersonates a trusted internal service |
| Tampering | A shopper edits the price in a hidden field before submitting | A file gets swapped for a malicious version during upload |
| Repudiation | A customer disputes a charge with no proof either way | A shared service account deletes a file, and nobody can say who did it |
| Information Disclosure | One shopper views another’s order by guessing an order ID | A storage bucket is misconfigured and left publicly readable |
| Denial of Service | Bots flood checkout with fake orders, locking up real inventory | Repeated file conversions get triggered to exhaust compute |
| Elevation of Privilege | A support tool lets an agent quietly grant themselves admin rights | An over-permissioned IAM role lets one compromised service reach every other bucket |
The fixes follow a pattern too: verify anything that claims to be a trusted source (signed webhooks, signed tokens), never trust a number the client sends you, check ownership on every lookup, rate limit anything an attacker could flood, and keep permissions as narrow as the job actually requires.
Same six questions, three different systems. That repeatability is the entire point of STRIDE: you are not reinventing the checklist every time, just pointing it somewhere new.
STRIDE vs DREAD vs PASTA: Which One Do You Actually Need?
STRIDE almost never works alone in a mature security program, which is why STRIDE vs DREAD and STRIDE vs PASTA come up constantly.
| Framework | Built By | What It Actually Does | Best For |
|---|---|---|---|
| STRIDE | Kohnfelder and Garg, Microsoft, 1999 | Finds and categorizes threats | Design reviews, feature-level analysis |
| DREAD | Microsoft | Scores threat severity across five factors | Deciding which STRIDE findings to fix first |
| PASTA | Tony UcedaVelez and Marco Morana | Simulates attacker behavior and ties threats to business impact | Enterprise risk work aimed at non-technical stakeholders |
STRIDE finds the threats. DREAD ranks them.
PASTA is heavier: a seven-stage process built around thinking like an actual attacker and translating every threat into business terms that leadership can act on. Fast-moving engineering teams usually get the most value from STRIDE on its own, or STRIDE paired with DREAD. Organizations that need to justify a security budget to a board get more out of layering PASTA on top.
Two more frameworks worth knowing, even if you reach for them less often: LINDDUN does for privacy what STRIDE does for security, worth adding if you handle regulated personal data. Attack trees are the right tool once you already know your scariest threat and want to map every path an attacker could take to get there.
STRIDE vs OWASP: What’s the Actual Difference?
These are not competing frameworks, and mixing them up is an easy mistake. STRIDE is a threat modeling process, applied before code exists, to ask what could go wrong at the design stage. The OWASP Top 10 is a list of the vulnerability categories that show up most often in applications that have already been built, useful during code review and testing.
They fit together neatly in practice. A STRIDE session might flag an elevation of privilege risk in your design. Later, during implementation, the OWASP list gives you the specific, well-documented failure pattern (broken access control) to actually check your code against. Use both. They are not asking the same question.
Free STRIDE Threat Model Template
You do not need to download anything for a free Stride threat model. Just copy the table below into a spreadsheet and start logging.
| Component | Category | Threat | Severity | Fix | Owner | Status |
|---|---|---|---|---|---|---|
| Login API | Spoofing | Credential stuffing, no MFA | High | Add MFA and lockouts | Backend | Open |
| Session Store | Tampering | Session token is editable in transit | Medium | Sign tokens, enforce HTTPS | Platform | Open |
| Password Reset | Repudiation | No record of who triggered a reset | Medium | Timestamped audit log | Backend | Open |
| User Database | Information Disclosure | Backup stored unencrypted | High | Enforce encryption at rest | Infra | Open |
| Login Endpoint | Denial of Service | No rate limit on failed attempts | High | Add rate limiting, CAPTCHA | Backend | Open |
| Admin Panel | Elevation of Privilege | Missing role check on one route | Critical | Add server-side auth check | Backend | Open |
The only habit that actually matters here is keeping the last two columns honest. A threat log without an owner and a real status is just a diagram with extra steps.
If you would rather have something generate this automatically, a few free STRIDE threat modeling tools do the diagramming and threat suggestion for you:
- Microsoft Threat Modeling Tool: draws the diagram, and auto-suggests threats per element. It also exports a STRIDE threat model PDF report, which is handy for audit evidence.
- OWASP Threat Dragon: is open source and does roughly the same job in a browser or desktop app.
- Threagile: takes a different route: you describe your system in YAML, and it generates the threat model, which fits naturally into a CI pipeline if you want this to run automatically whenever the architecture changes.
Common Mistakes to Avoid
- Skipping the diagram entirely. Trying to run STRIDE from memory misses exactly the threats that cluster at trust boundaries.
- Scoping too wide. One session against your whole platform produces a shallow list nobody trusts. Smaller scope, sharper results.
- Treating it as a one-time exercise. A threat model built once and never revisited is stale within a few months. Systems change, and the model needs to keep up.
- Forcing every threat into exactly one box. A stolen session token can be a spoofing, information disclosure, and elevation of privilege problem all at once. Log it under everything that applies.
- No owner, no status. Said above, worth saying twice. This is the single most common reason a threat model turns into a document nobody looks at again.
STRIDE for AI Agents: What’s New in 2026
Traditional STRIDE was designed for deterministic software systems and remains effective for analyzing infrastructure, APIs, permissions, and data flows. However, emerging AI systems introduce additional risks such as prompt injection, model manipulation, and unsafe tool execution. These risks are increasingly addressed through complementary frameworks such as OWASP LLM Top 10 and MITRE ATLAS rather than replacing the original STRIDE methodology. Here is what researchers have built to cover the gap, without throwing STRIDE out.
ASTRIDE: The Seventh Category
A December 2025 paper (Manikandan et al.) adds a new category on top of the original six: A, for AI Agent Specific Attacks. Think of it as STRIDE’s more paranoid younger sibling.
- Covers threats classic STRIDE was never built to see: prompt injection, context poisoning, unsafe tool use
- The platform itself is AI-powered, using vision language models to read architecture diagrams and draft the threat report automatically
- Best fit if you are building agentic systems from scratch and want a purpose-built seventh box to check.
ISADM: STRIDE plus real attacker data
A December 2025 paper from Khondokar Fida Hasan and colleagues stacks STRIDE together with MITRE’s ATT&CK and D3FEND frameworks, rather than adding a new category.
- STRIDE tells you which assets are at risk
- ATT&CK adds real-world data on which techniques attackers are actually using right now
- D3FEND supplies the specific technical defenses for those exact techniques
- Best fit for high-stakes industries like fintech, where “probably fine” is not a good enough answer
strideSEA: STRIDE across the whole lifecycle
STRIDE usually gets used once at the design stage, then quietly retired. A March 2025 paper from Alvi Jawad and colleagues keeps it running instead.
- Connects threat modeling, attack scenario mapping, risk analysis, and countermeasure selection under one shared vocabulary
- Nothing gets lost in translation between the design review and the final code review
- Best fit for teams tired of switching tools and terminology halfway through a project
| Framework | Adds | Best For |
|---|---|---|
| ASTRIDE | A new “AI Agent” category | Agentic systems built from scratch |
| ISADM | Real attacker technique data | Regulated, high-stakes industries |
| strideSEA | Lifecycle-wide consistency | Teams are juggling too many tools already |
None of this replaces the original six categories. Building a traditional application: plain STRIDE still does the job it has done since 1999. Building something with autonomous agents or tool calling: these extensions cover the parts STRIDE alone was never designed to catch.
Why STRIDE Matters for Security Certifications
STRIDE is foundational material for CISSP, Security+, and CEH, not optional background reading.
- Exam questions typically describe an attack scenario and ask which STRIDE category it falls under
- You may also be asked to explain STRIDE vs DREAD vs PASTA in one clean sentence
- The common trap: memorizing six letters without knowing why each one exists
Knowing which security property a category protects is usually the exact thing a scenario question is testing.
The Bottom Line
STRIDE earns its spot on CISSP and Security+ exam objectives, and in real 2026 security programs, for the same reason it existed in 1999: six categories, each tied to a specific security property, checked against a diagram, are simple enough to run in one meeting and thorough enough to actually catch design flaws. Take the template above, run it against the next feature you build that touches authentication, payments, or permissions, and expect to walk away with somewhere between 10 and 20 real threats on your first pass.
Frequently Asked Questions (FAQs)
What is the STRIDE threat model?
It is a threat modeling framework that sorts security threats into six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Teams apply it to a data flow diagram during design reviews to catch security gaps before code ships.
What are the six components of the STRIDE threat model?
Spoofing (authentication), Tampering (integrity), Repudiation (accountability), Information Disclosure (confidentiality), Denial of Service (availability), and Elevation of Privilege (authorization). Each one maps to a specific security property that an attacker could break.
What is the STRIDE threat model full form?
Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. It was designed as an acronym on purpose, so each letter would map directly to one threat category.
Who created the STRIDE threat model?
Loren Kohnfelder and Praerit Garg, both Microsoft engineers, created it in 1999 to give internal teams a shared, non-technical way to run security design reviews.
What is the difference between STRIDE and DREAD?
STRIDE finds and categorizes threats. DREAD scores how severe each one is, across Damage, Reproducibility, Exploitability, Affected Users, and Discoverability. Most teams run STRIDE first, then DREAD to decide what to fix first.
What is the difference between STRIDE and PASTA?
STRIDE is fast and works per component, good for individual feature reviews. PASTA is a seven-stage process that simulates real attacker behavior and ties findings to business impact, better suited to enterprise-wide risk work.
What is the difference between STRIDE and OWASP?
STRIDE is a design-time process for figuring out what could go wrong before code exists. The OWASP Top 10 is a ranked list of vulnerabilities that actually show up in built applications, used during testing. They complement each other rather than compete.
How do you use the STRIDE threat model?
Build a data flow diagram, mark the trust boundaries, then check the relevant STRIDE categories against every process, store, and flow. Document what you find with a severity, a fix, and an owner, then revisit the model whenever the architecture changes in a meaningful way.
Is there a free STRIDE threat model template?
Yes. A shared spreadsheet with columns for the threat, its severity, the fix, the owner, and its status covers what matters (see the template above). If you would rather it be generated for you, the Microsoft Threat Modeling Tool and OWASP Threat Dragon both export one automatically.
Does STRIDE still work for AI agents?
Partially. It still holds up for an AI system’s infrastructure, its APIs, storage, and network exposure. The reasoning and memory layers need an additional framework on top, like ASTRIDE, ISADM, or strideSEA, since classic STRIDE was never built to model non-deterministic behavior.
