STRIDE is a threat modelling framework that classifies threats as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Practitioners use it to structure design reviews and test cases. It helps identify where authentication, integrity, logging, confidentiality, availability, and privilege boundaries need controls.
What STRIDE Is Used For in Threat Modelling
STRIDE is most useful when you need a structured way to ask, “What could go wrong here?” It gives teams a repeatable checklist for design reviews, security workshops, and test planning so threats are not missed because the review stayed too general. The model works best when applied to concrete components, trust boundaries, and data flows rather than abstract system diagrams.
That is why a threat model is usually built from the architecture outward: identify the assets, boundaries, entry points, and trust assumptions, then ask which STRIDE category each one could be exposed to. The method is intentionally simple, but it only becomes valuable when teams use it to drive specific follow-up questions, not just to label risks after the fact.
For teams starting from a blank page, NHIMG’s Threat Modelling Guide is the most direct path to the underlying practice, including trust boundaries, data flow diagrams, and common workshop patterns.
What the Six STRIDE Categories Cover
The six STRIDE categories each point to a different failure mode. Spoofing is about pretending to be a trusted party. Tampering is unauthorized change. Repudiation is the ability to deny an action because the system lacks proof. Information disclosure covers exposure of data that should remain confidential. Denial of service is anything that prevents legitimate use. Elevation of privilege is when an actor gains more authority than intended.
Those categories are broad enough to cover most application and platform designs, but they are not interchangeable. A weak authentication design may show up first as spoofing, while a logging gap may show up as repudiation. A single component can also map to more than one STRIDE class, so practitioners should avoid forcing a one-to-one mapping when the threat is really a chain of failures.
Because the model is category-based rather than product-based, it is especially helpful for design reviews that need to compare controls across different system parts. It pushes the reviewer to ask which security property is being threatened, not just which technology is involved.
When the subject is autonomous systems, the same logic still applies, but the trust boundaries often become less obvious. NHIMG’s Threat Modelling AI Agents shows how STRIDE can be paired with identity maps and tool-access analysis when an agent can act, delegate, or call tools on its own.
How Practitioners Apply STRIDE in Reviews and Testing
In practice, STRIDE is strongest when it is tied to a repeatable review sequence. Teams often start with a diagram, identify trust boundaries, enumerate external and internal actors, then ask what threats apply at each boundary crossing and each sensitive operation. That output should then drive test cases, abuse cases, or control validation tasks.
The model also helps with coverage. If a team only tests for confidentiality loss, they can miss integrity or privilege issues that are just as damaging. If they only look for technical exploits, they can miss repudiation problems where auditability and non-repudiation controls are the real gap.
For deeper technical context on attacker behaviour and exploitation patterns, CISA’s cyber threat advisories provide a useful external reference point when you want to connect a threat model to real-world exploitation patterns. For design-stage defensive controls, CISA’s Secure by Design guidance reinforces the idea that the safest controls are the ones built in before release.
Risk and Threat Considerations
STRIDE reduces blind spots, but it can also create false confidence if teams treat the categories as a checklist instead of a way to reason about trust, proof, and exposure. The main risk is under-modeling, where a review names the threat class but does not trace it to a concrete control gap, test case, or validation step.
Failure mechanism: Teams map threats at a high level, miss the boundary where the abuse occurs, and leave the real weakness in authentication, logging, input handling, or authorization untouched.
Impact: The system may appear threat-modeled while still being exposed to spoofing, tampering, hidden privilege gain, or untraceable actions that were never actually tested or mitigated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | RA-3 — Risk Assessment | STRIDE is a structured threat analysis method for design reviews. |
| SA-8 — Security and Privacy Engineering Principles | STRIDE supports design-stage security thinking and control selection. | |
| Recommendation — Use RA-3 to identify and document threats during system design reviews. Apply SA-8 to build threat considerations into architecture and design decisions. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | STRIDE is commonly used to translate architecture threats into verification goals. |
| Recommendation — Use V15 to verify that design-level threats are addressed in the application architecture. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | STRIDE-informed threat models should feed response assumptions and exercise planning. |
| Recommendation — Use CIS-17 to ensure modeled threats inform response playbooks and exercises. | ||
Practitioner Guidance
What to prioritise: Start with trust boundaries and externally reachable actions, because those are where STRIDE usually produces the highest-value findings. If a component can be called, impersonated, modified, observed, or interrupted, it deserves review before lower-risk internal paths.
What to verify: Confirm that each identified threat class leads to a concrete control or test artifact. A good STRIDE session should produce an explicit follow-up such as an auth test, audit-log review, tamper check, or denial-of-service resilience check, not just a labeled diagram.
Common mistake: Treating STRIDE as a replacement for deeper analysis. It is a framing tool, so it works best when paired with architecture knowledge, abuse-case thinking, and validation evidence.
Practitioner takeaway: STRIDE is valuable when it changes the review from “is this system secure?” to “which security property fails at which boundary, and how will we prove it?”