What Threat Modeling Actually Produces
Threat modeling produces a prioritized list of risks specific to what you are building, with enough context to make decisions about mitigations. That is the complete definition. It is not a document format, a diagramming exercise, or a compliance activity. The output is actionable decisions: what to build differently, what controls to add, and what to test during implementation.
In practice, the output of a good threat modeling session is three things: a map of how data and control flow through the system (the data flow diagram), a list of threats specific to that system organized by category, and a set of mitigations with owners and timelines. Teams that skip the third artifact produce threat models that generate findings but no action. The findings sit in a document, get reviewed at the next annual security review, and are superseded by a new version of the same document before anyone acts on them.
Threat modeling is most valuable when it happens before code is written for a new component, when trust boundaries change, and when external integrations are added. These are the moments when the architecture is still malleable and the cost of change is low. A threat model produced after a system is built can still find issues, but the remediation cost is higher and some risks may be baked in by the chosen architecture.
When to Do It (and When It Is Too Late)
The right time to threat model is during design, not after implementation. For a new microservice, that means before the first line of code: when the team is deciding how authentication works, which data the service will handle, and how it will communicate with other services. For a change to an existing system, it means before the PR is opened: when the developer is deciding how to implement a new feature that touches a trust boundary.
The practical trigger for a threat modeling session is any of the following: a new service or component is being designed, authentication or authorization logic is changing, data flows to or from an external system are being added, sensitive data is being stored or transmitted in a new way, or a new user-facing input surface is being created. If none of these apply to a change, a full threat modeling session is probably not necessary.
When it is too late: threat modeling after a system has been in production for months and the architecture is fixed is not worthless, but it is expensive. The session will surface issues that require significant rework rather than small adjustments. If you are in this position, focus the session on the highest-risk components (authentication, data access, external integrations) and use the output to prioritize remediation work rather than to inform design decisions that have already been made.
STRIDE: The Most Practical Framework for Engineering Teams
STRIDE is a threat categorization framework developed at Microsoft that organizes threats into six categories. It is the most practical framework for engineering teams because each category maps directly to a question engineers can answer about their own system without requiring security expertise.
| Category | What it covers | Example | Primary control |
|---|---|---|---|
| Spoofing | Impersonating another user, system, or component | Forging a JWT to act as a different user | Authentication (strong identity verification) |
| Tampering | Modifying data in transit or at rest without authorization | Altering a request payload to change an order amount | Integrity controls (HMAC, digital signatures, input validation) |
| Repudiation | Denying that an action occurred when it did | A user claims they did not initiate a transaction that they did | Non-repudiation (audit logs, signed receipts) |
| Information disclosure | Exposing data to unauthorized parties | An API returning fields the calling user should not see | Authorization, encryption, access control |
| Denial of service | Making a system unavailable to legitimate users | Sending large payloads to exhaust memory in a parsing function | Rate limiting, input size limits, resource quotas |
| Elevation of privilege | Gaining capabilities beyond what was authorized | A regular user accessing an admin endpoint via a missing authorization check | Least privilege, authorization checks on every action |
To apply STRIDE, take each significant component in the system being designed and work through all six categories. For each category, ask: given the current design, is this threat possible? What controls exist to prevent it? If the answer to the first question is yes and the answer to the second is none or weak, that is a finding that needs a mitigation decision before implementation begins.
STRIDE is not exhaustive. It does not cover supply chain risks, physical security, or social engineering. For most engineering teams designing web services and APIs, it covers the categories that produce the highest-impact vulnerabilities and is tractable enough to complete in a focused session without specialist input.
The Three Artifacts That Make Threat Modeling Useful
A threat modeling session without structured outputs is a conversation that produces no decisions. The three artifacts that convert the session into actionable work are the data flow diagram, the threat list, and the mitigation register.
Data flow diagram (DFD). The DFD maps every component in the system, every data store, every external entity (users, third-party services, other internal services), and the data flows between them. Trust boundaries are drawn as lines on the diagram: data crossing a trust boundary is where threats are most likely to exist. The DFD does not need to be formal; a whiteboard photo or a simple box-and-arrow drawing is sufficient. What matters is that it is complete enough that the team can agree it represents the actual system.
Threat list. For each trust boundary crossing and each significant component, apply the STRIDE categories and record every threat identified, even the ones that are already mitigated. The full list matters because it represents the team's shared understanding of what can go wrong. Threats that are already mitigated should be documented with the existing control noted. Threats with no mitigation go to the next artifact.
Mitigation register. Each unmitigated threat gets a record with four fields: the threat description, the proposed mitigation, the owner (a specific person), and the timeline. Without an owner and timeline, mitigations do not get implemented. This register becomes a checklist for implementation and for code review: reviewers can verify that the identified mitigations are actually present in the code.
Running a Threat Modeling Session Without a Security Team
Most engineering teams do not have a dedicated security function available for every design review. Threat modeling without a security expert is possible and often produces better results than waiting for a security review that arrives after implementation is complete.
The session requires three things: the right attendees, a structured process, and a time limit. The right attendees are the engineers who will build the system, the engineer or architect who designed it, and ideally someone from the team that will operate it. A security specialist is useful but not required. Engineers who understand the system deeply can identify the same threats a security specialist would identify for most standard web service and API designs.
A practical process for a one-hour session looks like this. Spend the first fifteen minutes drawing the DFD on a whiteboard or collaborative tool and agreeing that it represents the actual system. Spend the next thirty minutes working through STRIDE categories for each trust boundary crossing, calling out threats as they are identified and recording them in a shared document. Spend the final fifteen minutes reviewing the threat list, identifying which threats lack mitigations, and assigning an owner and timeline to each.
Common failure modes in sessions run without security specialists: teams focus on threats they already know how to fix and skip the categories they are less comfortable with (repudiation and elevation of privilege are frequently underdiscussed), and teams identify threats but do not complete the mitigation register before the meeting ends. Setting a timer for the mitigation register portion of the session and not letting the meeting end without completing it prevents the second failure mode.
For recurring threat modeling, the output of each session should be stored alongside the design documentation for the service. When the service changes in a way that affects the DFD, the threat model should be updated. Treating the threat model as a living document rather than a one-time artifact keeps it useful as the system evolves.
Connecting Threat Models to Your Testing Program
A threat model is most useful when its outputs directly drive testing decisions. The threat list produced during design should become a testing checklist during implementation and a prioritization input for security testing at release.
During implementation, each threat in the mitigation register should have a corresponding test. If the threat is "forged JWT allows access as another user," the test is "attempt to authenticate with a forged JWT and verify the request is rejected." These tests can be unit tests, integration tests, or entries in a manual test plan, but they need to exist. A threat model that does not produce tests is not being used as a tool; it is being used as documentation.
At release, the threat model provides context that automated scanning tools lack. Application security testing tools like static analyzers and dynamic scanners find vulnerability classes but do not understand the specific trust boundaries and data flows in your system. The threat model bridges that gap: it tells the tester which components and flows are highest risk, so testing effort can be focused where it matters most.
Kira validates whether the threats identified in your model are exploitable in practice. Where threat modeling identifies the attack surface and the theoretical risks, Kira runs against the actual codebase and confirms which findings are reachable and triggerable with real payloads. This connects design-time assumptions to runtime reality: the threat model tells you what should be protected, and Kira tells you whether it actually is. Pairing a threat model with automated exploit validation closes the loop between design intent and implementation correctness.
The combination of static analysis, dynamic testing, and composition analysis covers different parts of the attack surface. Threat modeling tells you where to point those tools. API security testing in particular benefits from threat model inputs: API surfaces are where information disclosure and elevation of privilege threats most commonly materialize, and a threat model that has already identified which API endpoints cross trust boundaries gives testers a focused starting point rather than requiring them to map the entire surface from scratch.
For teams building a secure development lifecycle, threat modeling is the design-phase component of the SDL. It is the activity that catches architectural risks before they become implementation bugs. The SDL then carries those risks through to automated checks in CI, code review, and release gates, ensuring that the mitigations identified in the threat model are verified at every subsequent phase.
FAQ
How long does a threat modeling session take for a typical microservice?
A focused threat modeling session for a single microservice takes between 45 minutes and 90 minutes when the engineers who built or will build the service are in the room. The session should produce a complete DFD, a threat list covering all STRIDE categories for each trust boundary, and a mitigation register with owners assigned. Sessions that run longer than 90 minutes are usually covering too broad a scope (multiple services should be modeled separately) or are getting stuck on implementation details rather than design-level risks. If you cannot complete a threat model in 90 minutes, narrow the scope to the components with the highest data sensitivity or the most external exposure and model those first.
What is the difference between STRIDE and PASTA threat modeling?
STRIDE categorizes threats by type (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) and works from the attacker's capability toward the system. PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage risk-centric framework that works from business objectives through technical analysis to attack simulation and risk scoring. STRIDE is faster, requires less specialist input, and produces outputs that engineering teams can act on without a formal risk management process. PASTA is more rigorous and produces outputs that map to business risk, making it better suited to organizations with formal risk management programs. For most engineering teams doing threat modeling as part of design reviews, STRIDE produces more actionable outputs per hour of effort. PASTA is a better fit when the threat model output needs to inform business decisions about risk acceptance and investment prioritization.
Do I need a security expert in the room to run a useful threat modeling session?
No. A security expert is useful for catching threats that engineers might not think of, particularly in less common categories like repudiation and for systems with unusual trust boundary configurations. But engineers who understand the system they are building can identify the majority of threats that a security specialist would identify for standard web services and APIs. The structured STRIDE process compensates for the absence of specialist knowledge by providing a systematic checklist of threat categories to work through. The more important requirement is that the engineers who know the system are in the room and that the session produces a completed mitigation register before it ends. A threat modeling session run by engineers without a security specialist, but with a clear process and completed outputs, is more useful than a session run with a specialist that produces a threat list but no assigned mitigations.