Amar Jeer

From ZTNA to Fly Direct: A 2026 Architecture Decision Guide

July 16, 2026

MIN READ

From ZTNA to Fly Direct: A 2026 Architecture Decision Guide

Short answer: You don't have to pick a side on faith. Zero trust is the goal; where you enforce it is the decision. ZTNA still fits for brokering access to private apps behind your network. On-device Fly Direct fits for the web, SaaS, and AI plane, which is where most user traffic and most data risk now live. For most teams, the smart move in 2026 is to move that plane on-device first and keep ZTNA only where private-app access genuinely requires it. Here's the framework.

Start by separating the two jobs

Zero trust covers two very different traffic types, and conflating them is why the architecture debate gets muddy:

Private app access. Connecting a user to an internal application behind your network or cloud. This is ZTNA's home turf.
The web, SaaS, and AI plane. Everything users touch on the open internet all day, including the AI tools driving today's data-loss risk. This is where on-device enforcement wins.

Decide per traffic type, not per vendor. Most of the volume, and most of the exposure, is in the second bucket. Once you separate the two, the 'ZTNA vs on-device' argument stops being a war and becomes a routing question: which enforcement point is right for which traffic.

A quick decision checklist

Ask these about each control you run:

Where does the traffic actually go? If it's public SaaS or AI, a broker adds a detour with no benefit. Enforce on the device. If it's a private app behind your network, a broker or connector still has a role.
Do you need to see content, not just grant access? If yes, you need on-device inspection. Access control alone can't read prompts or uploads. See ZTNA controls access, it doesn't stop the leak.
How distributed is your workforce? The more remote and global your users, the more a broker's PoP dependency costs you, and the more on-device pays off. See security for remote and distributed teams.
How lean is your team? Fewer moving parts favors on-device. Connectors and HA pairs are ongoing work. See the operational cost of ZTNA.
Do you have data-residency or privacy constraints? On-device keeps decrypted traffic local. See zero trust shouldn't route everything through a third party.

If most of your answers point at public destinations, distributed users, a lean team, and residency constraints, the web, SaaS, and AI plane belongs on the device. That's the common case.

Map your traffic before you map your tools

Before touching architecture, get an honest inventory of where your users' traffic actually goes. Most teams are surprised: the overwhelming majority is public web, SaaS, and AI, and only a thin slice is private-app access behind the network. That ratio is the whole decision. If 90% of the traffic is headed for the open internet, routing 90% of it through a private-access broker is paying a tax on the wrong plane.

Discovery is step zero for a reason. You can't right-size ZTNA or scope an on-device rollout until you know the split. Turn on visibility first, look at the real destinations, then decide. Start with AI visibility.

A sane migration order

You don't rip anything out on day one. A low-risk sequence:

Deploy the on-device agent through your MDM and turn on discovery. See what AI and SaaS your users actually touch.
Move the web, SaaS, and AI plane on-device. Enforce SWG policy, Cloud Application Control, and Dopamine DLP at the endpoint. This is where the risk and the volume are. Use Monitor mode first, tune against real traffic, then switch to Block.
Right-size ZTNA. Keep it only for the private-app access that genuinely needs a broker. Many teams find that scope is smaller than they assumed.
Review the connector fleet. Every connector you no longer need is operational load you retire.

Teams have run steps 1 and 2 fast: a Fortune 100 reached 18,000+ devices in weeks, and Greylock Partners signed in 27 days. The sequence is deliberately reversible: you're adding an enforcement point and shifting traffic to it, not tearing out what you have before the replacement is proven.

What to measure during the pilot

A good pilot proves the case with numbers, not vibes. Track four things:

Performance. Compare tail latency, not averages, for real interactive apps, run from your most remote and travel-heavy users. That's where the broker detour shows up and where on-device gains are largest.

Coverage. Confirm the on-device agent sees AI and SaaS the broker never did: personal accounts, desktop AI clients, IDE assistants, and scripts. Discovery output is the evidence.

Data protection. In Monitor mode, count how many sensitive prompts and uploads the endpoint catches that the access layer let through. That gap is the risk you were carrying.

Operational load. Note how long deployment took and how many components you had to stand up. Compare it honestly to what a connector-based rollout would have required.

When ZTNA is still the right call

To be fair and useful: if your primary need is remote access to internal apps, and you have no appetite to change that, ZTNA does that job. On-device enforcement and private-app brokering can coexist, and this guide is not an argument to rip out working private-access infrastructure.

The mistake is using a private-access broker as your web, SaaS, and AI control, or paying the broker's latency and operational tax for traffic that never needed to go through it. Keep ZTNA where the destination is genuinely a private app behind your network. Move everything else to where the user is.

The honest scope

This is an evolution, not a religious war. Zero trust is right. The enforcement point is moving to the device for the plane that matters most, the same way it moved off the perimeter years ago. Move deliberately, measure from where your users actually work, and keep what still earns its place. The teams that do this well don't announce a 'ZTNA replacement.' They quietly shift the internet, SaaS, and AI plane on-device, watch the metrics improve, and let the private-app footprint shrink to its real size.

Common mistakes to avoid

Three traps show up repeatedly. First, buying one architecture for both traffic types because a vendor bundles them, instead of routing each plane to the enforcement point that fits it. Second, skipping discovery and guessing the private-app-versus-internet split, which almost always overstates how much really needs a broker. Third, treating the move as all-or-nothing and stalling, when the low-risk path is to add on-device enforcement for the internet plane, prove it in Monitor mode, and right-size ZTNA afterward.

Avoid those three and the decision gets much simpler: match the enforcement point to where the traffic actually goes, and let the metrics from a real pilot settle the rest.

Frequently asked questions

Do I have to replace ZTNA to adopt Fly Direct? No. Start by moving the web, SaaS, and AI plane on-device and keep ZTNA for private-app access. Reduce the ZTNA footprint over time to what genuinely needs a broker.

What should move on-device first? The web, SaaS, and AI plane, because that's where most user traffic and most data-loss risk live. Discovery, Cloud Application Control, and DLP all run at the endpoint.

How do I compare options fairly? Test from your users' real locations, separate private-app access from open-internet traffic, and weigh latency, operational load, content inspection, and data residency. Our best shadow AI governance tools guide is a starting point for the SaaS and AI side.

How long does a migration take? The on-device piece can move fast because it's an agent push and central policy. Real teams have reached thousands to tens of thousands of devices in days to weeks. Right-sizing ZTNA afterward is a slower, deliberate cleanup.

What should a pilot measure? Tail latency from remote users, coverage of AI and SaaS the broker missed, sensitive prompts and uploads caught in Monitor mode, and the operational load of deployment. Numbers, not impressions.

Is there any traffic that should stay on ZTNA? Yes: genuine remote access to private apps behind your network. Keep the broker scoped to that, and move the open-internet plane on-device.