Category: Threat Modeling

STRIDE

Also known as: STRIDE, STRIDE model, STRIDE threat model

Simply put

STRIDE is a framework used to identify and categorize security threats during the design of software systems. It organizes threats into six categories to help development and security teams think systematically about what could go wrong. The goal is to surface potential vulnerabilities early, before code is written or deployed.

Formal definition

STRIDE is a threat modeling taxonomy that classifies adversarial threats across six categories: Spoofing (impersonating another identity), Tampering (unauthorized modification of data or code), Repudiation (denying actions without the ability to prove otherwise), Information Disclosure (unauthorized exposure of data), Denial of Service (degrading or eliminating availability), and Elevation of Privilege (gaining capabilities beyond those authorized). Typically applied during architectural design reviews, STRIDE analysis is conducted at the code and design level and does not require a running system, meaning it can surface structural and logical threat categories but cannot detect runtime-specific behaviors, configuration-dependent vulnerabilities, or environment-level weaknesses without additional context or complementary methods.

Why it matters

Identifying security threats after a system is built is significantly more costly and disruptive than identifying them during design. STRIDE provides a structured vocabulary for surfacing threat categories early in the software development lifecycle, when architectural decisions can still be changed without large remediation effort. By giving teams a consistent set of threat categories to reason against, STRIDE reduces the likelihood that entire classes of threats are overlooked simply because no one thought to ask about them.

The six categories in STRIDE cover a broad range of adversarial concerns that affect most software systems, from identity impersonation and unauthorized data modification to availability attacks and privilege escalation. This breadth means that even teams without deep security specialization can use the framework as a checklist to prompt discussion and surface gaps in their designs. It is particularly valuable during architectural design reviews, where the goal is to evaluate structural and logical properties of a system rather than its runtime behavior.

STRIDE does have meaningful scope boundaries that practitioners should understand. Because it is applied at the code and design level without requiring a running system, it typically cannot surface configuration-dependent vulnerabilities, environment-level weaknesses, or runtime-specific behaviors. It is a taxonomy for organizing thinking, not a detection tool, and it works best when combined with complementary methods such as data flow diagram analysis, attack tree modeling, or runtime security testing to address the threat categories it surfaces.

Who it's relevant to

Software Architects and Designers

STRIDE is most directly applicable to architects and designers who are responsible for making structural decisions about a system. Applying STRIDE during design reviews allows these practitioners to evaluate whether proposed architectures introduce identifiable threat categories before implementation begins, reducing costly late-stage rework.

Application Security Engineers

Security engineers use STRIDE to facilitate threat modeling sessions, often in collaboration with development teams. They may guide the analysis, validate that identified threats map to appropriate mitigations, and ensure that the output feeds into a risk register or security backlog for remediation tracking.

Development Teams

Developers working on new features or systems benefit from STRIDE as a structured way to think about security implications of their design choices. Because the framework does not require security expertise to begin applying, it gives development teams a practical starting point for identifying what could go wrong before writing code.

Product and Engineering Leaders

Managers and technical leads responsible for release quality and risk management may use STRIDE outputs to understand the security posture of a system at design time, prioritize security investments, and demonstrate that structured threat analysis was performed as part of the development process.

Inside STRIDE

Spoofing

The threat category covering impersonation of users, systems, or components. It targets authentication controls and involves an attacker falsely claiming an identity they do not possess.

Tampering

The threat category covering unauthorized modification of data, code, or system state. It targets integrity controls and applies to data in transit, data at rest, and executable components.

Repudiation

The threat category covering the ability of an actor to deny having performed an action. It targets non-repudiation controls and relates to the adequacy of audit trails and logging mechanisms.

Information Disclosure

The threat category covering unauthorized exposure of sensitive data to parties who should not have access. It targets confidentiality controls and includes leakage through error messages, logs, side channels, and unprotected storage or transmission.

Denial of Service

The threat category covering attacks that degrade or eliminate the availability of a system or component. It targets availability controls and includes resource exhaustion, crash-inducing inputs, and volumetric attacks.

Elevation of Privilege

The threat category covering scenarios in which an actor gains capabilities or permissions beyond those they are authorized to hold. It targets authorization controls and includes both vertical privilege escalation and horizontal access violations.

Threat Enumeration Process

The structured activity in which analysts apply each STRIDE category systematically to every element of a data flow diagram, including processes, data stores, data flows, and external entities, to ensure coverage across all components.

Corresponding Security Properties

Each STRIDE category maps to a security property that a control must preserve: Spoofing to Authentication, Tampering to Integrity, Repudiation to Non-repudiation, Information Disclosure to Confidentiality, Denial of Service to Availability, and Elevation of Privilege to Authorization.

Common questions

Answers to the questions practitioners most commonly ask about STRIDE.

Does STRIDE guarantee comprehensive threat coverage if applied correctly?

No. STRIDE provides a structured checklist of six threat categories to prompt systematic thinking, but it does not guarantee comprehensive threat coverage. The quality of a STRIDE analysis depends heavily on the accuracy and completeness of the underlying system model, typically a data flow diagram. Threats that are not represented in that model will not be surfaced by the STRIDE process, regardless of how carefully the categories are applied.

Is STRIDE a threat modeling methodology or a threat classification system?

STRIDE is primarily a threat classification system, not a complete threat modeling methodology. It provides six categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) to help analysts identify and organize threats. A full threat modeling methodology requires additional steps such as system decomposition, diagramming, risk prioritization, and mitigation planning. STRIDE is typically used as one component within a broader methodology rather than as a standalone process.

At what stage in the software development lifecycle should STRIDE analysis be performed?

STRIDE analysis is most effective when performed during the design phase, before implementation begins, because changes to architecture are least costly at that stage. However, it can also be applied retrospectively to existing systems by constructing a data flow diagram of the current architecture. Many teams perform STRIDE during design and then revisit the analysis when significant features or architectural changes are introduced.

What artifacts are needed to conduct a STRIDE analysis?

A STRIDE analysis typically requires a data flow diagram (DFD) of the system being analyzed, which identifies processes, data stores, data flows, and external entities. Trust boundaries should be marked on the diagram, as many STRIDE threats are most relevant at points where data crosses a trust boundary. Supporting documentation such as architecture descriptions, authentication mechanisms, and data classification may also inform the analysis.

How do teams prioritize threats identified through a STRIDE analysis?

STRIDE itself does not include a built-in prioritization mechanism. Teams commonly pair STRIDE with a separate risk scoring approach, such as DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) or a likelihood-impact matrix, to rank identified threats. Prioritization typically considers the sensitivity of affected assets, the likelihood of exploitation, and the availability of mitigations, though the specific scoring method varies by organization.

Can STRIDE be applied to systems that are already in production, or is it only useful during design?

STRIDE can be applied to production systems, though the process typically requires reconstructing a data flow diagram from existing documentation, code review, and interviews with system owners rather than from design specifications. Applying STRIDE to a production system may reveal threats that were not addressed during initial development. However, mitigating findings in a production system is generally more constrained and costly than addressing them at design time, which is why earlier application is generally preferred.

Common misconceptions

STRIDE guarantees complete threat coverage for an application.

STRIDE provides a structured enumeration framework that reduces the likelihood of overlooking common threat classes, but it does not guarantee exhaustive coverage. Threats arising from business logic flaws, chained multi-step attacks, or context-specific trust assumptions may not surface through STRIDE analysis alone and typically require supplementary techniques.

STRIDE analysis can be performed once and then reused indefinitely for a system.

STRIDE analysis reflects the architecture and trust boundaries of a system at a point in time. As components are added, interfaces change, or deployment contexts shift, the threat model requires revisiting. A stale STRIDE model may miss threats introduced by architectural changes.

STRIDE is only applicable to the design phase and is not useful once a system is built.

While STRIDE is most efficiently applied during design, it can be applied retrospectively to existing systems by constructing data flow diagrams from documentation, code review, or runtime observation. Applying STRIDE to a built system can surface unaddressed threats and inform remediation priorities.

Best practices

Construct an accurate data flow diagram before beginning STRIDE enumeration, ensuring that all processes, data stores, data flows, and external entities are represented along with their trust boundaries, since the quality of the threat model depends directly on the accuracy of this diagram.

Apply each of the six STRIDE categories explicitly to every element in the data flow diagram rather than relying on intuition, as systematic per-element enumeration reduces the risk of omitting threats that are not immediately obvious.

Document identified threats with enough specificity to support prioritization and remediation planning, including the affected component, the applicable STRIDE category, the attacker goal, and the corresponding security property at risk.

Assign mitigations to each identified threat and verify that proposed controls address the specific STRIDE category involved, since a control appropriate for Spoofing (such as strong authentication) may not address a corresponding Elevation of Privilege threat in the same component.

Revisit and update the STRIDE model when significant architectural changes occur, including the addition of new integrations, changes to authentication mechanisms, or shifts in deployment topology, to keep the threat model aligned with the current system state.

Combine STRIDE with complementary techniques such as attack tree analysis or misuse case modeling for complex systems, as STRIDE enumerates threat categories but does not by itself model attacker sequences or multi-step exploitation paths.