How should security teams evaluate direct-routed ZTNA for Zero Trust access?

Why This Matters for Security Teams

Direct-routed ZTNA is often discussed as a network optimisation, but the security question is whether it actually reduces trust exposure. A design can look “zero trust” on paper while still allowing broad session reach, weak segmentation, or unmanaged broker paths. That matters because the access layer becomes part of the attack surface, not just a delivery mechanism. NIST’s NIST SP 800-207 Zero Trust Architecture is useful here because it frames zero trust around continuous verification and explicit access decisions, not just a different tunnel.

Security teams frequently miss that ZTNA should be assessed at both the identity layer and the path layer. If users are strongly authenticated but can still pivot across internal services once connected, the control is incomplete. That same risk appears with non-human identities too: service accounts, API clients, and automation jobs can inherit overbroad reach if routing and entitlement are not aligned. The practical test is whether the architecture reduces blast radius, not whether it replaces a VPN brand with a new one. In practice, many teams discover residual lateral movement only after an audit or incident exposes the hidden reach of “private” access.

How It Works in Practice

Evaluating direct-routed ZTNA starts with tracing what happens after authentication. A sound design should bind identity, device state, policy, and application context to each request, then enforce access at the narrowest viable point. Direct routing can improve performance and reduce dependency on central relays, but it only strengthens security if the policy engine still limits which applications, ports, and session actions are allowed.

Practitioners should test the design in three layers:

• Identity assurance: verify who or what is connecting, including human users and NHIs that may automate access.
• Session reach: confirm the authenticated entity can reach only the intended application or microservice, not an internal subnet.
• Traffic inspection and logging: ensure the control plane records decisions, denials, and anomalous paths for investigation.

That operational view aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access control, auditing, and system monitoring need to be demonstrable. Teams should also validate that the implementation does not create unmanaged identity sprawl; direct routing often increases the number of service endpoints, certificates, and tokens that must be governed. The OWASP Non-Human Identity Top 10 is relevant when automation or workload access participates in the same trust path.

Testing should include failure injection: revoked credentials, device posture failure, policy misfires, and attempted access to adjacent services. These checks show whether enforcement is truly per-application or merely front-ending a broader network route. These controls tend to break down when legacy applications still depend on shared back-end segments because the access broker cannot cleanly separate application reach from network reach.

Common Variations and Edge Cases

Tighter direct-routing controls often increase policy complexity and troubleshooting effort, requiring organisations to balance reduced blast radius against operational overhead. Best practice is evolving on how much central mediation is acceptable, because there is no universal standard for when a relay becomes a security weakness versus a useful inspection point. Some environments benefit from direct routing for latency and resilience, while others need an intermediate broker for logging, content controls, or protocol normalization.

The most important edge case is hybrid access. If some applications are direct-routed and others still traverse shared gateways, policy drift can create inconsistent user experience and uneven enforcement. Another common issue is privileged or machine-driven access: automation may bypass the same controls applied to interactive users unless the organisation intentionally governs certificates, tokens, and service identities. That is where NHI governance becomes relevant, because machine access can quietly become the weakest part of a “zero trust” design.

For regulated environments, the evaluation should also ask whether the design supports evidence collection, access review, and incident reconstruction. If the architecture cannot show who accessed what, from where, and under which policy decision, then the control may be operationally useful but weak as a governance mechanism. The right conclusion is not always to reject direct-routed ZTNA, but to confirm that its routing model is paired with enforceable identity policy and auditability rather than assumed to provide them.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust for privileged access?
• How should security teams replace VPN trust with zero trust access controls?
• How should security teams implement zero trust access management across hybrid environments?
• How should security teams implement contextual access policies in zero trust environments?