How to Do Threat Modeling: A Step-by-Step Guide for Your First Real System

Most writing about threat modeling explains what threat modeling is. This is a guide to doing one. By the end you will have walked a complete model of a real system: a small e-signature SaaS carried through every step, from the first box on the diagram to a decision with a name attached.

There is one prerequisite, and it is a posture rather than a tool. Threat modeling is a design activity, not a security audit. An audit asks whether what you built matches a standard, and it happens afterward. A threat model asks what could go wrong with what you are about to build, and it pays for itself before the code exists, when changing the answer costs a conversation instead of a quarter. Approach your first model looking for findings to report and you will produce a report. Approach it looking for design decisions and you will produce a better system. The steps are identical; the posture is not.

Step 0: pick a system worth modeling

The first mistake is scope. "Let us threat model the platform" produces a diagram nobody can read and an argument about what counts as a component. Model one system and its immediate neighbors: the thing your team owns and changes, plus whatever sits at its edges. Everything past the first hop is an external entity with an arrow pointing at it. You are modeling a design, not documenting an estate.

Not every system deserves a model this week. Four triggers earn the effort, and they are worth writing down as a team rule:

• A new system, or a materially new service inside an existing one.
• A new external integration, because someone else's code or infrastructure now sits on your data path.
• A change to authentication or authorization, which redraws who can reach what.
• A new category of data, especially anything regulated or anything a customer would hate to see leak.

Our running example trips three of the four on day one: it is new, it integrates a third-party email provider, and it handles executed contracts, a data category whose failure mode is a courtroom.

A threat model is one piece of a wider process: the tiering that decides how deep to go, and the sign-offs that make the output binding, belong to what a security design review contains. For a first model, pick a system important enough that people will care about the output and small enough that you can finish it.

Step 1: draw what you are building

A data flow diagram has four kinds of thing on it, plus one kind of line we draw in the next step. External entities are actors and systems outside your control. Processes are code that does something. Data stores are places data rests. Data flows are the labeled arrows between them. Trust boundaries, the fifth element type, are where the level of trust changes.

For the e-signature service, the external entities are the sender who uploads a contract, the signer who receives a link (often not a customer, often with no account at all), and the email provider that carries it. The processes are the web app, the API behind it, and the signing service that renders the document, captures the signature, and seals the result. The data stores are the document store holding uploaded and executed files and the audit log recording every view, signature, and download.

Then label the flows, because the labels are where threats come from. The sender uploads a PDF to the API, which writes it to the document store and asks the signing service to create a request. The signing service asks the email provider to deliver a link. The signer opens it, is served the document, and posts a signature back. The signing service writes the sealed file, appends to the audit log, and both parties later download the executed contract.

That takes ten minutes to draw. Fidelity is not the goal; agreement is: if two engineers draw the same system differently, you have found something before enumerating a single threat.

Step 2: mark the trust boundaries

Now draw the lines where trust changes. A trust boundary is any place a request crosses from a less trusted context into a more trusted one, or where control passes to a party you cannot inspect. Threats cluster on these lines because they are where an assumption is being made.

The e-signature service has three that matter. The first is the public internet meeting the API. Two different populations cross it: authenticated senders with accounts, and unauthenticated signers holding nothing but a link. That second population is the interesting one, because the link is the credential, and a credential that arrives by email has properties a password does not.

The second is the API meeting the signing service. Both are yours, which is exactly why teams skip it. The signing service holds the sealing key and the authority to declare a document executed, so anything that can ask it to seal a file has borrowed the most consequential privilege in the product.

The third is your infrastructure meeting the email provider. There, a URL granting access to a confidential document leaves your control, sits on someone else's servers, is scanned by mail filters, and lands in an inbox whose security is not your decision. Draw the boundary where you can no longer enforce anything, because that is what the line means.

Step 3: enumerate threats with STRIDE

With a diagram and boundaries, enumeration becomes mechanical, which is the point. STRIDE gives you six categories to ask of each element: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Apply only the categories that fit the element type, and work one element at a time. We wrote up all six with worked examples in STRIDE, explained with examples; here we walk two elements of the running example properly, because two done well teach more than twelve done thinly.

Phrase every threat as a sentence with an actor, a verb, and an asset. "Information disclosure on the document store" is a label. "An engineer holding the bucket-wide read role opens any customer's executed contract without the account ever knowing" is a threat, and only the second can be argued with, assigned, or closed.

The document store. As a data store it attracts tampering, repudiation, information disclosure, and denial of service. Tampering: a compromised service credential overwrites the stored PDF between the moment the signer reviews it and the moment the signature is applied, so the seal attaches to a document nobody agreed to. Information disclosure: download links are pre-signed URLs with a long expiry, so a signer forwards the mail and the recipient opens the contract nine months later. Same category again: object keys are sequential document IDs, so anyone holding one valid link can reason about the others. Repudiation, which lands here because the audit log shares the store's access model: the operator role that can write audit records can also delete them, so the record of privileged action is editable by the privileged. Denial of service: the API accepts an unbounded upload, and rendering a pathological PDF ties up the signing service for every other tenant.

The email boundary. As a flow crossing to a third party it attracts tampering, information disclosure, and denial of service, and the external entity behind it attracts spoofing. Information disclosure: the signing link is a bearer token in plaintext mail, so both mail providers and anyone with access to either inbox can open the document. Tampering: the provider's click-tracking rewrites your signing URL, routing every signer through a third party that now sees who opened what and when. Spoofing: an attacker who can send mail appearing to come from your domain issues a signing request that looks exactly like yours. Denial of service: the provider throttles you over a deliverability complaint, and signing stops for everyone until a support ticket clears.

That is nine threats from two elements, and none of them required creativity. They required a diagram and six questions.

Step 4: decide every threat

A list of threats is not a threat model. A threat model is a list of decisions. Every threat gets one of three outcomes, and each has a required field.

Mitigate, and name the control. Not "improve access control" but "download URLs expire in fifteen minutes and are bound to the signer's session, and the executed copy is delivered through an authenticated page rather than a link." A mitigation without a named control is an intention.

Accept, and name the owner. Someone with the authority to carry the consequence has to say that the risk is acceptable and why. "The signing link is a bearer credential in email, accepted for launch because the alternative is an account for every counterparty, with a fourteen-day expiry and one-time use as compensating controls. Accepted by the VP of Product, reviewed at GA." An acceptance with no name is a threat everyone quietly assumes someone else handled.

Rule out of scope, and write down why. Compromise of the email provider's own infrastructure is not something your design controls, and saying so in one line is legitimate. Silence is not, because next quarter nobody can tell a threat that was considered and dismissed from one that was never seen.

Then count the threats that ended in none of the three. That number, unmitigated threats by severity, is the one metric the model owes the rest of your program. It goes to the risk register, it tells you whether the design is ready, and it makes coverage a fact rather than a claim.

Step 5: end with names on a decision

A model that ends when the analysis ends is a document. A model that ends with a sign-off is a decision, and only decisions change what ships.

Three things close the loop. First, a named sign-off: the engineering owner confirming the mitigations are real and scheduled, and the risk owner accepting what is left. Second, a baseline: the diagram, the threats, and the decisions, stored where the next person can find them and versioned against the design they describe. Third, re-review triggers agreed in writing, the same four from Step 0. When one fires you review the delta rather than remodeling the system, and the delta takes an hour.

For the e-signature service, that means the key custody and link-expiry decisions carry owners and dates, the acceptance of email as a delivery channel has a review date at general availability, and adding an identity verification vendor for high-value contracts automatically reopens the model. The point is not ceremony. It is that six months from now, when someone asks why signing links work the way they do, the answer exists.

The anti-patterns

The failure modes of first threat models are consistent enough to list, and each is a way of substituting effort for decisions.

The common thread is that a threat model is judged by what it changed, not by how much of it there is.

Overall flow

Six steps, in the order that keeps a first model finishing.

Tooling, honestly

Do the first two or three models on a whiteboard with a six-column table: element, category, threat, control, owner, status. That is not a compromise; it is the correct tool for learning the method, because all the effort goes into the analysis and none into the software.

When drawing by hand starts to cost more than it returns, OWASP Threat Dragon is the honest free step up: a diagram editor with STRIDE prompts attached to elements, models stored as JSON in your repository, and no license conversation. For a team modeling a handful of systems a year, it may be the last tool you need.

What changes on a platform is not the analysis. It is what happens to the models later. They accumulate into a library instead of scattering across repositories, so "which systems have been modeled since their architecture changed" has an answer. Threats connect to the controls that answer them, the evidence those controls produce, and the risks left open, so a mitigation is traceable rather than asserted. Sign-offs sit on the model rather than in a chat thread. That is the case for threat modeling software: relationships between artifacts, not better diagrams.

AI belongs in the same frame. Our AI threat modeling studio reads the diagram you already have, registers its elements, and proposes candidate threats, batched behind one approval card. Every proposal waits on explicit human approval before anything is written, the model you use is your own, and the Step 4 judgment calls stay where they belong. If the system you are modeling contains a model itself, the categories hold but the questions underneath them change, and we work through that set in threat modeling AI systems.

Whichever tool you use, the sequence is the one you just read. Scope it, draw it, mark the boundaries, walk the letters, decide every threat, and put a name on the result. Do that once and the method stops being theory. Do it five times and it stops being an event.