Amar Jeer

Zero Trust Without the Detour: What On-Device Enforcement Does to Latency

July 16, 2026

MIN READ

Zero Trust Without the Detour: What On-Device Enforcement Does to Latency

Short answer: ZTNA adds a hop to every protected session because enforcement lives in a cloud broker. That hop has a latency cost, small when users sit next to a point of presence, large when they don't. On-device enforcement adds no network detour, because the decision happens on the machine and traffic flies direct. If your zero trust model is making apps feel slower, the architecture is the reason.

Latency is a security problem too

Slow security gets bypassed. Users find the workaround, the personal device, the unmanaged browser, the 'just this once' exception. A zero trust model that punishes people with lag erodes its own coverage. Performance isn't a nice-to-have next to security. It's part of security.

This is easy to underrate on a whiteboard and impossible to ignore in production. Security teams measure themselves on controls deployed. Users measure the same system on how long a page takes to load. When those two experiences diverge, shadow workarounds appear, and every workaround is a gap in the control you thought you had. Fast security is adopted security.

Where ZTNA spends your milliseconds

In a broker-based model, a protected session travels device to broker to connector to app. Each leg is real network distance. When the point of presence is close, the tax is modest. When the user is in a different region from the nearest PoP, or the PoP is congested, the tax grows.

Public measurements put cloud-proxy round trips at roughly 40 to 80 ms near a PoP and 150 to 400 ms when users are far from one (ThousandEyes and vendor docs). Multiply that across a workday of requests and interactive apps, and the 'invisible' hop becomes very visible. We measured this pattern across five gateways in our real-world SWG speed and break/inspect tests.

The cost isn't just the raw round trip. Modern apps chain dozens of requests to render a single view, and TLS setup, authentication, and policy lookups can each add their own round trips through the broker. A 60 ms detour repeated across a page's worth of calls stops being 60 ms and starts being a noticeable pause. The user doesn't see milliseconds. They see 'this feels slow.'

Jitter is worse than latency

Steady latency is annoying. Variable latency is what actually breaks the experience. When traffic routes through a shared cloud element, its performance depends on that element's current load, the health of the region, and whether a reroute is in progress. Two identical requests a minute apart can take very different amounts of time.

That variability, jitter, is brutal for interactive and real-time applications: video calls, remote desktops, collaborative editors, and streaming AI responses. On-device enforcement removes the shared element from the path, which removes the biggest source of jitter. The route from the device to the destination is just the internet, not the internet plus a congestion-prone middle hop.

Where Fly Direct spends none

On-device enforcement makes the policy decision locally, against a cached policy set, then sends traffic straight to its destination. There's no mandatory trip to a broker to get an allow-or-block result, so there's no network detour to pay for. The approved headline claim is up to 4x performance over legacy proxy SWGs, and the reason is structural: you can't add latency with a hop you don't take.

The decision itself is fast because the policy already lives on the machine. There's no round trip to ask a broker 'is this allowed.' The agent checks locally and connects. Inspection, including SSL break-and-inspect, happens in line on the endpoint, which is powerful modern hardware sitting idle most of the time, rather than on a shared appliance contending with thousands of other users.

This matters most for the people ZTNA was supposed to help: distributed and remote teams far from any data center. When enforcement is on their machine, their location stops being a performance penalty. The remote and distributed workforce case makes this concrete.

The streaming and interactive-app angle

AI made this worse for broker models. Interactive token streams, long-lived connections, and large uploads are exactly the traffic where a detour hurts most. Every extra network element in the path adds jitter to a response the user is watching render in real time. On-device inspection keeps that path short, which is one reason the AI plane is the first place teams move enforcement to the endpoint. Our GenAI security guide covers that shift.

Large uploads are the other stress case. Sending a big file to an AI tool or a SaaS app through a broker means the whole payload traverses the vendor's cloud twice, in and back out. On-device inspection reads the upload locally and sends it direct, so the file takes the short path while still being governed. You get the DLP decision without the double haul.

The compounding cost at scale

One slow session is a nuisance. Thousands of them, every day, is a tax on the whole organization's productivity that never shows up as a line item. It shows up as people waiting, as calls dropping, as 'the VPN is slow again' tickets, and as quiet workarounds. Because the cost is diffuse, it rarely gets attributed to the architecture that causes it. But it's real, and it compounds with every user and every remote location you add.

Removing the detour reverses the compounding. Each new user carries their own enforcement, so performance doesn't degrade as the fleet grows, and a new office in a new region doesn't need a nearby PoP to feel fast. The architecture scales down its own latency cost instead of up.

Measure it honestly

Actual numbers depend on endpoint hardware, policy complexity, and the user's own network. We're not claiming a broker is always slow or that on-device is always instant. We're claiming something narrower and provable: a model that routes through a cloud element inherits that element's distance and load, and a model that enforces locally does not.

Test both from where your people actually work, not from a lab next to a data center. Pick your most remote office and your most travel-heavy team, run the same interactive apps through each model, and watch the tail latencies, not just the averages. The averages flatter the broker. The tails are what users feel.

Performance and cost move together

A quieter benefit hides behind the speed argument. The same architecture that removes the latency detour also removes the cost of engineering that latency away. In a broker model, the way you make distant users faster is to add more points of presence closer to them, which is capacity you rent forever and a coverage map you constantly tend. On-device enforcement fixes it structurally. Each device carries its own enforcement, so a user in a new city or country is fast the day they're onboarded, with no nearby PoP to provision. Performance stops being a coverage-map problem you solve with spend and becomes a property of the architecture. That's why the speed argument and the cost argument tend to arrive together: both come from deleting the shared middle, not from optimizing it.

Frequently asked questions

Why does ZTNA add latency? Because enforcement runs in a cloud broker or point of presence, every protected session detours through it. The farther the user is from that PoP, the more latency the detour adds.

Does on-device enforcement slow down the endpoint? The dope.endpoint agent is lightweight and inspects locally. It removes the network detour entirely, which is where the biggest gains come from. Real performance still depends on hardware and policy, so test it.

Is 'up to 4x faster' a lab number? It's the approved headline claim for performance over legacy proxy SWGs. Run your own test from your users' locations to see the effect in your environment.

What is jitter and why does it matter more than latency? Jitter is variability in latency. Interactive apps like video calls and streaming AI responses tolerate steady delay far better than unpredictable delay. Removing the shared cloud hop removes the biggest source of jitter.

Does on-device inspection handle large uploads well? Yes. The upload is inspected locally and sent direct, so it takes the short path instead of traversing a vendor cloud twice.

How should I benchmark ZTNA vs on-device? Test from your most remote and travel-heavy users, run real interactive apps, and compare tail latencies, not averages. Averages hide the detour cost that users actually experience.