Zero Trust Beyond the Network Diagram

A zero trust program that ends with a new network diagram has moved the perimeter. It has not removed it.

The diagram is the easy part. Segments get drawn, a ZTNA gateway replaces the VPN, and the architecture slide looks different. But zero trust, as NIST defines it, is not a topology. It is a way of deciding access. No request is trusted because of where it comes from, and every resource is protected by a decision made when the request arrives. Those decisions live in identity, device, application and data layers. The diagram does not show them, and that is where programs stall.

What the standard actually asks for

NIST SP 800-207 puts trust in neither network location nor asset ownership. It shifts protection toward the resources themselves and the users and devices that request them. A company laptop on the office network earns no more trust than a personal device on the internet. User and device are verified as separate steps before a session to a resource is allowed.

The reference architecture has three logical parts. A policy engine decides. A policy administrator sets up or tears down the session. A policy enforcement point sits in the path and carries out the decision. The first two together form the policy decision point. The useful question for any important resource is simple: where are these three, who owns them, and what signals do they use?

NIST’s National Cybersecurity Center of Excellence shows how varied the answers can be. Its practice guide, SP 1800-35, describes 19 example implementations built with 24 collaborators across on-premises and multicloud environments. That spread is itself the message. Zero trust is assembled from parts, not bought as one.

Where it breaks: the seams

Each layer can be sound and the architecture can still fail where layers meet. Six seams deserve attention.

Seam	What usually goes wrong	Question to ask
Identity and device	The decision uses identity plus a device label that is stale, self-reported or checked only at login.	Is device health an input to each session decision, and how old can that signal be?
Identity and application	Single sign-on proves who the user is. The application then applies its own roles, which no one reviews.	Is what a user can do inside the application governed as carefully as the login?
Network and cloud control plane	Workload access is tightly controlled while cloud management APIs and IAM sit outside the model.	Who can change policy, create roles or open a path, and from where?
Workload to workload	User traffic is inspected. Service-to-service calls run on shared secrets and flat trust.	Do services and pipelines authenticate with identities that policy can see and revoke?
Administrative planes	Hypervisor, identity provider, EDR and backup consoles are reachable from ordinary networks.	Are they treated as the highest tier, with separate access paths?
Application and data	Policy stops at the application. Data leaves in bulk through a legitimate session.	What limits query and export volume after access is granted?

The Snowflake customer data thefts show the last seam clearly. Mandiant found that the intrusions traced back to stolen customer credentials, accounts with no MFA, and instances with no network allow-list. About 165 organizations were notified of potential exposure, and Mandiant found no evidence that Snowflake’s own environment had been breached. Strong verification of the user, restriction by location, and alerting on bulk export are all zero trust decisions. Here they were optional, and they were off. An optional control is not a decision point.

The decision point is also a target

Concentrating decisions in an identity provider and a policy engine improves consistency. It also creates one place where an attacker gains everything. CISA and the FBI describe actors who added their own federated identity provider to a victim’s SSO tenant so that logins kept working whatever happened to the victim’s passwords. Mandiant reports attackers harvesting long-lived OAuth tokens and session cookies, which carry authentication that was already completed.

Two design consequences follow. Protect the identity provider and policy administration plane as top-tier assets. And keep sessions short, or re-evaluate them on signal change, so a stolen token has limited value. Per-session access only helps if the session is actually re-evaluated.

Firewalls, segmentation and ZTNA gateways remain useful as enforcement points. What changes is that their rule sets stop being where trust is decided.

Decide how it fails

Every policy engine will fail at some point. If nobody has decided what happens then, the decision gets made during an outage by whoever is on call. Choose in advance, per resource. A payment system should fail closed. A low-risk internal site can fail open with enhanced logging. Write the choice down and test it, because the failure mode you assume and the one you have are often different.

A sequence that works

Start with resources, not technology. List the dozen or so assets whose compromise would hurt most, plus the administrative planes that control them.
Draw the decision map. For each resource, record who decides, which signals feed the decision, where it is enforced, how long a session lasts and what happens when a signal changes. This map replaces the network diagram as the main design artifact.
Fix the identity plane first. Phishing-resistant MFA for privileged users, hardened account recovery paths, and tight control over who can administer the identity provider.
Bring service identities and admin planes into scope. They are where programs most often stop.
Measure by pillar. CISA’s Zero Trust Maturity Model covers identity, devices, networks, applications and workloads, and data, with visibility and analytics, automation and orchestration, and governance running across them, at four stages from traditional to optimal. Use it as a shared vocabulary. Its examples are written for federal agencies and will not map one-to-one onto every enterprise.
Test the failures. Simulate a stolen session, a stolen administrator credential and a policy engine outage. Record what actually happens to access.

Metrics worth reporting

“Percentage of applications behind ZTNA” measures deployment. These measure decisions:

Share of high-value resources where every session is evaluated on identity, device and context.
Number of standing administrative entitlements on the highest-tier systems.
Time from a risk signal changing to access changing.
Policy exceptions, each with an owner and an expiry.

A zero trust architecture is judged by what happens when one assumption fails. If a stolen session, a compromised device or an over-privileged service identity does not change the access decision, the design still trusts something it should not.

NEXT STEP