ZTNA is only one access control layer. On its own, it does not tell teams what they are protecting or stop movement between internal workloads after access is granted. Zero Trust requires segmentation because policy must be enforced near the resource, application, or data itself. Without that proximity, attackers can still spread and reach high-value assets.
Why ZTNA Is Necessary but Not Sufficient
ZTNA answers a narrow question: whether a user, device, or session should be allowed to initiate access to a specific application or service. That is valuable, but it does not replace the broader zero trust requirement to continuously constrain access, verify assumptions, and reduce blast radius once an actor is already inside the environment. A program built on ZTNA alone still leaves gaps in internal trust boundaries and east-west traffic control.
Zero Trust is not just an entry decision. It is an operating model for how trust is granted, limited, and rechecked across the environment. That is why policy must extend beyond the access edge and into the resource path itself, especially where internal workloads, service-to-service calls, and data access are involved. NIST SP 800-207 Zero Trust Architecture frames this as continuous verification and least privilege, not a single front door check.
Practically, the difference shows up when an attacker or overprivileged internal user has already passed an initial gate. If the environment lacks segmentation, the same session can often move laterally, probe adjacent services, and reach higher-value assets without triggering a new enforcement point. ZTNA can reduce exposure at the perimeter, but it does not by itself define or enforce the internal boundaries needed to contain spread.
What Segmentation Adds That ZTNA Cannot
Segmentation is the control that makes Zero Trust real inside the environment. It forces access decisions closer to the resource, application, workload, or data, so policy is enforced where the risk actually lives. That proximity matters because trust should be tied to the specific asset and transaction, not assumed across an entire subnet, cluster, or internal network zone.
This is especially important for east-west traffic, where machine-to-machine communication often becomes the path of least resistance after an initial compromise. Workloads may authenticate successfully and still be allowed to talk too broadly to databases, queues, admin services, or shared platforms. Guide to SPIFFE and SPIRE is useful here because it shows how workload identity, attestation, and service-to-service trust can support resource-level enforcement rather than broad network trust.
Segmentation also helps separate policy intent from network convenience. ZTNA may tell you that access is legitimate at login time, but segmentation determines whether that access should reach a specific workload, port, or dataset. Without that second layer, Zero Trust becomes mostly a remote-access story instead of an enterprise-wide access model.
How Incomplete Zero Trust Fails in Real Environments
The most common failure mode is assuming that successful initial authentication or device posture checks are enough to contain a compromise. They are not. Once a session is established, weak internal policy can allow an attacker to reuse trusted paths, harvest additional credentials, or exploit loosely separated services that were never meant to be reachable from the original access point.
Another common gap is incomplete mapping of application dependencies. Teams may protect the user-to-app path while leaving service-to-service, administrative, or data-plane paths under-enforced. That creates a false sense of coverage because the external access story looks strong while the internal attack surface remains wide open. Ultimate Guide to NHIs, Standards is relevant because it connects Zero Trust with the controls that govern workload identity, IAM, and security controls around internal access paths.
For practitioners, the real test is whether a compromised session can move laterally, not whether it can get in. If the answer is yes, the program is incomplete even if ZTNA is deployed correctly. A mature Zero Trust program limits trust at the edge and inside the environment, so compromise of one access path does not become compromise of the whole estate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Zero Trust completeness depends on enforcing policy near the protected resource and limiting internal movement. |
| Recommendation — Enforce information flow controls so east-west access is constrained at the resource boundary. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question is specifically about why ZTNA alone does not satisfy the broader Zero Trust model. |
| Recommendation — Design policy for continuous verification, least privilege, and resource-centric enforcement. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is incomplete internal access control after initial entry, which CIS addresses through access governance. |
| Recommendation — Restrict internal access paths so one permitted session cannot reach unnecessary systems. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Workload and service paths can remain overprivileged even when front-door access is controlled. |
| NHI-08 — Environment Isolation | Segmentation and isolation are the missing layers when ZTNA does not stop east-west spread. | |
| Recommendation — Reduce internal privilege so workloads can only reach the resources they actually need. Isolate environments so compromise of one zone does not enable broad lateral movement. | ||
Practitioner Guidance
What to verify: Confirm that every high-value application, workload, and data store has an explicit enforcement point, not just a ZTNA entry control. If your only policy boundary is the login or broker layer, internal blast radius is still too large.
What to prioritise: Start with the paths that let one trusted workload or user reach many others, especially shared services, admin interfaces, and sensitive data stores. Those are usually the shortest routes from initial access to material impact.
Common mistake: Treating “we have ZTNA” as equivalent to “we have Zero Trust.” The former controls access initiation; the latter also controls internal movement, privilege scope, and resource proximity.
Practitioner takeaway: The program is complete only when trust decisions follow the access path all the way to the resource, because that is what prevents one permitted session from becoming an enterprise-wide foothold.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
