STRIDE Threat Modeling Framework: Complete Guide to Categories, Application, and Best Practices

The STRIDE threat modeling framework is a structured method for identifying security threats in software systems by classifying them into six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. It was developed at Microsoft in 1999 by Loren Kohnfelder and Praerit Garg as a mnemonic to help engineers systematically reason about threats during design rather than after deployment.

Each STRIDE category maps to a security property that an attacker seeks to violate:

The framework’s purpose is to provide teams with a repeatable checklist for threat identification rather than relying on ad hoc brainstorming. By walking through each element of a system, processes, data stores, data flows, and external entities, and asking “how could this be spoofed, tampered with, repudiated, disclosed, denied, or elevated?”, teams surface threats that unstructured reviews miss.

In modern DevSecOps and the software development lifecycle (SDLC), STRIDE is typically applied during the design phase, before code is written, and revisited whenever architecture changes. It integrates into threat modeling as code, CI/CD security gates, and cloud architecture reviews, making it one of the most widely taught and implemented threat modeling frameworks in application security programs today.

The Six Categories of the STRIDE Threat Modeling Framework

Summary Comparison Table

Spoofing

Definition: Spoofing occurs when an attacker impersonates a legitimate user, device, or system component to gain unauthorized access.

Real-world examples (2026-relevant):

• Forged JWT tokens used to impersonate a service-to-service API call in a microservices mesh
• Fake OAuth consent screens tricking users into authorizing a malicious app
• Spoofed AI agent identities in multi-agent orchestration systems where one agent impersonates another to escalate tool access
• DNS spoofing redirecting cloud API traffic to attacker-controlled endpoints

Detection signs:

• Authentication logs showing impossible travel or duplicate active sessions
• Certificate mismatches or unexpected identity provider redirects
• API calls with valid-looking tokens but anomalous request patterns

Mitigations:

• Strong mutual TLS (mTLS) for service-to-service communication
• Multi-factor authentication (MFA) for user-facing systems
• Signed and short-lived tokens (JWT with strict expiry and audience validation)
• Certificate pinning for critical clients

Tampering

Definition: Tampering is the unauthorized modification of data, code, or configuration, either in transit or at rest.

Real-world examples (2026-relevant):

• Supply chain attacks modifying open-source packages or CI/CD pipeline artifacts before deployment
• Man-in-the-middle modification of API payloads lacking integrity checks
• Prompt injection that tampers with an AI system’s context window to alter model behavior
• Unauthorized edits to Infrastructure-as-Code (IaC) templates in shared repositories

Detection signs:

• Checksum or hash mismatches on binaries and container images
• Unexpected diffs in configuration or IaC state files
• Integrity monitoring alerts on critical system files

Mitigations:

• Cryptographic signing of code, containers, and IaC artifacts
• Immutable infrastructure and write-once audit logs
• Input validation and schema enforcement on all API boundaries
• File integrity monitoring (FIM) on production systems

Repudiation

Definition: Repudiation is the ability of a user or system to deny having performed an action, when no reliable evidence exists to prove otherwise.

Real-world examples (2026-relevant):

• A user denying they approved a financial transaction due to missing audit trails
• An AI agent performing an autonomous action with no traceable decision log, making accountability impossible
• Admins disabling logging before performing unauthorized changes in cloud consoles
• Shared service accounts making it impossible to attribute actions to an individual

Detection signs:

• Gaps or tampering in audit logs
• Actions attributed to shared or generic accounts
• Missing timestamps, digital signatures, or correlation IDs on critical transactions

Mitigations:

• Centralized, tamper-evident logging (write-once, cryptographically chained logs)
• Digital signatures on critical transactions
• Unique identity per user/service — eliminate shared credentials
• Detailed audit trails for AI agent decisions and tool invocations

Information Disclosure

Definition: Information Disclosure is the exposure of data to individuals or systems not authorized to access it.

Real-world examples (2026-relevant):

• Misconfigured cloud storage buckets exposing customer data
• Verbose API error messages leaking stack traces or internal schema details
• AI models leaking training data or sensitive context through inference (model inversion, prompt leakage)
• Overly permissive IAM roles allowing cross-tenant data access in multi-tenant SaaS

Detection signs:

• Data loss prevention (DLP) alerts on outbound traffic
• Public exposure findings from cloud security posture management (CSPM) tools
• Unexpected data appearing in logs, caches, or third-party analytics

Mitigations:

• Encryption at rest and in transit (TLS 1.3, AES-256)
• Least-privilege IAM and strict tenant isolation
• Data classification and DLP policies
• Output filtering and redaction for AI model responses

Denial of Service

Definition: Denial-of-Service (DoS) attacks degrade, disrupt, or block legitimate access to a system or resource.

Real-world examples (2026-relevant):

• Volumetric DDoS attacks against public-facing APIs
• Resource exhaustion attacks against AI inference endpoints (token-flooding, expensive prompt loops)
• Algorithmic complexity attacks exploiting unbounded regex or recursive parsing in APIs
• Rate-limit bypass in serverless architectures causing runaway cloud costs (economic DoS)

Detection signs:

• Sudden spikes in latency, error rates, or compute cost
• Abnormal request volume from single sources or botnets
• Queue backlogs or autoscaling thresholds repeatedly triggered

Mitigations:

• Rate limiting and request throttling at API gateways
• Auto-scaling with hard cost/resource ceilings
• Web Application Firewalls (WAF) and DDoS protection services
• Circuit breakers and timeout enforcement on downstream calls

Elevation of Privilege

Definition: Elevation of Privilege occurs when an attacker gains capabilities or access rights beyond what was intended or assigned.

Real-world examples (2026-relevant):

• Container escape vulnerabilities granting host-level access from a compromised pod
• Overprivileged AI agent tool permissions allowing it to perform actions outside its intended scope
• Privilege escalation through misconfigured Kubernetes RBAC roles
• Exploiting insecure deserialization to execute code with elevated system rights

Detection signs:

• Unexpected role or permission changes in IAM logs
• Processes running with higher privileges than their baseline
• Anomalous lateral movement between network segments or namespaces

Mitigations:

• Principle of least privilege enforced across users, services, and AI agents
• Regular privilege access reviews and just-in-time (JIT) access
• Kubernetes RBAC hardening and pod security standards
• Sandboxing and strict tool-permission scoping for AI agents

How the STRIDE Threat Modeling Framework Works

Step-by-Step Process

1. Define scope – Identify the system, application, or feature being modeled.
2. Build a Data Flow Diagram (DFD) – Map processes, data stores, data flows, and external entities.
3. Identify trust boundaries – Mark where data crosses between zones of differing trust (e.g., internet to internal network, user to service).
4. Apply STRIDE to each element – Systematically ask which of the six threats apply to each process, data store, data flow, and external entity.
5. Document threats – Record identified threats with affected components and trust boundaries crossed.
6. Prioritize threats – Rank them by risk, often using a complementary model such as DREAD (see Limitations section).
7. Define mitigations– Assign controls to each validated threat.
8. Validate and iterate – Review the model when architecture changes; treat it as a living artifact.

DFD Elements and Trust Boundaries

A Data Flow Diagram breaks a system into four element types. STRIDE threats do not apply equally to all of them. This is the basis of STRIDE-per-element, a technique that maps only relevant threat categories to each DFD element type, reducing analysis noise.

*Repudiation applies to data stores that function as logs.

STRIDE-per-Element vs. STRIDE-per-Interaction

• STRIDE-per-element: Apply the relevant threat categories (per the table above) to each individual DFD element. Efficient for large systems; reduces redundant analysis.
• STRIDE-per-interaction: Analyze the interaction between two elements (e.g., user → API) as a unit, considering all six threats for that specific data flow. More thorough for high-risk trust boundary crossings, but more time-intensive.

Teams typically use STRIDE-per-element for broad system coverage and reserve STRIDE-per-interaction for flows crossing critical trust boundaries.

Practical Checklist

•  DFD created and reviewed with system owners
•  All trust boundaries explicitly marked
•  STRIDE applied to every process, data store, data flow, and external entity
•  Threats documented with component, category, and trust boundary
•  Threats prioritized by risk
•  Mitigations assigned and tracked to closure
•  Model stored in version control alongside architecture docs
•  Model re-reviewed on significant architecture change

Evolution and History of STRIDE

STRIDE remains a foundational reference point in application security standards, referenced across NIST guidance, OWASP’s Application Security Verification Standard (ASVS) discussions, and vendor-neutral secure design curricula.

Strengths and Limitations of the STRIDE Framework

Strengths and When to Use It

• Systematic coverage: Forces structured analysis rather than relying on testers’ intuition.
• Early-stage applicability: Works before code exists, during architecture and design review.
• Vendor-neutral and well-documented: Extensive tooling, training material, and industry precedent.
• Scales via STRIDE-per-element: Adaptable to both small features and large distributed systems.
• Best used when: Designing new systems or major features, performing architecture reviews, onboarding teams to structured threat modeling, or satisfying compliance requirements that call for documented threat analysis.

Limitations and How to Address Them

Relevance in 2026

STRIDE remains actively used in cloud-native architecture reviews, zero-trust design validation, and compliance-driven security programs (SOC 2, ISO 27001, NIST SSDF). Its extension into AI system threat modeling, covering agent permission boundaries, model integrity, and inference-time data disclosure, keeps it relevant as organizations threat-model LLM-integrated applications alongside traditional software.

Tools That Support the STRIDE Threat Modeling Framework

Frequently Asked Questions FAQ’s

What does STRIDE stand for?

STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege, six categories of security threats.

Who created the STRIDE threat modeling framework?

Loren Kohnfelder and Praerit Garg created STRIDE at Microsoft in 1999 to help engineers systematically identify threats during system design.

How do you apply STRIDE to a data flow diagram?

Build a DFD showing processes, data stores, data flows, and external entities, mark trust boundaries, then evaluate each element against the STRIDE categories relevant to its type (see the DFD element mapping table above).

What is the difference between STRIDE-per-element and STRIDE-per-interaction?

STRIDE-per-element applies relevant threat categories to individual DFD components for efficient broad coverage; STRIDE-per-interaction analyzes all six threats across a specific interaction between two elements for deeper analysis at critical trust boundaries.

Is STRIDE still relevant in 2026?

Yes. STRIDE remains standard practice for cloud-native, microservices, and AI/LLM system threat modeling, and is commonly referenced in compliance frameworks and secure SDLC processes.

Does STRIDE replace DREAD?

No. STRIDE identifies threat categories; DREAD scores and prioritizes the threats STRIDE identifies. They are complementary, not competing, frameworks.

Can STRIDE be used for AI and LLM systems?

Yes, with extension. Teams map AI-specific risks (prompt injection, model inversion, agent over-permissioning) onto STRIDE categories, often supplementing with OWASP’s LLM Top 10 and MITRE ATLAS for AI-specific detail.

What is the difference between STRIDE and PASTA?

STRIDE is a threat-categorization checklist typically applied at the design/architecture level. PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric methodology that incorporates business impact and attacker simulation; teams often use STRIDE for technical threat identification and PASTA for business-risk alignment.

What tools support STRIDE threat modeling?

Microsoft Threat Modeling Tool and OWASP Threat Dragon are the most widely used free tools; IriusRisk and Threagile are common commercial and threat-modeling-as-code alternatives.

How often should a STRIDE threat model be updated?

Whenever system architecture changes materially, new components, new trust boundaries, new data flows — and at minimum during periodic security review cycles (commonly annually or per major release).

What is the STRIDE framework for threat modeling?

STRIDE is a threat classification framework, created by Microsoft engineers Loren Kohnfelder and Praerit Garg in 1999, that categorizes security threats into six types — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege — applied against a system’s data flow diagram to systematically identify how each component or interaction could be attacked.

What are the six components of the STRIDE threat model?

The six components are: Spoofing (impersonation, violates authentication), Tampering (unauthorized modification, violates integrity), Repudiation (denying an action with no proof, violates non-repudiation), Information Disclosure (unauthorized data exposure, violates confidentiality), Denial of Service (blocking legitimate access, violates availability), and Elevation of Privilege (gaining unauthorized capabilities, violates authorization).

What are the 5 steps of threat modeling?

The five general steps are:

• decompose the system into a data flow diagram with trust boundaries,
• identify threats using a method like STRIDE,
• assess and prioritize the identified risks,
• mitig, repeating the process as the system and its architecture evolve.

What is the 4 question framework for threat modeling?

The 4-question framework, popularized by Adam Shostack, asks:

• What are we building?
• What can go wrong?
• What are we going to do about it?
• Did we do a good enough job?

STRIDE is commonly used to answer question two, providing the structured categories for identifying what can go wrong.