ZTNA reduces exposed access paths, but it does not stop an attacker or compromised user from moving laterally once inside the network. In hybrid environments, internal workload to workload traffic can expand quickly, so perimeter control alone leaves blind spots. ZTS closes that gap by limiting internal communication to only what is explicitly required.
Why ZTNA reduces exposure but does not finish the job
ZTNA is effective at shrinking the number of directly exposed access paths, but that is only one part of the problem. Once a user, device, or workload is already inside a trusted session, ZTNA does not by itself prevent lateral movement, overbroad internal access, or unsafe east-west communication in a hybrid environment. That gap matters most where internal trust is still implicit.
Hybrid networks also tend to mix cloud, on-premises, SaaS, and legacy segments, so the attack surface is not a single perimeter anymore. If internal connections are still broadly allowed, an initial foothold can become a path to additional systems even when inbound access was tightly brokered at the edge.
- ZTNA controls entry, not all post-entry movement.
- Hybrid traffic often includes service-to-service and workload-to-workload paths that ZTNA was not designed to govern end to end.
- Residual risk comes from what remains reachable after authentication succeeds.
That is why a zero trust design normally pairs access brokering with internal segmentation and explicit communication rules, such as NHI Mgmt Group's Ultimate Guide to NHIs guidance on zero trust and the Guide to SPIFFE and SPIRE for workload identity attestation and trust boundaries.
Where the residual risk comes from in hybrid environments
The main failure mode is assuming that authenticated access is equivalent to authorized movement everywhere else in the environment. In reality, ZTNA decisions are usually scoped to the access request, while hybrid networks also contain internal routes, shared services, admin planes, APIs, and application dependencies that need their own control logic.
That is especially important for workload traffic. Application components often communicate far more than human users do, and those paths can expand quietly as new integrations are added. If internal communication is not constrained, a compromised endpoint or account can use legitimate connectivity to discover systems, reach sensitive services, or pivot into better targets.
The practical implication is that ZTNA can be a strong front door control and still leave meaningful exposure behind it. The residual risk is not that ZTNA fails at its job, but that its job is narrower than the full trust problem in a hybrid estate.
For the underlying model, NIST’s Zero Trust Architecture publication is the clearest external reference point: access should be continuously evaluated and enforced as close as possible to the resource, not assumed safe after an initial check.
What practitioners should do instead of relying on ZTNA alone
Use ZTNA as the access entry point, then layer it with internal enforcement so east-west traffic is explicitly constrained. In practice, that means defining which users, services, and workloads may talk to which resources, then denying everything else by default.
What to verify: Check whether your policy model covers only remote user access or also internal application paths, service accounts, API flows, and administrative planes. If internal connectivity is still broadly trusted, the design is incomplete even if ZTNA is fully deployed.
What good looks like: A compromise of one identity or workload should not automatically unlock large parts of the environment. The expected state is narrow, purpose-bound connectivity with clear segmentation, monitored exceptions, and explicit approval for sensitive paths.
Practitioner takeaway: Treat ZTNA as an access reduction control, not a full containment strategy; in hybrid networks, the real test is whether lateral movement is still possible after the initial session is approved.
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 address the attack and risk surface, while NIST CSF 2.0, 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 CSF 2.0 | PR.AC — Access Control | ZTNA and internal segmentation both govern access paths and privilege boundaries. |
| Recommendation — Define and enforce access rules for every internal path, not only the user entry point. | ||
| NIST Zero Trust (SP 800-207) | 0 — Zero Trust Architecture | The question is directly about why ZTNA alone is insufficient in a zero trust design. |
| Recommendation — Extend policy enforcement to resource-level and east-west traffic decisions. | ||
| CIS Controls v8 | 6 — Access Control Management | Hybrid lateral movement risk is reduced by managing access paths and least privilege. |
| Recommendation — Restrict internal communications to explicitly approved access paths and remove broad trust. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Lateral Movement Prevention | Hybrid east-west movement often depends on non-human credentials and internal trust paths. |
| Recommendation — Limit workload and service access so one compromise cannot pivot across the environment. | ||
Related resources from NHI Mgmt Group
- Why do network security tools still leave organisations exposed to access risk?
- Why does SSO leave identity risk in hybrid work environments?
- Why does relying on email security alone still leave organisations exposed to phishing risk?
- Why does relying on SSO or VPN shutdown alone leave offboarding risk in place?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
