Threat Modeling Diagrams: STRIDE, Data Flow Diagrams & Trust Boundaries (2026)

A threat modeling diagram is a structured visual representation of a system that identifies assets, trust boundaries, data flows, and potential attack vectors. Unlike a standard architecture diagram, a threat model diagram is annotated with the threats that apply to each component and flow — making it the primary artifact for secure design reviews, SOC 2 audits, and EU AI Act conformity assessments.

Threat modeling forces architects to think like attackers before the system is built. A diagram externalizes that thinking — it lets security engineers, developers, and auditors inspect the same shared model, identify gaps, and track mitigations. The Microsoft Security Development Lifecycle (SDL), OWASP Threat Dragon, and frameworks like PASTA all center threat modeling on a visual diagram of the system.

Why diagrams are central to threat modeling

Threat modeling without a diagram is guesswork. A diagram gives the team a shared, precise definition of the system boundary — what's in scope, what's out of scope, and where trust changes. Three use cases make threat model diagrams especially important in 2026:

• SOC 2 Type II: Auditors increasingly request threat model diagrams as evidence for CC6 (logical access) and CC7 (system monitoring) controls. A DFD that shows trust boundaries, data stores, and authentication flows demonstrates that security was built into the design, not bolted on.
• EU AI Act: High-risk AI systems under the EU AI Act require documented risk management processes. Threat modeling diagrams for AI inference pipelines — showing where training data enters, where model outputs leave the trust boundary, and where human oversight is enforced — directly support conformity assessment.
• Secure design reviews: Architecture review boards, AppSec teams, and security champions use threat model diagrams to evaluate new systems before they are approved for production. A diagram reduces the review from a freeform discussion to a systematic walkthrough of every trust boundary crossing.

The four components of a threat modeling diagram

1. Data Flow Diagrams (DFDs)

The Data Flow Diagram is the most common visual format for threat modeling. A DFD shows how data moves through a system — from external actors, through processes and data stores, and back out. It is the base layer on which STRIDE threats are identified. DFDs exist at multiple levels of abstraction: a Level 0 context diagram shows the system as a single process interacting with external entities; Level 1 decomposes the system into its major processes; Level 2 drills into individual services or components.

2. Trust boundaries

A trust boundary is a line on the diagram where data crosses from one security context to another — for example, from the internet to a DMZ, from a DMZ to a private VPC subnet, from one microservice to another with a different IAM role, or from a user's browser to a backend API. Every trust boundary crossing is a potential attack surface. The boundary is typically drawn as a dashed line or a shaded zone on the DFD. STRIDE threats are analyzed at each boundary crossing, not for the entire system at once.

3. STRIDE threat categories

STRIDE is the threat classification framework developed at Microsoft. Each letter maps to a threat category. Once trust boundaries are defined, the team systematically asks: does this boundary crossing expose us to each STRIDE category? Threats are documented on or adjacent to the relevant data flow arrow or component.

4. DREAD risk scoring

DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) is a scoring model for prioritizing identified threats. Each threat is scored 1–3 across the five dimensions; the sum gives a risk score from 5 to 15. In practice, DREAD is often used alongside CVSS or replaced by a simpler High/Medium/Low rating, but the five dimensions remain a useful checklist for communicating risk severity to stakeholders.

DFD elements: the building blocks

Every threat model DFD is constructed from five element types. Using consistent notation — typically the Yourdon/DeMarco DFD notation or Microsoft's Threat Modeling Tool conventions — ensures that any security engineer can read the diagram:

STRIDE breakdown: threats and examples

STRIDE provides a checklist that prevents teams from overlooking entire threat classes. For each data flow or component, ask whether each STRIDE category applies:

Prompt templates for AI-generated threat model diagrams

Describe your system to ArchitectureDiagram.ai and it generates a complete DFD with labeled trust boundaries and data flows. Use these prompt templates as starting points:

Web application DFD

API service DFD

AI agent threat model

Microservices threat model with trust boundaries

DREAD scoring in practice

Once STRIDE threats are identified, DREAD scoring prioritizes the backlog of mitigations. Each threat is scored on five dimensions from 1 (low) to 3 (high):

• Damage: How severe is the impact if the threat is exploited? (1 = minor inconvenience, 3 = full data breach or service outage)
• Reproducibility: How reliably can an attacker reproduce the exploit? (1 = requires rare conditions, 3 = always succeeds)
• Exploitability: How much skill or access does exploitation require? (1 = requires insider access and advanced skills, 3 = unauthenticated remote exploit)
• Affected users: What proportion of users are impacted? (1 = a single user, 3 = all users)
• Discoverability: How easy is the vulnerability to find? (1 = requires source code access, 3 = publicly documented or discoverable by automated scanner)

A DREAD score of 13–15 is critical, 9–12 is high, 5–8 is medium. In many teams, DREAD is simplified to a qualitative High/Medium/Low risk rating, but the five dimensions still provide a useful structured conversation about risk.

Threat modeling in DevSecOps and SOC 2 workflows

Threat modeling is most effective when it is part of the development workflow rather than a one-time pre-launch exercise. Integrating threat model diagrams into DevSecOps and compliance processes:

• Design review gate: Require a threat model DFD for any new service or significant feature before the architecture review board (ARB) approves the design. The diagram is stored in the design doc alongside the architecture diagram.
• Sprint zero: For new projects, a threat modeling session in sprint zero produces the initial DFD. The output feeds directly into the security backlog — identified threats become tickets with DREAD priority scores.
• SOC 2 evidence package: Auditors use threat model diagrams to evaluate CC3 (risk assessment) and CC6 (logical access controls). Diagrams that show trust boundary analysis, identified threats, and documented mitigations are stronger evidence than narrative descriptions alone.
• Change-triggered re-modeling: Any change that introduces a new external entity, a new data store, or a new trust boundary crossing should trigger a threat model update. Keeping the diagram current is a requirement for SOC 2 continuous monitoring.
• CI/CD security gate: Pair threat model findings with your DevSecOps pipeline — STRIDE findings for injection and authentication vulnerabilities map directly to SAST and DAST scan categories, letting you verify mitigations automatically.

Common mistakes in threat model diagrams

• Vague or missing trust boundaries

  The most common mistake. Drawing a diagram without explicit trust boundary lines means STRIDE analysis has no anchor — the team can't systematically ask "what crosses this boundary?" Every trust boundary should be named (e.g., "Internet → Load Balancer", "App Tier → Database Tier") and every data flow crossing it should be listed.

• Missing data stores

  Teams often diagram the compute and network layers but omit data stores — caches, message queues, log aggregators, and secrets managers. Data stores are primary targets for information disclosure and tampering threats and must appear explicitly in the DFD.

• Ignoring internal threats

  Many DFDs only model external attackers. Insider threats, compromised service accounts, and lateral movement within the private network are often more realistic attack vectors. Draw trust boundaries between internal services too — not just between the internet and your perimeter.

• Conflating DFD levels

  A Level 0 context diagram mixed with Level 2 service detail produces a diagram that is simultaneously too abstract and too cluttered. Maintain separate diagrams at each level of abstraction — use Level 0 for executive briefings, Level 1 for design reviews, Level 2 for detailed security analysis of individual services.

• Documenting threats without mitigations

  A threat model diagram that lists STRIDE threats without corresponding mitigations is a liability, not an asset — it documents known vulnerabilities without evidence of remediation. Every identified threat should reference its mitigation: a security control, an accepted risk decision, or a tracked backlog item.

Frequently asked questions

What is the difference between a threat model diagram and a security architecture diagram?

A security architecture diagram shows the security controls deployed in a system — firewalls, WAFs, IAM boundaries, encryption layers — without explicitly mapping attack vectors. A threat model diagram starts from the same system view but adds STRIDE threat analysis at each trust boundary crossing, DREAD risk scoring, and documented mitigations. In practice, the two are complementary: the security architecture diagram shows what defenses exist; the threat model diagram shows what threats each defense is countering.

How often should threat model diagrams be updated?

Threat model diagrams should be treated as living documents and updated whenever the system changes in a security-relevant way: adding a new external integration, introducing a new data store, changing authentication mechanisms, or restructuring service boundaries. A common policy is to require a threat model review for any pull request that touches authentication, authorization, cryptography, or external API integrations. For SOC 2 continuous compliance, diagrams should be reviewed at least annually even without system changes.

Can AI generate accurate threat model diagrams?

AI can generate a structurally correct DFD — with correct elements, labeled trust boundaries, and STRIDE annotations — from a plain English description of the system. The output is most accurate when the prompt includes specific details: the names of external entities, the protocols on each data flow, the data store types, and the trust boundary names. The resulting diagram is a starting point for human review, not a replacement for a security engineer's analysis. Use AI generation to accelerate diagram creation and ensure no elements are omitted; use expert review to validate the threat analysis and mitigation adequacy.

Related guides: DevSecOps architecture diagrams, zero trust architecture diagrams, SOC 2 architecture diagrams, and authentication architecture diagrams.