In a Data Flow Diagram used for threat modeling, what is a trust boundary and why does it matter?
A line drawn across a data flow wherever the level of trust changes — it marks exactly where an attacker can interject, so it is where you concentrate the security analysis.
* Trust boundaries (dashed) divide a DFD into trust zones — the point where a data flow crosses one is where an attacker can interject. *
A trust boundary is drawn intersecting a data flow at any point where data passes from one level of trust to another. Every place a flow crosses one is a spot an attacker could interject, so the boundaries together map the attack surface — and each crossing is a prompt to ask "who can read, tamper with, or spoof this data here?"
Typical trust boundaries:
- Machine boundaries — data leaving one host for another
- Privilege boundaries — e.g. normal user ↔ administrator, or user-mode ↔ kernel-mode
- Integrity boundaries — trusted internal data meeting untrusted external input
Two rules of thumb for where they fall:
- Threads inside a single native process usually sit within one trust boundary — they share the same privileges, rights, identifiers, and access, so there is no trust change between them.
- Processes talking across a network always have a trust boundary between them — they are distinct entities even if they set up a secure channel.
Gotcha: encrypting the network traffic is the "instinctive" mitigation, but encryption protects confidentiality in transit — on its own it does not stop tampering or spoofing at the boundary (those need integrity and authentication controls). That is exactly why you draw the boundary and analyse it, rather than reaching for encryption reflexively.
Go deeper:
Threat model (Wikipedia) — how DFDs, trust boundaries, and STRIDE combine to find where a design can be attacked.