Amar Jeer

Beyond ZTNA: Why Zero Trust Belongs on the Device

July 16, 2026

MIN READ

Beyond ZTNA: Why Zero Trust Belongs on the Device

Short answer: ZTNA was a real step forward. It replaced the flat, trusted network with identity-aware access to individual apps. But it kept one assumption from the old world: that enforcement has to happen in a box somewhere in the middle, now a cloud broker instead of a VPN concentrator. Fly Direct takes the next step. It moves zero trust enforcement onto the device itself, so policy runs where the user is and traffic goes straight to its destination. Same principle, better place to enforce it.

What ZTNA got right

Give ZTNA credit. It killed the idea that being on the network means being trusted. It tied access to identity and device posture, scoped it per app, and made the old VPN model look as dated as it was. For connecting a remote user to a specific private application, that was the right correction, and it moved the whole industry forward.

The philosophy is sound: never trust, always verify. Assume the network is hostile. Grant the least access needed, and only after checking who's asking. None of that is in question. The question worth asking in 2026 isn't whether zero trust is right. It's where you enforce it.

That distinction matters because 'zero trust' and 'ZTNA' get used interchangeably, and they shouldn't. Zero trust is a principle. ZTNA is one product category that implements a slice of it, specifically remote access to private apps, using a particular architecture. You can keep the principle and change the architecture. That's the entire argument of this piece.

The assumption ZTNA kept

Most ZTNA is delivered as a cloud service. The user's request goes to a broker or a point of presence, gets checked against identity and policy, and then reaches the app through a connector. Trust moved from the network to identity, which is good. But the enforcement point stayed in the middle of the path.

That middle box has consequences. It adds a hop. It depends on the broker being reachable and healthy. And it means your traffic transits infrastructure you don't own to get a yes-or-no decision. You solved the trust problem and re-introduced the detour problem.

Look at the lineage and the pattern is obvious. The VPN concentrator was a box in the middle. The cloud proxy was a box in the middle. ZTNA's broker is a box in the middle. Each generation moved the box and improved the trust model, but none of them questioned whether the box needed to be in the traffic path at all. That's the assumption worth retiring.

A short history of moving the control point

The history of network security is a steady march of the control point moving closer to the user.

First it lived at the perimeter. A firewall at the edge of the corporate network decided what came in and out, and everything inside was trusted. That worked while the users and the apps were inside the building.

Then the perimeter dissolved. Apps moved to SaaS, users moved home, and the firewall found itself guarding a building most of the work had already left. The cloud proxy answered by moving inspection to the vendor's cloud, so a roaming user could be protected without coming back to headquarters. Better reach, but now every request detoured to a data center.

ZTNA answered the trust half of the problem: stop trusting the network, verify identity per app. But it inherited the cloud proxy's shape, a service in the middle that traffic routes through.

The device is the end of that line. It's the one place that's always with the user, always sees the request first, and sees the full context: the user, the process that made the request, the destination, and the content. Moving enforcement there isn't a detour from the zero trust journey. It's the destination the journey was heading toward all along.

Where Fly Direct puts enforcement

dope.security runs zero trust on the endpoint. The dope.endpoint agent inspects traffic and enforces policy on the device, using a locally cached copy of policy, then sends traffic direct to its destination. No mandatory trip to a broker just to get an allow-or-block result. We call it Fly Direct.

The trust model is the same as ZTNA's: verify identity, check the device, apply policy per destination. What changes is the location. Enforcement happens at the operating system's networking layer, on the machine, before anything leaves. That's a more natural home for zero trust than a shared cloud choke point, and it's measurably faster because there's no detour. See our real-world SWG speed and break/inspect tests for what removing the hop does in practice.

The control plane still lives in the cloud. Policy is authored centrally in dope.console and pushed to the fleet in under a minute. What doesn't live in the cloud is the data plane. The actual decryption, inspection, and enforcement happen on the endpoint, which is why traffic doesn't need to detour anywhere to be governed.

What 'on the device' actually means

On-device enforcement is not a browser extension and not an agent that simply tunnels traffic to a cloud service. It runs at the operating system's networking layer, which is why it can see and act on traffic from any application, not just a browser tab.

That has three practical effects. First, coverage: it sees browser sessions and native clients alike, from a desktop AI app to an IDE assistant to a script hitting an API, when the traffic is decryptable and the app is supported. Second, context: because it sits at the OS boundary, it can read the originating process directly rather than inferring the application from network patterns. Third, timing: it evaluates and can block a request before it leaves the machine, rather than reporting on it after it already reached the destination.

A broker sees a tunnel. The endpoint sees the whole picture. That's the difference that makes on-device the sharper place to enforce zero trust, not just the faster one.

Why 'on the device' is the logical next step

Put the two threads together and the conclusion is hard to avoid. The control point has been moving toward the user for two decades, and the device sees more than any point upstream of it can. On-device enforcement is both the end of the architectural trend and the richest vantage point for a zero trust decision.

That's also why the on-device model handles things a broker never can: which application made the request, whether the login is a corporate tenant or a personal one, and what's actually inside the request. Those are exactly the questions modern risk turns on, and they're invisible to a component that only sees an authenticated tunnel.

Objections, answered

'On-device can't be zero trust, the device is the thing you don't trust.' Fair concern, wrong conclusion. Zero trust means don't trust the network or implicit position, and verify continuously. On-device enforcement still verifies identity and device posture; it just also uses signals a broker can't. The agent is tamper-resistant and centrally managed, and policy comes from the cloud control plane. You're not trusting the device. You're using it as the enforcement point while still verifying everything.

'A cloud broker scales better.' Scaling a shared inspection plane means adding capacity to a component every session depends on. On-device enforcement scales with the fleet automatically, because each device carries its own enforcement. There's no central data plane to size, congest, or reroute.

'We're mid-migration to ZTNA. Is this a rip-and-replace?' No. This is an evolution, not a demolition, and the two coexist. Keep ZTNA where you genuinely need to broker access to private apps. Move the web, SaaS, and AI plane on-device, because that's where the volume and the data risk now sit. Our complete guide to AI governance covers that plane in depth, and the Cato Networks vs Zscaler comparison shows how the cloud-service model plays out at the platform level.

This is an evolution, not a demolition

ZTNA solved a specific job well, and plenty of teams still run it for private application access. The point isn't that zero trust was wrong. It's that the enforcement point is moving, the same way it moved away from the perimeter a decade ago. On-device is where it's heading. For most teams, the web, SaaS, and AI plane is the first place to make that move, because that's where the data and the risk now live.

Frequently asked questions

Is Fly Direct the same as ZTNA? They share the zero trust principle: verify identity and device, apply policy per destination. They differ on where enforcement runs. ZTNA typically enforces in a cloud broker; Fly Direct enforces on the device and sends traffic direct.

Does on-device enforcement still verify identity and device posture? Yes. Zero trust checks still apply. The difference is that the decision and the traffic don't detour through a third-party broker to happen.

Is this a rip-and-replace of ZTNA? No. It's a shift in where you enforce. Many teams start with the web, SaaS, and AI plane on-device and keep other controls in place while they migrate.

Does zero trust require a cloud service? The principle doesn't. It requires verification and least privilege. Those can be enforced on the device with a cloud control plane for policy and telemetry, which is what Fly Direct does.

What traffic should I move on-device first? The web, SaaS, and AI plane. That's where most user traffic and most data-loss risk live, and it's the traffic that gains the most from removing the broker hop.

Is on-device slower for the endpoint? The agent is lightweight and inspects locally. Removing the network detour is where the biggest performance gains come from. Actual numbers depend on hardware and policy, so test from where your users work.