Security teams should use ZTNA to control who can reach the environment and ZTS to control what can move inside it. ZTNA reduces broad perimeter exposure through identity based access, while ZTS limits lateral movement after entry. Together they create layered containment for north-south and east-west traffic, which is the practical shape of Zero Trust in hybrid environments.
Why ZTNA and ZTS belong together, not as alternatives
ZTNA and ZTS solve different halves of the same trust problem. ZTNA is the front door control, it decides whether a user, device, or workload can reach a protected service at all. ZTS is the interior control, it reduces what that already admitted session can reach, which keeps a valid connection from becoming broad internal access. For zero trust programmes, the design goal is layered containment, not a single control that claims to do everything.
This distinction matters in hybrid environments because traffic patterns are mixed. Some paths are clearly north-south, while others become east-west after the first hop lands inside the environment. If teams treat ZTNA as sufficient on its own, they often preserve too much implicit internal trust. If they treat ZTS as a substitute for entry control, they leave the first compromise too easy to obtain.
- Use ZTNA where the question is “Should this session be allowed in?”
- Use ZTS where the question is “Once in, what else can this session reach?”
- Design both controls so a legitimate path still has a tight blast radius.
That logic aligns with NIST SP 800-207 Zero Trust Architecture, which frames access as continuously evaluated and tightly bounded rather than implicitly trusted after initial admission.
Where identity-bearing access is part of the programme, the interior control matters just as much as the entry gate. Ultimate Guide to NHIs is useful here because it connects Zero Trust with privilege scope, lifecycle control, and lateral-movement resistance for service accounts, API keys, and other machine-access paths. For workload-level enforcement patterns, Guide to SPIFFE and SPIRE shows how workload identity and attestation can support tighter internal trust boundaries.
How to divide responsibilities between the edge and the interior
The cleanest operating model is to assign one control to admission and the other to containment. ZTNA should enforce strong authentication context, device or posture checks where appropriate, and application-specific access decisions. ZTS should enforce policy after admission, ideally at the service, workload, or segment level, so a compromised session cannot roam freely. The programme works best when policy intent is consistent across both layers, but the enforcement points are not duplicated blindly.
Teams usually get into trouble when they allow one product to blur into the other. A remote access tool marketed as Zero Trust may be excellent at replacing VPN exposure yet still leave east-west movement largely unconstrained. Conversely, a segmentation tool may reduce lateral movement while still assuming that any authenticated entrant is broadly trustworthy. The right question is not which acronym is stronger, but which trust boundary each layer actually enforces.
- Define the entry policy in terms of user, device, workload, and application context.
- Define the internal policy in terms of allowable destinations, session scope, and segmentation boundaries.
- Keep administrative exceptions rare, time-bound, and auditable.
For teams standardising the model, the Ultimate Guide to NHIs, Standards section is a practical bridge because it connects Zero Trust with the identity and control standards that often shape implementation choices.
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 Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture — Zero Trust Architecture | Defines continuous verification and constrained access boundaries for this ZTNA plus ZTS model. |
| Recommendation — Map admission and segmentation policies to continuous verification and least-privilege enforcement. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Least Privilege and Access Scope | ZTS is about limiting post-entry reach, which directly depends on scoped identity privilege. |
| NHI-03 — Secrets Rotation and Expiry | Tight containment only holds if the credentials behind ZTNA and ZTS are short-lived and revocable. | |
| Recommendation — Scope every service and machine identity to the minimum internal destinations it truly needs. Rotate access material aggressively so compromised sessions cannot retain durable reach. | ||
| CIS Controls v8 | 6 — Access Control Management | Separating entry control from internal containment is an access-control design decision. |
| 8 — Audit Log Management | ZTNA and ZTS decisions need logging to confirm who entered and what paths they used. | |
| Recommendation — Enforce distinct controls for initial access and internal reach to reduce blast radius. Log access and segmentation decisions so policy gaps and lateral movement are detectable. | ||
Practitioner Guidance
What to verify: Confirm that ZTNA and ZTS are enforcing different policy decisions, not two versions of the same coarse rule. If both products are effectively allowing the same broad post-authentication reach, the programme is still vulnerable to lateral movement even if the front door looks strong.
What changes at scale: The larger the environment, the more important it is to scope internal policy by application path, workload trust, and segment rather than by human assumptions about “internal” versus “safe.” At scale, the failure mode is usually not missing a single control, but overbroad policy that quietly accumulates exceptions.
Common mistake: Treating ZTNA as a VPN replacement and stopping there. That improves perimeter exposure, but it does not automatically stop an already admitted session, service account, or workload from being over-extended inside the environment.
Practitioner takeaway: The programme is strongest when ZTNA limits admission and ZTS limits movement after admission, because Zero Trust is about shrinking trust at every hop, not merely hardening the first one.
Related resources from NHI Mgmt Group
- How should security teams combine RBAC and ABAC in a Zero Trust programme?
- How can security teams tell whether their identity programme is ready for zero trust?
- How should security teams implement integrated PAM in a zero trust programme?
- How should security teams govern vendor access in a zero trust programme?
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
