The Connector Problem: How ZTNA Recreated the Backhaul It Was Meant to Kill

Short answer: ZTNA retired the VPN concentrator and replaced it with a broker and a set of connectors. Traffic still routes through the vendor's cloud to reach an app, which means ZTNA quietly re-created the backhaul detour it was supposed to end. Fly Direct removes the middle entirely: enforcement runs on the device and traffic goes straight to its destination. This is the architecture piece most ZTNA buyers only notice after deployment.

The promise vs. the plumbing

The ZTNA pitch is clean: no more VPN, no more flat network, just identity-aware access to the exact apps a user needs. The plumbing underneath is less clean. A typical deployment has three moving parts: a client on the device, a broker or service edge in the vendor's cloud, and connectors deployed next to your apps.

To reach an app, the user's traffic goes device to broker to connector to app. The trust decision improved. The path got longer. That's the tension at the heart of the model: it fixed how access is granted without fixing how traffic flows.

Most buyers don't feel this on day one. They feel it three months in, when a user in another region complains that an internal tool is slow, or when a connector fails over and a team loses access for twenty minutes. The architecture was doing exactly what it was designed to do. The design just put a dependency in the path.

Where the detour hides

VPN backhaul was obvious: everything went to a concentrator in your data center. ZTNA backhaul is subtler because it's someone else's cloud, but the shape is the same. Every session rides through the vendor's point of presence. When that PoP is far from the user, latency climbs. Cloud-proxy round trips run roughly 40 to 80 ms near a PoP and 150 to 400 ms when users are far from one. When the PoP degrades, sessions degrade with it.

We wrote about the same pattern in the DNS and cloud-proxy world in why on-device beats DNS-only and cloud proxy alternatives. The lesson transfers directly to ZTNA: any model that puts a shared cloud element in the traffic path inherits that cloud's latency and availability.

There's a second, quieter detour too. Even when the app and the user are in the same city, traffic can route out to a distant PoP and back because that's where the broker lives. The physical distance between user and app stops mattering; what matters is the distance to the vendor's nearest inspection point. For a distributed workforce, that's a lottery you run on every session.

Anatomy of a ZTNA session

Walk a single request through the model and the cost becomes concrete.

A user opens an internal app. The client intercepts the request and sends it to the broker in the vendor's cloud. The broker authenticates the user, checks device posture, and consults policy. It then hands the session to a connector sitting next to the app, which finally opens the connection to the app itself. The response retraces the path.

Every one of those legs is real network distance and a real dependency. The broker has to be up. The connector has to be up. The path between them has to be healthy. You've turned 'user reaches app' into a small distributed system with several components that all have to cooperate for a click to work.

Now compare the on-device path: the agent intercepts the request, checks it against a locally cached policy, and opens the connection directly. One component, one decision, no intermediate legs. The difference isn't philosophical. It's a count of the things that have to go right.

The connectors themselves are a cost

Connectors don't run themselves. They need to be deployed, kept highly available, patched, and monitored. Each app or environment you protect adds connectors to maintain. That's operational weight that scales with your footprint, and it's weight your team carries forever, not just at rollout.

Redundancy multiplies it. Because a single connector failure can cut access to whatever sits behind it, teams run connectors in pairs or clusters. Now every protected environment is at least two components to patch, monitor, and upgrade in lockstep. Multiply across a real estate of apps and the connector fleet becomes a meaningful part of the infrastructure team's week.

Single-vendor SASE platforms bundle this differently but don't erase it. We compared that trade-off in Cato Networks alternatives for single-vendor SASE. The bundle can simplify procurement. It doesn't remove the fact that the enforcement plane lives off your devices and has to be operated.

What removing the middle looks like

Fly Direct has no broker in the path and no connectors to maintain for the web, SaaS, and AI plane. The dope.endpoint agent enforces policy locally against a cached policy set, then traffic flies direct to its destination. Inspection happens at the operating system's networking layer, on the machine.

The result is fewer parts and a shorter path. There's no PoP to be far from, no connector fleet to keep alive, and no shared cloud element that every session depends on. Policy still pushes centrally from dope.console, fleet-wide, in under a minute. The control plane stays in the cloud. The data plane stays on the device.

That split is the whole trick. Keep the thing that benefits from being central, policy authoring and telemetry, in the cloud. Move the thing that suffers from being central, the traffic path, onto the endpoint. You get centralized management without centralized backhaul.

Reliability is an architecture property

Operational cost and reliability are two readings of the same fact: every component in the path can fail and has to be owned. A broker, a PoP, and a set of connectors are three categories of failure between a user and their app. Reduce the components and you reduce the failure modes by construction, not by heroics.

On-device enforcement with a cached policy set has a useful property here. If the control plane is briefly unreachable, the device keeps enforcing against its last known policy, because the decision already lives on the machine. A broker outage tends to mean no decision at all. Fewer dependencies in the path is not just faster and cheaper. It fails more gracefully.

The honest scope

ZTNA's connector model exists to reach private apps sitting behind your own network. That's a real job, and if that's your primary need, connectors earn their place. The point here is narrower and fair: for the traffic most users generate all day, the web, SaaS, and increasingly AI tools, routing through a broker and connectors adds a detour with no security benefit that on-device enforcement doesn't already provide.

That's the plane to move first. You don't have to touch private-app access to get the win. You just stop sending the internet through a middle box. Teams that did exactly this off legacy cloud proxies describe the deployment experience in the Greylock Partners story, and the scale version is in the Fortune 100 deployment.

Frequently asked questions

Does ZTNA really backhaul traffic? Most ZTNA routes sessions through a broker or point of presence in the vendor's cloud before reaching the app. That's a detour by design. The latency and availability of that path depend on the vendor's cloud.

What replaces the connector in an on-device model? For the web, SaaS, and AI plane, nothing. The device enforces policy locally and connects direct. There's no connector fleet to deploy or maintain for that traffic.

Does on-device mean no cloud at all? No. The control plane stays in the cloud for policy and telemetry. The data plane, the actual inspection and enforcement, runs on the device.

Why do connectors need high availability? Because a connector sits in the path to whatever app it fronts, a single failure can cut access. Teams run redundant connectors to avoid that, which adds components to operate.

Can I keep ZTNA for private apps and go on-device for everything else? Yes, and that's the common path. Move the internet, SaaS, and AI traffic on-device first, and keep ZTNA scoped to the private-app access that genuinely needs a broker.

What happens during a broker or PoP outage? In a broker model, an outage can mean no access decision and no connection. On-device enforcement keeps working against cached policy if the control plane is briefly unreachable.

Cut the middle out

See what removing the broker and the connectors does to latency and operational load. Book a 20-minute demo or start an instant trial.

Further reading: real-world SWG speed and break/inspect tests and the dope.SWG product overview.