A trust boundary is a line drawn on a diagram where data passes between components that deserve different levels of trust, such as a browser and your server, or your service and a third party. Threats cluster at these lines, so they are where a threat modeling session should spend most of its time.
The five parts of a useful diagram
The OWASP Threat Modeling Cheat Sheet says a good model clearly shows trust boundaries, data flows, data stores, processes and external entities. It describes these as likely attack points and key inputs for later steps.
- External entities are things outside your control: users, partner systems, third party APIs.
- Processes are your code running somewhere.
- Data stores hold data at rest.
- Data flows show movement between them.
- Trust boundaries mark where trust changes.
Where boundaries usually go
Start with the obvious ones:
- Between the internet and your edge.
- Between your application and its database.
- Between your service and a vendor API.
- Between a regular user area and an admin area.
- Between tenants, if your product is multi tenant.
- Between your pipeline and the environment it deploys to.
The OWASP Top 10 entry on insecure design also recommends separating tiers at system and network layers by exposure and isolating tenants by design. Those separations are trust boundaries you can see in the architecture.
What to ask at each boundary
For every flow that crosses a line, ask:
- Who is on each side, and do they authenticate?
- Is the data validated when it crosses?
- Can someone on the lower trust side tamper with it in transit?
- What happens if the other side is slow, wrong or hostile?
- Is there a record of what crossed?
These map neatly onto STRIDE categories, so you can combine the two techniques.
Drawing tips
Keep the first version rough. The cheat sheet suggests a whiteboard is fine, as long as you store the diagram in a form the team can update. For complex systems, draw one high level overview and then separate detailed diagrams per component.
Do not draw every class. Draw things that move data or hold it. If a box has no flows crossing a boundary, it can wait.
A quick example
Consider a web form that uploads a document to storage, then a worker process that reads it. Boundaries: user to web server, web server to storage, storage to worker. The worker reads data that a user controlled, so the third boundary matters even though it is entirely inside your cloud account.
Spotting missing boundaries
If your diagram has no trust boundaries, it is probably a block diagram. If every box is inside one big boundary, you are assuming everything is trusted. A good sign is when someone in the room says "wait, who controls that side?" That question is the point of the exercise. Add a line, note the answer and move on.
Quick check
Is the line between two of my own services a trust boundary?
Often yes, if one of them handles user supplied data or holds different privileges. Internal does not mean trusted.
How many boundaries is too many?
If the diagram becomes unreadable, group components and split the diagram. Keep the boundaries that matter for the feature under review.
Sources
Last reviewed: 19 October 2026.
