Threat Modeling · Design-time

STRIDE

The most widely used framework for finding threats in a design. STRIDE walks every component, data flow and trust boundary through six categories of attack and asks, concretely, "how could this be abused?" — so the answer arrives at design time, when it's cheapest to fix.

What it is

STRIDE is a threat-modeling framework created at Microsoft to identify and classify the ways a system can be attacked. The name is an acronym for its six threat categories. Each category is the mirror image of a security property you want to hold: spoofing breaks authentication, tampering breaks integrity, repudiation breaks non-repudiation, information disclosure breaks confidentiality, denial of service breaks availability, and elevation of privilege breaks authorization.

It's a discovery tool, not a scoring tool. STRIDE tells you what can go wrong; you then prioritise the findings with a risk scheme such as DREAD and design the controls to mitigate them.

The six categories

For each element of the system, you check all six — the discipline is in not skipping any:

SSpoofing identityAn attacker pretends to be another user, service or component — e.g. forging a token or session.Authentication

TTampering with dataUnauthorised modification of data in transit, at rest or in memory — changing parameters, files or messages.Integrity

RRepudiationA user can deny an action because the system kept no trustworthy record of it — missing or forgeable logs.Non-repudiation

IInformation disclosureSensitive data is exposed to someone who shouldn't see it — PII, secrets, internal errors, a system prompt.Confidentiality

DDenial of serviceThe system is made unavailable or unaffordable — resource exhaustion, runaway cost, flooding.Availability

EElevation of privilegeAn attacker gains capabilities they shouldn't have — a normal user becoming an administrator.Authorization

How it works — the architecture

STRIDE is applied on top of a data-flow diagram (DFD): the system drawn as external entities, processes, data stores, data flows and — crucially — the trust boundaries they cross. Threats concentrate where data crosses a boundary. Each element type is naturally susceptible to a subset of the six categories, which keeps the analysis focused.

Diagram the system

External entities, processes, data stores, flows and trust boundaries — agreed by architects and security together.

Apply STRIDE per element

For each component and flow, ask the six questions and write down concrete, specific threats — not generic ones.

Rate impact & likelihood

Score each threat (e.g. with DREAD or a risk matrix) so mitigation effort is spent where it matters.

Define mitigations

Map each threat to a control — auth, integrity checks, audit logging, encryption, rate limits, least privilege — or a design change.

Example — an API that manages users

Walking one endpoint through STRIDE turns six abstract categories into six concrete tests:

Spoofing — can a token be forged or replayed to impersonate another user?
Tampering — can request parameters be modified in transit to act on someone else's record?
Repudiation — if a sensitive action is taken, is there a tamper-evident log that the user can't deny?
Information disclosure — do error messages or responses leak PII, internal IDs or stack traces?
Denial of service — can one client exhaust the service with unbounded or expensive requests?
Elevation of privilege — can a normal user reach an admin-only operation by changing a role or path?

How we audit your systems with STRIDE

We build the DFD with your team — a shared, accurate picture of components, data and trust boundaries.
We enumerate threats per element — every flow walked through all six categories, nothing skipped.
We validate, not assume — high-impact threats are confirmed against the live system with real adversarial testing.
For AI systems we extend STRIDE — adding the LLM-specific abuse classes (prompt injection, data leakage, excessive agency) from the OWASP LLM Top 10.
You get a register — each threat with element, category, severity, status and a mapped control.

How we implement it

Threat modeling only pays off if it survives contact with delivery. We embed STRIDE into your SDLC: a model produced at design review, re-visited when the architecture changes, and tied to concrete controls your engineers own. Findings are mapped to OWASP, the EU AI Act and NIST AI RMF so the evidence is recognised by auditors, and the battery is re-run as the system evolves so a design that's safe today stays safe after the next deploy.

STRIDE is a Microsoft-originated framework. This page reflects NexusFinLabs' practice and is general guidance, not legal advice.

Want a STRIDE threat model of your system or AI?

📞 Book a session ▶ Run a live scan Prioritise with DREAD →