How to create a DFD for threat modeling

The core DFD elements

A threat-modeling DFD normally represents four useful concepts: processes, data stores, external entities and data flows. Trust boundaries show where the security assumptions change.

Start with scope

Define the system you are analyzing and the security questions you need the diagram to answer. A diagram that contains every microservice and operational detail can become difficult to reason about. Keep the first model focused.

Show data flows clearly

Each important interaction should have a direction and enough context to understand what crosses the boundary. Identify sensitive data where relevant and distinguish external inputs from trusted internal flows.

Mark trust boundaries

Trust boundaries can exist between users and applications, internet-facing services and internal services, tenants, subscriptions, workloads, privileged components and third-party services. They are especially valuable because many threat scenarios arise when data or authority crosses one.

Include identities and privileged operations

Modern cloud architectures often rely on workload identities, managed identities, service principals and RBAC. Make security-relevant identity relationships visible enough to reason about authorization and privilege escalation.

Validate the diagram before threat analysis

Before generating threats, check whether important actors, flows, data stores and trust boundaries are represented consistently. Missing or ambiguous flows can create false confidence in the resulting threat model.

Keep assumptions explicit

Record assumptions such as encryption in transit, encryption at rest, authentication requirements and logging expectations. Explicit assumptions make later review and change analysis much easier.