STRIDE

STRIDE is the design-time threat modeling framework developed at Microsoft in the late 1990s by Loren Kohnfelder and Praerit Garg. The framework provides a structured way to think about what could go wrong with a system during the architecture and design phase — before the system is built — by walking through each component, each data flow, and each trust boundary and asking which of six standard threat categories apply. The methodology is lightweight enough to fit into software development workflows, well-understood enough that engineers can learn it without specialized security background, and structurally simple enough that it has become the de facto threat modeling approach in the majority of software development organizations that do any threat modeling at all.

STRIDE is also one of the frameworks where the gap between formal adoption and operational practice is widest. Many organizations have STRIDE-shaped threat modeling documentation that satisfies an audit checkbox without producing meaningful security insight. The framework provides the structure; the analytical work it is meant to structure is the part that determines whether the output is valuable.

This page is the deep-dive companion to the Threat Modeling Frameworks umbrella. The scope here is what STRIDE actually is, how to apply it well, and how to avoid the failure modes that the framework’s apparent simplicity makes easy.

What STRIDE actually is

STRIDE is an acronym for the six threat categories the framework organizes:

• Spoofing — impersonating something or someone.
• Tampering — modifying data or code.
• Repudiation — denying having performed an action.
• Information Disclosure — exposing information to unauthorized parties.
• Denial of Service — making the system unavailable to legitimate users.
• Elevation of Privilege — gaining capabilities beyond authorization.

Each threat category corresponds to a violation of a specific security property:

Threat	Violates	Security Property
Spoofing	Authenticity	Identity is who they claim to be
Tampering	Integrity	Data and code are unchanged from authorized state
Repudiation	Non-repudiation	Actions can be attributed to actors
Information Disclosure	Confidentiality	Information reaches only authorized parties
Denial of Service	Availability	System remains accessible to legitimate users
Elevation of Privilege	Authorization	Capabilities match assigned authority

The mapping to the classic security properties (CIA — confidentiality, integrity, availability — plus authenticity, non-repudiation, and authorization) is part of why STRIDE has held up over thirty years. The six categories cover the standard taxonomy of what can go wrong from a security perspective, organized in a way that is comprehensive without being so granular that it becomes unwieldy.

STRIDE is applied at design time, walking through the planned architecture before implementation begins. The output is a list of design-level threats that the architecture must mitigate, typically captured in the design review documentation alongside the architectural decisions themselves. This is the operational distinction that separates STRIDE from frameworks like ATT&CK (which describe adversary behavior in operational contexts) or OCTAVE (which work from organizational risk assessment): STRIDE answers “what could go wrong with this design” before there is anything to attack.

The framework is lightweight by design. A team can learn STRIDE in an hour and apply it in a half-day workshop. The lightweight character is its primary virtue — STRIDE fits into development sprint cycles in a way that heavyweight methodologies like PASTA do not — and its primary risk — the apparent simplicity makes it easy to apply superficially.

The six categories in detail

Each category warrants more depth than the acronym alone provides. The examples in each section are illustrative rather than exhaustive.

Spoofing

Spoofing is the threat that someone or something pretends to be a different identity. The category covers:

• User identity spoofing — an adversary authenticates as a legitimate user, typically through credential theft, credential stuffing, session hijacking, or weak authentication that allows impersonation.
• Process identity spoofing — a malicious process presents as a legitimate one, through binary planting, DLL hijacking, or running with a deceptive name.
• Server identity spoofing — a system connects to an adversary-controlled server thinking it is the legitimate one, through DNS hijacking, certificate failures, or man-in-the-middle attacks.
• Service identity spoofing — a microservice impersonates another service, through compromise of service-to-service authentication.

Mitigations typically involve authentication mechanisms appropriate to the identity type: passwords-plus-MFA for user identities, code signing for process identities, TLS server authentication for server identities, mTLS or service mesh identity for service identities.

Tampering

Tampering is the threat that data or code is modified without authorization. The category covers:

• Data tampering in transit — modification of data while it crosses a network, addressed by integrity protection (HMACs, signatures, AEAD modes).
• Data tampering at rest — modification of stored data, addressed by integrity protection on storage (file integrity monitoring, signed configurations) and access controls.
• Code tampering — modification of executable code, addressed by code signing, secure boot, and runtime integrity verification.
• Configuration tampering — modification of system configurations, addressed by configuration management tooling, signed manifests, and audit logging.

The integrity primitives that address tampering are covered in detail in the Hash Functions and MACs page and the broader Cryptography section.

Repudiation

Repudiation is the threat that an actor denies having performed an action, with the system unable to provide convincing evidence to the contrary. The category covers:

• User action repudiation — a user claims they did not perform an action they actually did.
• Administrative action repudiation — an administrator denies a configuration change or access grant.
• Transaction repudiation — one party in a transaction denies the transaction occurred or denies its terms.

Mitigations typically involve audit logging (with tamper-resistant storage), digital signatures (which provide cryptographic non-repudiation), and structured authorization tracking. The relationship to compliance is direct: many regulatory frameworks require non-repudiation properties that translate directly into STRIDE-style threat analysis.

Information Disclosure

Information disclosure is the threat that information reaches parties who should not have access to it. The category covers:

• Direct information disclosure — data accessed by parties without authorization, through compromised credentials, access control failures, or storage misconfiguration.
• Side-channel information disclosure — data inferred from indirect signals (timing, error messages, log content, network traffic patterns).
• Inadvertent disclosure — data exposed through bugs, misconfigurations, or third-party integrations.
• Data aggregation disclosure — individually-anonymous data combined into identifying information.

Mitigations are typically encryption (covered in Symmetric Cryptography), access controls (RBAC, ABAC), data classification and handling policies, and careful design to prevent side-channel leakage. The privacy-specific aspects of information disclosure are handled in more depth by LINDDUN — the privacy-focused parallel framework.

Denial of Service

Denial of service is the threat that the system becomes unavailable to legitimate users. The category covers:

• Resource exhaustion — adversary consumes computing resources (CPU, memory, disk, network) until legitimate requests cannot be served.
• Algorithmic complexity attacks — adversary triggers expensive code paths that consume disproportionate resources per request.
• State exhaustion — adversary fills up state tables, connection pools, or queues that the system depends on.
• Logical denial of service — adversary causes the system to enter a state where it cannot serve legitimate users, without necessarily exhausting any specific resource.

Mitigations are typically rate limiting, capacity planning, redundancy, and architectural choices that bound resource consumption per request (request size limits, query complexity limits, etc.). Distributed denial of service attacks against external-facing systems require additional mitigations at the network edge.

Elevation of Privilege

Elevation of privilege is the threat that an actor gains capabilities beyond what their authorization permits. The category covers:

• Vertical privilege escalation — a low-privilege account gains administrative or root access.
• Horizontal privilege escalation — an account gains access to resources belonging to a different account at the same privilege level.
• Process privilege escalation — code running at a low privilege level executes operations that require higher privilege.
• Context privilege escalation — capabilities valid in one context (a user-mode process, an unprivileged container) leak into a context where they should not be available.

Mitigations are authorization controls, sandboxing, least-privilege design, and careful management of trust boundaries. Many privilege escalation vulnerabilities arise from the gap between formal authorization design and actual implementation; the threat model must track this gap explicitly.

The methodology

Applying STRIDE involves three distinct activities, each of which can be done well or poorly:

Decompose the system. Produce a model of the system’s components, data flows, and trust boundaries. The standard modeling artifact is a data flow diagram (DFD) showing how data moves through the system and where the trust boundaries lie. The DFD identifies the entities (external actors), processes (system components that transform data), data stores (where data is persisted), and data flows (the connections between everything else). Trust boundaries — the points where the trust level changes — are explicitly marked.

Identify threats. Walk through the model and apply STRIDE to each element, asking which of the six threat categories apply. The walkthrough can be done at different granularities (covered below). The output is a list of design-level threats with descriptions of the specific concern in the context of the specific system.

Determine mitigations and validate. For each identified threat, determine the planned mitigation (whether by control, design choice, or accepted risk). Validate that the mitigations actually address the threats — this is the step that prevents the threat modeling output from being purely theoretical.

The methodology is at heart structured creativity. The structure (the six categories, the data flow diagram, the walkthrough) provides discipline; the analytical work of asking “what could go wrong here in this specific context” is the creative part that the structure organizes but does not replace.

Data flow diagrams as the modeling artifact

Data flow diagrams are older than STRIDE — DFDs were a standard software engineering artifact in the 1970s and 1980s before being adopted as the threat modeling diagram of choice. The standard DFD notation:

• External entities are drawn as rectangles or labeled boxes. They represent actors outside the system being modeled — users, third-party services, the broader internet.
• Processes are drawn as circles or rounded rectangles. They represent components within the system that transform or operate on data — application services, microservices, functions.
• Data stores are drawn as parallel lines (or open rectangles in some notations). They represent persisted data — databases, file storage, caches, message queues.
• Data flows are drawn as arrows connecting the above. They represent data movement — HTTP requests, database queries, message bus traffic.
• Trust boundaries are drawn as dashed lines crossing the diagram, separating regions of different trust level.

The trust boundary is the most important element of a STRIDE DFD. Every data flow that crosses a trust boundary is a candidate for all six STRIDE threats; data flows entirely within a trust boundary are typically less rich threat sources. The trust boundary is where the security review concentrates its attention.

DFDs are typically maintained at two or three levels of decomposition. A Level 0 DFD shows the system as a single process with its external interactions. A Level 1 DFD decomposes that process into its major components. Further decomposition into Level 2 or Level 3 DFDs may be appropriate for complex systems. The right level for threat modeling is the level where the trust boundaries become visible — typically Level 1 or Level 2 for most systems.

The DFD discipline is the part of STRIDE methodology that tends to suffer in practice. A team that produces an incomplete or inaccurate DFD will identify threats against the wrong system. The DFD work is the foundation; spending time getting it right pays back through the rest of the threat modeling exercise.

STRIDE per element vs STRIDE per interaction

Two variants of the STRIDE walkthrough exist, each with operational tradeoffs:

STRIDE per element walks through each element of the DFD and asks which STRIDE threats apply to it. Each element has standard threat categories that typically apply (external entities can be spoofed and can repudiate; processes can experience all six threats; data stores experience tampering, information disclosure, and DoS; data flows experience tampering, information disclosure, and DoS). The walkthrough produces a per-element threat list that the team works through systematically.

The advantage of per-element STRIDE is comprehensive coverage. Every element gets examined for every applicable threat type. The disadvantage is that the resulting threat list can be large and contains threats that don’t actually apply in the specific context.

STRIDE per interaction walks through each data flow (or each component interaction) and asks which STRIDE threats apply at that interaction. The walkthrough focuses on the trust boundary crossings and the data movement that traverses them, producing a smaller and more contextual threat list.

The advantage of per-interaction STRIDE is focused analysis. The threats identified are tied to specific interactions, which makes mitigation more concrete. The disadvantage is that threats inherent to specific elements (like data store tampering when the store sits within a single trust boundary) can be missed.

Most mature STRIDE programs use per-interaction analysis with element-level fallback: focus on the trust boundary crossings, but check element-level threats for any element that has substantial intrinsic value or sensitivity. The right choice depends on the system being analyzed and the team’s experience.

Where STRIDE excels

The framework earns its operational value in several specific contexts:

Software design review during development. STRIDE fits naturally into design review processes. The team architecting a new service or feature walks through the design with security in mind, identifies threats, and documents mitigations. The output becomes part of the design documentation alongside the architectural decisions themselves. This is the workflow STRIDE was designed for and where it produces the most value.

Training engineers in security thinking. Engineers learning to think about security benefit from the structured prompts STRIDE provides. The six categories give specific things to ask about during design, which is more productive than “think about security” as a general directive. Teams adopting STRIDE often find that the framework’s primary value is the security-thinking discipline it instills, beyond the specific threat lists it produces.

Cross-functional design conversations. STRIDE provides a common vocabulary that lets security engineers, software engineers, and architects discuss threats without translation overhead. A statement like “this interaction has spoofing and tampering risk” is precise enough to drive specific design decisions and accessible enough that non-security engineers can engage with it.

Lightweight integration into agile workflows. STRIDE applied per-sprint or per-feature fits into agile development timelines in a way heavyweight methodologies do not. A 90-minute threat modeling session per significant feature is achievable; a multi-week PASTA analysis is not.

Documentation that survives. STRIDE outputs — the DFD, the threat list, the mitigation plans — produce design documentation that remains useful over the system’s lifetime. The DFD shows trust boundaries that future engineers need to know about; the threat list documents security decisions; the mitigation plans capture the reasoning behind specific controls.

Where STRIDE has limits

The honest treatment of the framework requires several acknowledged limits:

STRIDE does not handle adversary motivation. The framework is agnostic to who the adversary is and why they would attack. A threat is a threat whether the attacker is a nation-state, a financially-motivated criminal, an insider, or a curious researcher. For some kinds of analysis (specifically, threat modeling that needs to prioritize based on adversary capability and intent), STRIDE is too generic. Combining STRIDE with threat intelligence specific to the organization’s adversaries fills this gap; STRIDE alone does not.

STRIDE is design-oriented, not operational. The framework excels at “what could go wrong with this design” but does not handle “what is going wrong with this system right now.” Operational threat analysis — incident response, ongoing detection coverage, threat hunting — uses frameworks like ATT&CK and the Diamond Model, not STRIDE.

STRIDE does not scale to enterprise architecture. Threat modeling individual services with STRIDE is straightforward. Threat modeling an enterprise architecture with hundreds of services and thousands of trust boundary crossings is not. The methodology does not provide the structure for aggregating threats across many systems or for prioritizing across an enterprise-wide threat surface. Other frameworks (OCTAVE, PASTA) handle enterprise-scale threat analysis better.

STRIDE produces categories, not specific threats. A “spoofing threat” on a data flow is a category, not a specific attack. Translating from category to actual attack — knowing what spoofing attacks are realistically possible against the specific implementation — requires security expertise that STRIDE does not provide. Teams without that expertise can produce STRIDE outputs that look complete but don’t capture the actual attack surface.

STRIDE does not handle modern microservice complexity well. The framework was designed for systems with relatively few components and well-defined boundaries. Modern microservice architectures have hundreds of services, dynamic deployment patterns, and trust boundaries that change with each deployment. STRIDE applied to such architectures often produces threat lists that are either too generic (covering categories without specific context) or too specific (covering only the most-recently-analyzed service while leaving the rest untouched).

The framework is not threat intelligence. STRIDE identifies categories of things that could go wrong; it does not tell the team which of those things are actually likely. Prioritization requires threat intelligence that STRIDE does not provide. Teams that treat STRIDE outputs as complete threat models without prioritization typically over-invest in mitigating low-probability threats and under-invest in high-probability ones.

Operational use

A few places STRIDE shows up in practical work:

During architecture review for new services. STRIDE is applied as part of the design review process. The architect produces a DFD; the team walks through the threats; mitigations are added to the design before implementation begins. This is the canonical workflow and the one where STRIDE produces the most value.

During feature design within existing services. For significant features that change trust boundaries or data flows, STRIDE-lite analyses (focused on the changes rather than the entire system) keep threat modeling current with system evolution. The lightweight character of STRIDE makes this kind of incremental analysis tractable.

During security training for development teams. STRIDE is the standard framework taught when development teams are being introduced to threat modeling. The accessibility and structure make it appropriate for engineers who are learning security thinking for the first time.

During third-party assessment of designs. External security reviewers often use STRIDE as their walkthrough framework, particularly for systems where the assessment has design-time scope rather than penetration testing scope.

During design documentation. Mature STRIDE programs treat the threat model documentation as a first-class artifact that stays current with the system. The documentation includes the DFD, the threat list, the mitigation decisions, and the residual risk acceptances. Future engineers, auditors, and security reviewers all benefit from this documentation.

Tooling

The STRIDE tooling ecosystem has several mature options:

Microsoft Threat Modeling Tool is the original tool, developed by Microsoft and freely available. It provides a structured DFD editor with built-in STRIDE prompts, threat templates, and reporting. The tool is Windows-only and is best suited for individual analysts; collaborative use is harder. Microsoft has continued maintaining the tool, with updates through 2024.

OWASP Threat Dragon is the leading open-source alternative, available as both a desktop application and a web-based tool. Threat Dragon supports STRIDE plus other threat frameworks and is more accessible for collaborative use than Microsoft’s tool. The OWASP project is actively maintained and is the standard recommendation for teams that need open-source threat modeling tooling.

IriusRisk is the leading commercial threat modeling platform with substantial enterprise adoption. The platform supports STRIDE plus other frameworks, integrates with development pipelines, and provides threat-pattern libraries that automate parts of the threat identification process. The commercial tool tier is appropriate for organizations running threat modeling at enterprise scale.

ThreatModeler is another commercial platform with similar positioning to IriusRisk. The two are the dominant commercial options in the space.

Spreadsheet-based threat modeling remains common in practice, particularly for individual services and teams without dedicated tooling investment. A spreadsheet with element/interaction in rows and STRIDE categories in columns is functionally sufficient for many threat modeling exercises, and the lower setup cost makes it appropriate for organizations starting their threat modeling practice.

Diagrams.net (formerly draw.io) and similar generic diagramming tools are used for DFD production when threat modeling tooling is not in place. The output is not as structured as dedicated tools provide, but the diagrams themselves are functional.

The relationship to other frameworks

STRIDE coexists with several other threat modeling frameworks:

LINDDUN is the privacy-focused parallel framework. Where STRIDE has six security threat categories, LINDDUN has seven privacy threat categories. The methodologies are otherwise similar — same DFD-based modeling approach, same walkthrough structure. Teams that need both security and privacy threat modeling typically use STRIDE and LINDDUN in parallel.

PASTA is the heavier methodology that explicitly includes business risk analysis. PASTA’s seven stages cover business objective definition, technical scope definition, application decomposition, threat analysis, vulnerability analysis, attack modeling, and risk impact analysis. STRIDE is the threat identification step within stage 4 of PASTA — PASTA can be understood as STRIDE with substantial additional structure for business alignment.

OCTAVE operates at the enterprise asset level rather than the system design level. STRIDE and OCTAVE are not direct competitors; they address different abstractions. An organization typically uses both, with OCTAVE driving enterprise risk priorities and STRIDE handling system-level technical threats.

Attack trees can be combined with STRIDE for deeper analysis of specific high-priority threats. The STRIDE walkthrough identifies threats at the design level; attack trees can be developed for the threats that warrant deeper analysis. The combination is more analytical than either framework alone.

ATT&CK operates at a different abstraction level (operational adversary behavior rather than design-time threat categories). STRIDE-identified threats can be mapped to ATT&CK techniques to connect design-time analysis to operational threat understanding, but the frameworks are not interchangeable.

Persistent pitfalls

Several recurring failure patterns in STRIDE adoption:

Filling in the matrix without analysis. The framework’s structure makes it easy to produce STRIDE-shaped documentation by marking each cell with generic statements (“spoofing risk mitigated by authentication”) without genuinely analyzing what could go wrong in the specific context. The output looks complete; the analysis is shallow.

Incomplete or wrong DFDs. A DFD that misses components, data flows, or trust boundaries produces threat modeling against a partial picture of the system. Threats against the missed parts are absent from the model. DFD accuracy is foundational and tends to suffer when threat modeling is rushed.

Treating STRIDE as the complete threat model. STRIDE identifies categories of design-level threats. A complete threat model also needs operational threat intelligence, prioritization based on adversary capability, and validation against real-world attack patterns. STRIDE-only threat modeling produces a partial picture.

One-time threat modeling at initial design. Systems change. A threat model produced at initial design and never updated becomes outdated as the system evolves. Mature programs treat threat modeling as ongoing, with updates triggered by significant architecture changes.

Threat modeling without follow-through. Identifying a threat and noting “mitigated by [planned control]” is not threat modeling — it’s planning to threat-model. Without verification that the planned controls actually got implemented and actually address the identified threats, the threat model is aspirational documentation.

Skipping the “are we done?” question. Mature STRIDE practice includes explicit validation that the threat model captures the threats that matter. This is the hardest part to do well — knowing whether you’ve identified the important threats requires security expertise that the framework structure does not provide. Teams that skip this validation produce threat models that satisfy the methodology but may miss the threats that actually matter.

Threat modeling without engineering buy-in. STRIDE outputs are valuable only if engineers actually implement the identified mitigations. Threat modeling sessions where security engineers identify threats that development engineers then ignore produce documentation rather than security improvements. Cross-functional engagement is critical.

Standards and references

• Threat Modeling: Designing for Security by Adam Shostack (2014) — the canonical reference on threat modeling methodology, with extensive coverage of STRIDE and DFD-based modeling.
• Microsoft Threat Modeling Tool — aka.ms/tmt, the original tool with built-in STRIDE templates.
• OWASP Threat Dragon — owasp.org/www-project-threat-dragon/, the open-source alternative.
• The Microsoft Security Development Lifecycle (SDL) — the broader process within which STRIDE was originally developed.
• NIST SP 800-154 (draft) — Guide to Data-Centric System Threat Modeling, which references STRIDE alongside other approaches.

How to actually use STRIDE in 2026

For organizations adopting STRIDE, a practical sequence:

1. Train the development team on the framework. A 2-hour introduction covering the six categories, the DFD methodology, and the walkthrough process is sufficient to start. Engineers do not need to become security specialists; they need enough understanding to participate productively in threat modeling sessions.

2. Pick a tool appropriate to the scale. Spreadsheets work for individual teams. OWASP Threat Dragon works for organizations with multiple teams and moderate scale. IriusRisk or ThreatModeler are appropriate for enterprise-scale programs. Don’t over-invest in tooling before the practice is established.

3. Integrate threat modeling into the design review process. New services and significant features get threat modeling as part of design review. The timing matters — threat modeling after implementation is far less valuable than threat modeling during design.

4. Use per-interaction analysis with element-level fallback. Focus on trust boundary crossings; check element-level threats for high-value elements. The combination produces focused output without missing intrinsic-to-element threats.

5. Document the threat model as a living artifact. The DFD, the threat list, the mitigations, and the residual risk acceptances all belong in the system’s design documentation. Updates to the system trigger updates to the threat model.

6. Validate that mitigations actually exist. Threat modeling is aspirational without verification. Pair the threat modeling exercise with subsequent verification that the planned mitigations got implemented and that they address the identified threats.

7. Bring in security expertise for high-value systems. Development teams can apply STRIDE productively to most systems; high-value systems benefit from security specialist involvement in the threat modeling sessions. The right balance is “developers lead with security support” rather than “security imposes threat modeling on developers.”

8. Combine with threat intelligence for prioritization. STRIDE identifies threats; threat intelligence informs which ones to prioritize. Without prioritization, STRIDE outputs treat all threats as equally important, which they are not.

STRIDE is the most-adopted threat modeling framework in software development for good reasons — it is lightweight, accessible, and produces real value when applied with discipline. The failure modes the framework’s adoption has produced are not arguments against the framework; they are arguments for taking the analytical work seriously rather than treating the framework structure as a substitute for it.

Where to go next on this site

Adjacent material on this site:

• Threat Modeling Frameworks — the umbrella overview.
• MITRE ATT&CK — the operational adversary behavior framework that complements STRIDE’s design-time focus.
• MITRE D3FEND — the defensive countermeasure catalog.
• LINDDUN — the privacy-focused parallel framework.
• PASTA — the heavyweight methodology that extends STRIDE with business risk analysis.
• The Cyber Kill Chain — the attack lifecycle model.
• The Diamond Model — the CTI analytical framework.

STRIDE is the threat modeling framework that has held up best across decades of changing technology and threat landscapes. The mathematics has held up; the failures have all been about how teams apply it rather than about the framework itself. Used as the structure for genuine analytical work, it produces design documentation that improves security outcomes meaningfully. Used as a documentation template, it produces paper that satisfies auditors without changing security posture. The difference is operational discipline, not the framework.