What a threat model diagram is
A threat model diagram is a visual representation of a system's assets, data flows, trust boundaries, and the threats that could exploit each of those flows. The most common approach is a data flow diagram (DFD) annotated with STRIDE threat categories — the method pioneered at Microsoft and widely adopted across enterprise security and compliance programs. Attack trees are a complementary approach: instead of starting from the system's structure, they start from an attacker's goal and branch downward into the conditions that must be true for the attack to succeed.
Teams use threat model diagrams for three main purposes: secure design review (finding vulnerabilities before they are built in), compliance evidence (demonstrating due diligence under SOC 2, ISO 27001, HIPAA, and PCI DSS), and penetration test scoping (telling the pen test team where to focus effort). A threat model diagram produced during design is far cheaper than a vulnerability found in production.
STRIDE threat categories
STRIDE maps six threat categories to the elements of a data flow diagram. Every process, data store, external entity, and data flow in your diagram is a candidate for each category. Applying the checklist systematically ensures no class of threat is overlooked.
| Category | What it means | Example threat |
|---|---|---|
| Spoofing | Impersonating a user, service, or component | An attacker forges a JWT to authenticate as another user |
| Tampering | Unauthorized modification of data or code | An attacker intercepts and modifies an API request in transit |
| Repudiation | Denying an action without a way to disprove it | A user deletes a record and claims they never made the change |
| Information Disclosure | Exposing data to unauthorized parties | An overly verbose error message leaks a database connection string |
| Denial of Service | Disrupting availability of a service or resource | An unauthenticated endpoint accepts unlimited payload sizes |
| Elevation of Privilege | Gaining capabilities beyond what is authorized | A regular user accesses an admin-only API endpoint via IDOR |
Trust boundaries in a threat model
A trust boundary is a line in a threat model diagram where the level of trust in data or principals changes. Common trust boundaries include: the edge between the public internet and a corporate network, between a browser and an API server, between a web tier and a database, and between a user process and a privileged system process. Any data flow that crosses a trust boundary is a threat modeling event — the receiving side cannot fully trust what arrives from the other side and must validate, authenticate, and authorize before acting on it.
In a DFD, trust boundaries are drawn as dashed lines or shaded regions that visually enclose components sharing the same trust level. Annotating every data flow that crosses a boundary with STRIDE threats makes it immediately clear which controls — input validation, mTLS, rate limiting, audit logging — need to be applied at each crossing point. This visual clarity is why threat model diagrams are a required artifact in many security design review processes.
How to generate a threat model diagram with flow-chart.io
- Create a free account — 40 AI credits/month, no credit card required.
- Select the Security / Threat Model domain from the domain picker.
- Describe your system — for example: "STRIDE threat model for a web application with a React frontend, Node.js API server, and PostgreSQL database. Show trust boundaries between the browser, API, and database tiers. Label STRIDE threats on each data flow crossing a trust boundary."
- Edit and export — click any node, edge, or boundary to rename, reclassify, or annotate it. Export as SVG, PNG, or JSON for embedding in design documents or compliance evidence packages.
Frequently asked questions
- What is threat modeling?
- Threat modeling is a structured security engineering practice in which you identify assets in a system, enumerate the threats that could compromise those assets, and determine which mitigations to implement. The output is a threat model diagram — typically a data flow diagram (DFD) annotated with trust boundaries, threat vectors, and controls. Teams use threat modeling during design to find vulnerabilities before they are built in, during penetration test scoping to focus effort, and during audits to demonstrate due diligence under frameworks like NIST CSF, SOC 2, and ISO 27001.
- What is the STRIDE framework?
- STRIDE is a threat categorization framework developed at Microsoft. The acronym stands for: Spoofing (impersonating a user or component), Tampering (unauthorized modification of data or code), Repudiation (denying an action without a way to disprove it), Information Disclosure (exposing data to unauthorized parties), Denial of Service (disrupting availability), and Elevation of Privilege (gaining capabilities beyond what is authorized). Applying STRIDE to each element in a DFD produces a systematic list of threats to evaluate and mitigate.
- What is a trust boundary in a threat model?
- A trust boundary is a line in a threat model diagram where the level of trust in data or principals changes — for example, the boundary between the internet and a corporate network, between a user's browser and an API server, or between a web server and a database. Any data flow that crosses a trust boundary is a threat modeling event: the receiving side cannot fully trust the data arriving from the other side, so it must validate, authenticate, and authorize before acting. Trust boundaries are typically drawn as dashed lines or shaded regions on a DFD.
- How is a threat model diagram different from a network diagram?
- A network diagram shows physical or logical topology — devices, IP ranges, VLANs, and cable connections. A threat model diagram shows data flows, trust assumptions, and threat vectors across those flows. A network diagram might show that a server exists on a DMZ; a threat model diagram shows what data crosses the DMZ boundary, which STRIDE threats apply to each flow, and what controls (firewall rules, mTLS, input validation) are in place. Both are useful; they answer different questions.
- Does flow-chart.io support NIST CSF and zero-trust diagrams?
- Yes. flow-chart.io generates security architecture diagrams that reflect zero-trust principles — explicit verification at every trust boundary, least-privilege data flows, and labeled control points. You can describe your architecture in plain language and ask for NIST CSF or zero-trust framing; the AI labels nodes, flows, and boundaries accordingly and surfaces the five NIST CSF functions (Identify, Protect, Detect, Respond, Recover) as annotations where relevant.
- Can I export a threat model diagram for a compliance audit?
- Yes. Every diagram in flow-chart.io can be exported as SVG, PNG, or JSON. SVG and PNG exports are suitable for embedding in security design documents, architecture review records, and compliance evidence packages for SOC 2, ISO 27001, HIPAA, and PCI DSS audits. The JSON export captures the full structured object model — every node, edge, label, and boundary — so the diagram can be re-imported and edited as requirements change.
- What is the difference between STRIDE and PASTA?
- STRIDE is an attacker-agnostic checklist: you apply six threat categories to every element in your DFD and identify which threats are relevant. It is fast, systematic, and developer-friendly. PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage risk-centric methodology that moves from business objectives through technical decomposition to attack simulation and residual risk scoring. STRIDE is widely used during design and code review; PASTA is typically applied at the architecture level when a full risk-rating output is required for executive or compliance audiences. Most teams use STRIDE for day-to-day threat modeling and PASTA when they need to prioritize across a large backlog of threats.