A Trust Boundary Is Not an Architecture Diagram

“The diagram has all the services and arrows, so the security review is done.”

Let me stop you there, before somebody exports it to PDF and calls the meeting productive.

A component diagram is not a threat model.

Boxes are components.

Arrows are connections.

Neither tells anybody whether the arrow carries customer data.

Or a deployment command.

Or a bearer credential.

Or an unauthenticated callback.

Or a request from one service account that can now administer three more systems.

“Service A calls Service B” is a topology statement.

Security architecture needs a different statement.

Which identity crosses which trust boundary, to do what to which asset, and what still stops it after Service A is compromised?

Those aren’t decorative annotations.

They are your review.

Microsoft’s threat-modelling sequence begins with assets, then an architecture overview containing subsystems, trust boundaries and data flow, before naming a threat.

OWASP’s DFD rule is equally plain.

A trust boundary appears where privilege or authentication level changes as data crosses.

That isn’t a request for a more attractive diagram.

It is a request for a diagram whose arrows mean something.

No one would say “we drew the building, so we completed the fire inspection.”

Yet people draw twelve cheerful microservice boxes and call the safety case implicit.

It isn’t implicit.

It is missing.

1. “But the Network Zones Are on the Diagram.”

Good.

Network zones are a network control.

They show intended reachability.

They can limit which systems initiate a connection and where packets are routed.

They don’t, by themselves, show a trust boundary in the threat-model sense.

A DFD has four element types.

External entity.

Process.

Data store.

Data flow.

A human user can be an external entity.

A service can be a process.

A database can be a data store.

The request between them is a data flow.

The dashed boundary goes where the flow enters a different privilege or authentication context.

Microsoft’s minimal example is an outside human user, a web-server process, a database store, and your boundary between user and web server.

Three shapes and one line are enough to start.

Your zone line might coincide with that boundary.

Often it doesn’t.

A workload crossing from one subnet to another with the same identity, authority and accepted trust assumptions may cross a routing boundary without creating the decisive security question.

A service in the same zone can call an administrative API using a more privileged identity, and cross your boundary that matters without ever leaving the nice blue rectangle.

Network placement is topology. A trust boundary is a change in what the receiver is prepared to trust.

Drawing a network-zone outline around some boxes does not make every request inside it equally harmless.

Paint is not policy, even when the paint is a very expensive cloud diagramming tool.

2. “But Every Arrow Has a Protocol Label.”

A protocol label is a useful fact.

It isn’t the rest of the fact.

It tells your reviewer how traffic travels.

It does not tell them who is making your request.

How that identity is authenticated.

Which resource or operation the receiver authorizes.

What data classification is carried.

A flow from orders to billing is not described by HTTPS, any more than a payroll wire is described by “uses a phone.”

Put your service identity on the arrow.

Put the entry point on the arrow.

Put your data class on the arrow.

Put the authorization decision on the arrow where it crosses a boundary.

This caller, this operation, this protected resource, under this condition.

Which is why OWASP places the trust boundary at a privilege or authentication change, not at an arbitrary protocol transition.

A transport-channel control, a presented identity credential, a queue policy and an application authorization check operate at different layers and provide different evidence.

Your DFD has to show which one actually decides whether your request proceeds.

Otherwise your review has quietly accepted this proposition:

The request used a respectable protocol, therefore the sender was entitled to do whatever the receiver did.

Nobody would accept that wording in an access-control review.

Add an arrowhead and suddenly it becomes architecture.

3. “But We Documented the Data Stores.”

Documenting your data stores is necessary.

It is still not sufficient.

A data store name tells your reviewer where something rests.

The threat model needs the asset classification, and the flows that create, read, alter or export it.

The significant boundary may sit at an administrative function.

A partner integration.

A batch job.

Your service identity allowed to query the store.

“Database” isn’t a classification.

It is furniture.

Which is why scoping comes before diagramming.

Microsoft’s sequence starts by identifying the assets worth protecting and explicitly fixing what your model excludes.

The UK NCSC distinguishes a whole-system model.

All components, users, flows, interconnections and trust boundaries, from a model of a particular component and its immediate neighbours.

Those two granularities answer different questions.

The whole-system view can see a threat at the seam between two components that each look respectable alone.

The per-component view is often the only thing a real team can keep current.

Treat either as universal and you get one grand map nobody maintains, or twelve tidy maps that stop exactly before the inconvenient boundary.

Use both where the seam carries a sensitive asset or a privilege change.

If your customer-data export path crosses a partner boundary, “your data is in the warehouse” has not modelled the part anybody needs to decide.

4. “But the Platform Team Owns the Shared Controls.”

Excellent.

Now trace the dependency, instead of counting your control twice.

James Reason’s 1990 Swiss-cheese model only gets protection from independently placed failure conditions.

Two controls failing from the same root cause, the same identity-provider compromise, the same misconfiguration class, the same logic error.

Are one slice cut twice.

A firewall and an identically configured firewall behind it don’t produce independent depth.

A network boundary plus an application-layer identity check can, because the same permitted protocol does not automatically defeat your credential decision.

Shared identity, network, policy and logging services are often good controls.

Your application review establishes what they enforce for this flow, where their enforcement point sits, and what happens if the shared dependency is compromised or unavailable.

“The platform owns it” is an ownership answer.

It isn’t an answer to whether your application still has an independent boundary.

The historical shift toward assumed compromise makes the question blunt.

Jon Measham named de-perimeterization in 2001.

The Jericho Forum formally launched in January 2004.

John Kindervag coined “zero trust” in 2010.

Google’s BeyondCorp paper documented an internal architecture in December 2014 that treated the internal network as no more inherently trusted than the public internet.

The durable idea is not a product name.

After the first control fails, what stops the next hop?

If the answer is “the shared control would not fail,” that is not defence in depth.

That is a wish with a service-level agreement.

5. “But There Are Too Many Service-to-Service Calls to Model.”

Then you have a granularity problem.

Not permission to make the flows disappear.

STRIDE.

Dated to Loren Kohnfelder and Praerit Garg in 1999.

Is useful precisely because it is a broad, developer-facing pass over every relevant DFD element and boundary.

Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

It does not demand an attack novel for every arrow.

It asks the same set of questions until the meaningful paths have been covered.

For a high-value threat, build an attack tree rather than pretending every entry deserves identical treatment.

Bruce Schneier’s December 1999 formulation puts the attacker goal at the root, uses OR nodes for alternatives, and AND nodes for preconditions that must all hold.

A mitigation breaking one AND-linked condition defeats that path.

That gives the arrow consequences.

A compromised service account reaches the payment API only if your identity is accepted, the authorization permits the operation, and your boundary permits the route.

There are other dials.

PASTA has seven stages, and brings business impact in before technical decomposition.

DREAD rates Damage potential, Reproducibility, Exploitability, Affected users and Discoverability as High (3), Medium (2) or Low (1), producing a 5-to-15 composite.

Microsoft’s simpler alternative is Probability × Damage Potential, each on a 1-to-10 scale.

Those are ways to choose what gets depth.

They are not a licence to inspect only the three arrows that fit on a slide.

6. “But Assumed Compromise Makes Every Design Look Unsafe.”

No.

It makes unsupported assumptions visible.

Assumed compromise does not say every service is compromised now, every time, forever.

It says a design should not have to prove the first boundary stayed perfect before it can explain the next one.

The useful question is specific.

If this service account, workload, network segment or policy dependency fails, which assets and operations are reachable next?

That answer becomes a blast-radius requirement.

The service account receives only the operations it needs.

The next resource performs its own authorization decision.

Segmentation restricts the reachable peers.

An independent layer addresses a different failure condition.

Monitoring and a tested mitigation tell your operator what is supposed to happen when the path behaves differently.

This is not merely an argument about perimeter history.

It is the distinction between an architecture saying “internal services are trusted,” and one that can state the authority of each service-to-service call.

The former is a comforting label.

The latter is a control model.

The alternative, a component diagram whose every internal arrow silently means “probably allowed”, is not less alarming.

It merely has better spacing.

7. No, This Does Not Mean Every Box Needs a Bespoke Security Design.

It doesn’t.

The point is not to assign a separate ceremony to every container, library or background worker.

It is to draw and review your boundaries carrying sensitive assets, privilege changes, externally reachable entry points and consequential shared dependencies.

Fine-grained segmentation has a real operating cost.

A December 2019 survey of more than 300 IT professionals found 19% of respondents had implemented a segmentation solution, deployment-and-tuning time averaged one to three months, and more than two-thirds found firewall-rule testing difficult.

Dated figures.

Not a current adoption claim.

Their durable point is that retrofit work is gated by flow discovery and testing, not by buying a firewall.

Past the maintainable point, policies grow roughly with communicating workload pairs rather than simply with workloads.

An unauditable rule set creates outages and gaps.

It does not become rigorous because it contains more lines.

The right boundary is one you can discover, define, test, monitor and keep current.

The OT case is an even less forgiving reminder.

Purdue separates Levels 0-1 physical processes and field devices, Level 2 control systems, Level 3 manufacturing operations, Level 4 business systems.

IEC 62443’s zones and conduits define logical asset groupings and explicitly controlled paths.

Yet Dragos’s 2026 OT year-in-review found 56% of assessed organizations could not see below the IT/OT boundary, while a 2025 SANS ICS/OT survey reported only 12.6% with full visibility across the ICS Cyber Kill Chain.

A boundary nobody can verify is very difficult to distinguish from a boundary nobody has.

More boxes do not fix that.

Verifiable flows do.

8. What You Should Actually Do.

Start with a scoped DFD, not the existing component inventory. Name the assets worth protecting and the explicit exclusions.

Mark every external entity, process, data store and data flow.

Annotate each material flow with data classification, entry point, calling identity, receiving resource, operation, and the authentication and authorization decision that applies.

Draw a trust boundary wherever privilege or authentication changes. For each cross-boundary flow, state what the service account may do, where that authority is enforced, and which condition stops it after the sending workload is compromised.

Record shared controls and dependencies separately from independent layers, a repeated dependency is not a second mitigation.

Run STRIDE against the relevant elements and boundaries. Use an attack tree for the higher-value surviving threats.

Rank and triage with a chosen method, then attach a countermeasure, an owner, a tracked work item, a status and a test to each material threat.

A threat model producing an attractive file and no requirement has achieved document retention.

Nothing else.

Make the update trigger explicit. A new flow, a changed service identity, a new privilege, a different entry point or a changed shared dependency updates the DFD and its threats.

Before the system claims the old review still applies.

Your model is part of your architecture’s change control.

Not the ceremonial first page of it.

9. The Actual Model Is Not Complicated.

A component diagram answers: what talks to what?

A threat-model DFD answers: what crosses your boundary, under which identity and authority, with which assets at stake?

Security architecture adds the final question: after one thing is compromised, what prevents the next thing from being compromised too?

A visual topology does not reveal the security significance of a flow until identity, authority and failure assumptions are attached.

Diagram tooling and service counts will change.

That distinction will not.

Draw the boxes.

Keep the arrows.

Then make every material arrow answerable.