Skip to content

Data Flows & Trust Boundaries

This guide explains how to model data flows and trust boundaries correctly so that threat models produce meaningful, actionable results.

It builds on the concepts introduced in Elements and focuses on how to apply them in practice, not just what they represent.

Use this guide when you want to improve model quality, avoid missed threats, or understand why certain threats appear (or don’t).

Why this matters

Most missed or misleading threats come from one of two problems:

  • Data flows are incomplete or oversimplified
  • Trust boundaries are missing, misplaced, or overused

Because many threats are triggered when data crosses a trust boundary, modeling these correctly has a direct impact on threat coverage and accuracy.

Modeling data flows correctly

Data flows represent how information moves through a system. In threat modeling, what matters most is not volume, but correctness.

What to model as a data flow

Model data flows when data:

  • Crosses a trust boundary
  • Changes format or representation
  • Is sent to or received from another component
  • Is persisted or retrieved from storage
  • Leaves or enters the system

If data moves but none of the above apply, the flow may not need to be explicit.

Tip

If you’re unsure whether to add a data flow, add it. Missing flows are more harmful than extra ones.

Common data flow mistakes

Warning

The following mistakes frequently lead to missing threats.

  • Modeling only “happy path” flows
  • Omitting authentication or authorization flows
  • Treating internal service calls as implicit
  • Combining multiple distinct flows into one
  • Ignoring error paths or fallback behavior

Each omitted flow is a potential blind spot.

Example: Oversimplified vs accurate data flows

❌ Oversimplified model

flowchart LR
    User --> App
    App --> Database
This model hides:

  • Authentication
  • API boundaries
  • Data validation
  • Trust changes

flowchart LR
    User -->|Credentials| WebApp
    WebApp -->|Auth request| AuthService
    WebApp -->|API call| BackendAPI
    BackendAPI -->|Read/Write| Database
This level of detail enables meaningful threat generation without over-modeling.

Modeling trust boundaries correctly

Trust boundaries represent changes in trust level, not just architectural layers.

A trust boundary should exist whenever assumptions about identity, control, or security change.

When to add a trust boundary

Add a trust boundary when:

  • Data enters the system from outside
  • Components are owned or operated by different parties
  • Authentication or authorization decisions occur
  • Network exposure changes
  • Data moves into a more sensitive context

Tip

Trust boundaries should reflect security assumptions, not org charts or deployment diagrams.

Common trust boundary anti-patterns

Warning

These patterns often reduce model quality.

  • No trust boundaries at all
  • A single boundary around the entire system
  • Boundaries around every component
  • Boundaries added only for visual symmetry
  • Treating internal services as implicitly trusted

Each of these can either hide risk or overwhelm the model with noise.

flowchart LR
    User --> WebApp --> Database

This implies equal trust across all components.

flowchart LR
    subgraph Untrusted
        User
    end

    subgraph Trusted
        WebApp
        BackendAPI
        Database
    end

    User -->|HTTPS| WebApp
    WebApp --> BackendAPI
    BackendAPI --> Database

This makes trust assumptions explicit and highlights boundary crossings.

Cross-boundary data flows

The highest-risk data flows are those that cross trust boundaries.

When reviewing a model, pay special attention to flows that:

  • Enter the system
  • Cross from lower trust to higher trust
  • Carry sensitive data
  • Trigger privileged operations

These flows are where:

  • Input validation matters most
  • Authentication and authorization must be correct
  • Threat density is highest

Tip

If a data flow crosses a trust boundary, pause and ask:
“What assumptions am I making about this data?”

How this affects threat generation

In Devici:

  • Attributes describe security-relevant characteristics
  • Data flows show how those characteristics interact
  • Trust boundaries determine where threats apply

If data flows or trust boundaries are missing or incorrect:

  • Threats may not be generated
  • Generated threats may appear irrelevant
  • Mitigations may seem disconnected from reality

Accurate modeling leads directly to better outcomes.

Practical guidance

When refining a model:

  1. Review all data flows that cross trust boundaries
  2. Verify each flow represents a real interaction
  3. Confirm trust boundaries match security assumptions
  4. Adjust attributes after structure is correct
  5. Re-review generated threats

Structure first, attributes second, threats last.

What’s next

Once data flows and trust boundaries are correctly modeled:

Correct structure is the foundation of effective threat modeling.