The Hidden Operational Cost of ZTNA (and the On-Device Alternative)

Short answer: ZTNA's real cost isn't the license. It's the ongoing operational load of connectors, brokers, high-availability pairs, and the integration work to keep them running. That work scales with your footprint and never ends. On-device Fly Direct removes the connector fleet for the web, SaaS, and AI plane and deploys as a single agent, so a lean team can run it. The cheapest architecture is the one with the fewest moving parts to babysit.

The line item you see vs. the cost you feel

Every zero trust platform has a per-user price. That's the line item you see. The cost you feel is different: the hours your team spends deploying connectors, standing up high-availability pairs, wiring identity integrations, and troubleshooting when a broker or PoP has a bad day.

For a large team with dedicated infrastructure staff, that's absorbable. For the lean IT and security teams running most mid-market companies, it's the whole story. The tool that looks cheaper on the quote can be the expensive one once you count the salaried hours it consumes every week.

Total cost of ownership is the honest metric, and it has three parts: the license, the deployment, and the run. ZTNA vendors compete hard on the first. The second and third are where the real money goes, and they're the parts a demo never shows you.

What ZTNA asks you to operate

A broker-based ZTNA deployment typically means running and maintaining connectors next to each protected environment, usually in redundant pairs so a single failure doesn't cut access. Add identity provider integration, device posture configuration, and per-app policy. Each new environment you protect adds more connectors to the fleet. The operational surface grows with your estate.

Break the lifecycle into phases and the load is easier to see.

At deployment, you're standing up connectors in every environment, configuring the identity integration, defining posture rules, and building the initial policy set per app. That's project work, and it's front-loaded.

At steady state, you're patching and upgrading connectors, monitoring their health, keeping HA pairs in sync, and responding when one falls over. You're also re-testing after every vendor-side change to the broker or agent.

At change time, every new app, acquisition, or environment restarts a slice of the deployment phase. The estate never stops growing, so the work never stops.

None of this is exotic. It's just work, and it's permanent. It's the same weight that made legacy proxy and DNS rollouts painful, which we documented in why on-device beats DNS-only and cloud proxy alternatives.

What on-device removes

Fly Direct deploys as a single lightweight agent, the dope.endpoint, pushed through your MDM. For the web, SaaS, and AI plane there are no connectors to deploy, no HA pairs to maintain, and no PoP dependency to monitor. User import and SSO are one-click. Policy pushes from one console, fleet-wide, in under a minute.

Compare the same three phases. Deployment is pushing an agent through tooling you already run, with one-click SSO and user import. Steady state is keeping an agent updated, which your MDM already does for every other piece of software on the fleet. Change time is editing policy in one console, not standing up new infrastructure. The operational surface stops scaling with your app estate, because there's no per-app connector to add.

The proof is in deployment speed

The clearest evidence that an architecture is light to operate is how fast real teams get it live. Heavy architectures can't deploy fast, because the connectors and integrations gate the timeline.

A Fortune 100 scaled from 900 to over 18,000 devices in weeks, roughly 3,000 per week, deployed silently via Intune, as told in the 18,000-device deployment story. Greylock Partners went from first proposal to signed contract in 27 days, detailed in the Greylock story. Another Cisco Umbrella customer migrated 2,000 machines in two days. None of those timelines are possible when the architecture requires a connector fleet standing behind each protected environment.

Speed at rollout predicts cost at steady state. The same properties that let you deploy in days, one agent, central policy, no connectors, are the properties that let a small team keep running it without a dedicated pod.

Fewer parts, fewer failure modes

Operational cost and reliability are the same conversation. Every component in the path is a thing that can break and a thing someone has to own. A broker, a PoP, and a set of connectors are three categories of failure between your user and their app. On-device enforcement with a cached policy set keeps working even when the control plane is briefly unreachable, because the decision already lives on the machine.

Fewer parts is not just cheaper. It's more resilient. Every component you remove is an on-call page you'll never get, a patch cycle you'll never run, and a post-incident review you'll never write. Simplicity compounds in your favor the same way complexity compounds against you.

Who this matters most for

The operational argument lands hardest for lean teams, because they feel every hour. A two-person IT function can't run a connector fleet across a dozen environments and still do everything else. For them, the architecture that needs the least babysitting isn't a preference. It's the only one that's actually operable.

It also matters for fast-growing companies. If you're adding offices, apps, and headcount, an architecture whose operational load scales with your footprint quietly taxes your growth. One that scales by pushing an agent to each new device does not.

The honest scope

If you need to broker access to private apps behind your own network, connectors do a job, and for that job the operational cost is the price of the capability. The argument here is about total cost of ownership for the traffic that dominates a workday. For the web, SaaS, and AI plane, the connector-and-broker model is operational overhead you can retire by moving enforcement to the device.

Healthcare and public-sector teams with small staffs made exactly this move, as in the Outreach Health and City of Visalia stories. Neither has a large infrastructure team. Both run modern security anyway, because the architecture doesn't demand one.

A quick TCO gut check

Want a fast read on an architecture's true cost before you build a spreadsheet? Ask four questions and count the answers you don't like:

• How many components sit between a user and the internet, and who patches each one?
• What happens to access when one of those components fails, and how often does that happen?
• How much of a new-site or new-app rollout is infrastructure work versus a policy edit?
• If your headcount doubled next year, would the security operational load double with it?

On-device enforcement answers those with 'one agent,' 'it keeps working on cached policy,' 'a policy edit,' and 'no.' A connector-and-broker model answers each one the expensive way. The gut check isn't a formal model, but it points at the same conclusion the detailed math does, and it takes five minutes instead of a quarter.

Frequently asked questions

What makes ZTNA expensive to operate? The ongoing maintenance of connectors, high-availability pairs, and broker or PoP dependencies, plus the integration work to keep them healthy. That load scales as you protect more environments.

How many components does Fly Direct add? One: a lightweight agent on the device, managed from a single console. For the web, SaaS, and AI plane there are no connectors to maintain.

Can a small IT team run this? Yes. That's the point. One-click SSO and user import, MDM deployment, and fleet-wide policy in under a minute are built for lean teams. See the customer stories for real timelines.

How does deployment speed relate to operating cost? The properties that make deployment fast, one agent, central policy, no connectors, are the same ones that keep steady-state operation light. Fast rollout predicts low run cost.

Does removing components hurt reliability? The opposite. Fewer components mean fewer failure modes. On-device enforcement also keeps working against cached policy if the control plane is briefly unreachable.

Do I still need connectors for private apps? If you broker access to private apps behind your network, that use case still needs its infrastructure. Moving the web, SaaS, and AI plane on-device removes connectors for that traffic, which is most of it.

Cut the operational load

See how few parts on-device zero trust actually needs. Book a 20-minute demo or start an instant trial with your corporate email.

Further reading: Cato Networks alternatives for single-vendor SASE and the dope.SWG product overview.