What is Threat Modeling and Why Does It Matter?

Before your team writes a single line of code, attackers are already thinking about how to break what you are about to build. Threat modeling is how you get ahead of them. It is a structured way of asking one simple question — "what could go wrong?" — and then doing something about the answers before a production incident forces your hand.

If that sounds like something only large security teams with dedicated threat-intel budgets do, think again. Threat modeling scales down to a two-person startup and scales up to a Fortune 500 enterprise. The tooling and ceremony differ, but the core practice is the same.

A plain-language definition

Threat modeling is a process for identifying, prioritising, and mitigating security risks in a system — ideally before that system is built or changed. You document what your system does, who interacts with it, where data flows, and then systematically enumerate the ways an adversary could abuse each of those elements.

The output is not a vague list of worries. It is a structured set of threats — each with a severity, a likely attacker goal, and one or more mitigations — that your team can act on. Done well, threat modeling plugs directly into your backlog, your risk register, and your acceptance tests.

Why threat modeling matters

Security incidents are expensive — not just in breach costs, but in engineer time, customer trust, and regulatory exposure. The earlier in the development lifecycle you catch a design flaw, the cheaper it is to fix. Studies consistently show that a vulnerability caught at design time costs 10–100× less to remediate than one found after deployment.

Consider some well-known incidents through this lens:

• Broken authentication flows — many credential-stuffing attacks succeed because session tokens are predictable or authentication bypass paths were never enumerated. A STRIDE-based threat model of the login flow would surface these as Spoofing and Elevation of Privilege threats.
• Misconfigured cloud storage — public S3 buckets exposing sensitive data almost always stem from a missing trust boundary analysis: who should be able to reach this data store, from where, and under what conditions?
• Supply-chain compromises — attacks like the XZ Utils backdoor exploit the assumption that build pipelines are trusted. Threat modeling the CI/CD pipeline as a system surface would flag this as a Tampering threat.

Beyond incident prevention, threat modeling satisfies compliance requirements. SOC 2, ISO 27001, PCI-DSS, and OWASP SAMM all either require or heavily recommend threat modeling as part of a mature security posture.

Core methodologies: STRIDE, PASTA, and LINDDUN

No single methodology fits every team or every system. Here is a quick orientation across the three most widely used frameworks:

STRIDE

Developed at Microsoft, STRIDE is the most widely used threat-modeling framework for software systems. It is an acronym covering six threat categories, each of which maps to a security property your system should uphold:

STRIDE pairs naturally with Data Flow Diagrams (DFDs). You map each process, data store, external entity, and data flow — then apply each STRIDE category to every element systematically.

PASTA

PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric framework in seven stages: define objectives, define the technical scope, decompose the application, analyse threats, identify vulnerabilities, enumerate attacks, and analyse risk and impact. PASTA is more process-heavy than STRIDE and is popular in organisations that need to tie threat modeling outputs directly to business risk metrics and compliance reports.

LINDDUN

LINDDUN is a privacy-focused framework that mirrors STRIDE's structure but replaces the six threat categories with privacy-specific ones: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance. If your system handles personal data and you operate under GDPR or similar regulations, LINDDUN is a strong complement to STRIDE.

When to threat model — and who should be in the room

The best time to threat model is at design time, before implementation begins. The second-best time is right now. Even for an existing system, the exercise almost always surfaces risks that have been assumed-away rather than deliberately accepted.

Practically, threat modeling fits naturally into:

• New feature design — run a lightweight model before implementation starts. A 60-minute session with a simple DFD pays dividends.
• Architecture reviews — any time the data flow or trust boundaries of a system change.
• Compliance assessments — as evidence for SOC 2, ISO 27001, or a penetration test scope document.
• Incident post-mortems — to update the threat model with newly discovered attack paths.

Threat modeling is not a security-team-only activity. The most effective sessions include the engineer who knows how the system actually works, the product manager who understands the business logic (and the edge cases users will find), and a security champion or architect who can translate risks into mitigations. The security team facilitates; they do not monopolise.

A worked example: threat-modeling a login flow with STRIDE

Let us walk through a concrete example. Imagine a web application with the following login flow:

1. The user enters email and password in the browser.
2. The browser sends credentials over HTTPS to the authentication API.
3. The API checks credentials against the user database.
4. On success, the API issues a JWT and stores a refresh token in the database.
5. The browser stores the JWT in localStorage.

Applying STRIDE to each element gives us a starting threat list:

• Spoofing (API → User): Is the HTTPS certificate validated? If not, an attacker on the same network can intercept credentials. Mitigation: enforce HSTS, pin the certificate in mobile clients.
• Tampering (Browser → API data flow): Can an attacker replay a captured request? Mitigation: short-lived JWT expiry, refresh token rotation.
• Repudiation (User → API): If a user denies logging in, can we prove they did? Mitigation: log authentication events with IP and user-agent; retain logs.
• Information Disclosure (API → Database): Does a failed login response distinguish between "user not found" and "wrong password"? Mitigation: return a generic error message regardless of failure reason.
• Denial of Service (Browser → API): Is there a rate limit on the login endpoint? Mitigation: IP-based and account-based rate limiting, CAPTCHA on repeated failures.
• Elevation of Privilege (JWT stored in localStorage): Can a malicious script on the same origin steal the token? Mitigation: consider httpOnly cookies instead of localStorage; implement a strict Content Security Policy.

Six threats from a ten-minute exercise. Each one now has a clear mitigation that can go straight into your backlog. That is the value of threat modeling.

Getting started today

You do not need expensive tooling or a dedicated security team to start threat modeling. You need three things:

1. A diagram of your system — even a rough whiteboard sketch of the data flows and trust boundaries.
2. A structured framework — STRIDE is a great starting point.
3. A place to track the threats you find — a risk register, a backlog column, or a dedicated threat-tracking tool.

In the next post in this series, we dive deeper into Data Flow Diagrams — the most powerful artifact for systematic threat modeling — and show you step by step how to build one using ThreatTree.