About
Subscribe

Direct-routed vs cloud-routed ZTNA: Why the data path matters to business leaders

The two models apply zero trust controls differently because they take fundamentally different approaches to carrying approved traffic.
Johannesburg, 30 Sep 2026

Zero trust network access replaces broad network access with identity-driven, least-privilege connectivity. Once access is approved, however, traffic still needs a path to the protected resource. Direct-routed ZTNA sends that traffic through enterprise-selected routes, while cloud-routed ZTNA sends it through a provider-operated cloud broker before it reaches the destination.

Both models can enforce zero trust policy effectively. The distinction is operational: where traffic travels, who controls the path, and which components become dependencies for every session. Those differences affect performance, resilience, governance, scalability, operating effort and cost.

Direct-routed vs cloud-routed ZTNA.
Direct-routed vs cloud-routed ZTNA.

The direct-routed approach

In a direct-routed design, the platform evaluates identity, device posture and contextual policy, then allows approved traffic to travel between the requester and the resource through a path controlled by the enterprise. The provider supports the access decision, but its cloud does not have to carry every session. 

This model can minimise unnecessary network distance, preserve local or private connectivity and give the organisation greater control over routing and capacity. It is particularly useful where users, applications and workloads are spread across data centres, branches, cloud environments and isolated networks. The trade-off is operational responsibility: the enterprise must design, monitor and maintain resilient paths across those environments.

Direct routing can also strengthen data-path governance. Sensitive traffic can remain on approved enterprise networks, and security teams have clearer control over geography, segmentation and third-party transit. This can simplify data-residency assessments and audit evidence, although the organisation remains accountable for operating those controls consistently.

The model is often a strong fit for latency-sensitive applications, high-volume services, operational technology and machine-to-machine connections. It can also reduce the need to force local or private traffic through an external intermediary solely to apply access policy.

The cloud-routed approach

In a cloud-routed design, approved traffic passes through a provider-operated cloud broker. The provider supplies the routing infrastructure, points of presence and service capacity, creating a consistent access layer for users and applications across multiple locations.

This can speed deployment, simplify global service delivery and reduce the infrastructure that internal teams operate. It can be attractive for distributed workforces and standardised application access. The trade-off is that the broker becomes part of every session: performance, availability and route efficiency depend on the provider’s network footprint, capacity and service health.

Cloud routing therefore exchanges some enterprise control for a more provider-managed operating model. That exchange can be valuable when simplicity and rapid scale matter most, but it may introduce extra network distance, third-party transit and a greater reliance on the provider’s commercial model and roadmap.

Direct-routed and cloud-routed: Business comparison

  • Traffic path: Direct routing uses enterprise-selected routes to the resource. Cloud routing inserts the provider’s broker into the session path.
  • Performance: Direct routing can provide shorter, more predictable paths for nearby or demanding resources. Cloud routing offers a consistent service, but extra hops or backhauling can increase latency.
  • Resilience: Direct routing avoids making one external broker the universal data-path dependency, but the enterprise must engineer resilient connectivity. Cloud routing shifts more of that responsibility to the provider, while exposing sessions to provider outages or congestion.
  • Environment fit: Direct routing is well suited to hybrid estates, private resources, operational technology and machine-to-machine traffic. Cloud routing is well suited to distributed users and standardised application publishing.
  • Governance: Direct routing provides greater control over traffic location and third-party transit. Cloud routing centralises delivery, but provider locations, multi-tenancy and data-path visibility require careful review.
  • Operations and cost: Direct routing may require more internal networking skill and infrastructure but gives the enterprise greater control over capacity and avoids mandatory broker transit. Cloud routing can reduce operational overhead, although service tiers, throughput charges and provider dependency may grow with usage.
  • Strategic control: Direct routing keeps more architectural control within the organisation. Cloud routing places more responsibility with the provider in exchange for simpler deployment and service management.

Business limitations of cloud-routed ZTNA

  • Productivity risk: Additional hops and cloud backhauling can affect response times for latency-sensitive, real-time or high-throughput applications.
  • Operational continuity exposure: If the broker experiences congestion, routing issues or outage, access to otherwise healthy enterprise systems may be affected.
  • Coverage constraints: Web-first access models may not naturally fit all legacy, custom, OT/IOT, server-initiated or bidirectional traffic patterns.
  • Governance complexity: When traffic traverses multi-tenant third-party infrastructure, data-path control, residency, assurance and audit evidence require additional scrutiny.
  • Tool sprawl: Use cases outside the broker’s core coverage can leave VPNs, proxies or specialist gateways in place, fragmenting policy and support.
  • Cost uncertainty: Throughput, capacity and retained exception tools can make the long-term economics harder to forecast as usage scales.
  • Secure server-initiated connection constraints: Business processes that rely on callbacks, automated data exchange, monitoring, replication, industrial control workflows or application-to-application communication can be difficult to support when a cloud-routed Layer 7 ZTNA platform is optimised for user-initiated web sessions. This may require architectural workarounds, policy exceptions or parallel connectivity methods, delaying projects, increasing integration complexity, reducing operational visibility and leaving critical machine-to-machine services outside the standard zero trust access model.

Why the choice matters

Direct-routed ZTNA is generally the stronger fit when path control, low latency, private connectivity and support for diverse environments are priorities. Cloud-routed ZTNA is generally the stronger fit when rapid deployment, global consistency and reduced internal infrastructure management matter more.

The right choice should be tested against application location, user geography, traffic volume, failure scenarios, regulatory requirements, operating capability and total cost. Some organisations may adopt both models deliberately: direct routing for sensitive, high-performance or operationally complex workloads, and cloud routing where provider-managed simplicity offers greater value.

Share

Private Protocol

As a next-generation IT security distributor, Private Protocol delivers specialised solutions and strategies across Africa. We empower our channel partners with a comprehensive portfolio, enabling them to provide customers with industry leading solutions that covers – Ai security, risk visibility, brand protection, data security, infrastructure security, and identity security - alongside offensive security and awareness training.

Website - www.privateprotocol.com

Editorial contacts