Why isn't cloud ZTNA enough for zero trust?

Cloud ZTNA decides which users and devices may connect to which applications, which is one slice of zero trust. NIST's definition goes wider: no implicit trust based on network location, with authentication and authorization performed before each session. A gateway alone says nothing about workloads, data, or what happens after access is granted.

What does ZTNA actually cover?

Zero trust network access replaces a broad VPN with per application access. A user signs in, the service checks identity and device posture, and a session opens to one application rather than a whole network. That addresses the old habit of treating anything inside the network as trusted.

NIST SP 800-207 describes zero trust as moving defenses "from static, network-based perimeters to focus on users, assets, and resources". Note the word resources. The document says authentication and authorization of both subject and device are discrete functions performed before a session to an enterprise resource is established. ZTNA is one common way to implement that for remote access. It is not the whole architecture.

What is left uncovered?

CISA's Zero Trust Maturity Model organizes the work into five pillars (identity, devices, networks, applications and workloads, data) and three cross-cutting capabilities (visibility and analytics, automation and orchestration, governance). Use it as a gap list. A ZTNA service mostly touches identity, devices and networks. That leaves:

• Applications and workloads. Service to service traffic, build pipelines and code that runs without a human user are outside a user facing gateway.
• Data. Classification, access rules and logging on the data itself.
• Visibility and analytics (cross-cutting). Whether anyone looks at the signals, and acts on them.
• Automation and orchestration (cross-cutting). Whether policy changes happen by process or by hand.
• Governance (cross-cutting). Who owns the policy and how exceptions expire.

CISA's page also describes the goal as making "access control enforcement as granular as possible" and says zero trust may require a change in "philosophy and culture". A tool purchase does not deliver that by itself.

What goes wrong after the session opens?

A constructed example: a contractor's laptop passes the device check and gets access to an internal admin tool through ZTNA. The tool holds a long lived API key that opens a storage bucket full of customer exports. The gateway did its job. The application did not enforce least privilege on what the signed in session could reach, and nothing flagged an unusual bulk download. Each missing piece belongs to a different pillar.

Does the cloud part matter?

Hosting the gateway in a cloud service removes appliances and helps remote users, but it adds a dependency. You still need to know where your applications live, which of them sit behind the gateway, and which are reachable some other way. An application reachable directly from the internet beside a ZTNA front door is a common leftover.

How to check or apply this

1. List every internet reachable application and mark which ones sit behind your ZTNA service.
2. Map your current tools to the CISA pillars and cross-cutting capabilities and write "none" where nothing exists.
3. Check that service accounts and automated jobs have scoped, short lived credentials, not shared keys.
4. Confirm data stores enforce their own access rules and log reads.
5. Decide who reviews the access logs, how often, and what triggers action.
6. Set an expiry date on every policy exception.

Safeguard works on the software side of this picture: asset discovery, policies and gates in pull requests and pipelines, and agent identity for automated actors. It does not replace an access gateway.

Quick check

Sources

• NIST SP 800-207, Zero Trust Architecture
• CISA Zero Trust Maturity Model

Last reviewed: 18 October 2026.