ZTNA connector architectures compared across enterprise platforms

The ZTNA market hit roughly $39.58 billion in 2025, and Mordor Intelligence has it climbing to $96.75 billion by 2030. Gartner, via Zscaler, puts 70% of new remote access deployments on ZTNA instead of VPN this year, so the shift itself isn't in question. But most people evaluating these platforms stop at feature checklists and quadrant placement, which tells you about as much as judging a car by its paint job. What actually decides whether your rollout works, or turns into a six-month support ticket, is the connector: the piece of software that brokers access between a user and a private resource. Get that wrong for your environment (hybrid cloud, an OT network, a pile of unmanaged contractor laptops, a regulated data pipeline) and no amount of quadrant positioning saves you.

The three architectural splits that actually separate ZTNA platforms

Every ZTNA platform makes three choices, and each one comes with a bill attached that nobody hands you as an itemized receipt up front.

Agent-based versus agentless is the first. Agent-based puts a client on the managed endpoint, and that buys you real posture checks: patch level, EDR status, whether the right cert is present. It's also the only way to handle non-web protocols like RDP or SSH. Agentless renders access through a browser via reverse proxy, which works fine for contractors and BYOD where you can't force enrollment, but your posture visibility shrinks to whatever the browser session happens to hand over. Most vendors support both, and your device population usually makes the choice for you anyway.

Second: reverse-proxy/broker versus outbound tunnel. Reverse-proxy puts the vendor's cloud directly in the request path, publishing the app through the vendor's edge and closing inbound ports on the server. Outbound tunnel runs a small connector process inside your network that dials out to the vendor's cloud and holds a persistent encrypted tunnel open, so nothing inbound is ever exposed and no endpoint is reachable from outside. Some vendors run both sides as outbound tunnels (one from the user's device, one from an app-side connector) stitched together at a cloud broker so client and server never speak directly. What matters is whether the app server is ever exposed, even briefly, during session setup.

Third: cloud-hosted enforcement versus on-prem relay. Cloud-hosted means the policy engine lives in the vendor's point of presence, so latency becomes a function of how close that PoP sits to the user and the app; uptime is the vendor's problem, not yours. On-prem relay means you run the gateway yourself, which kills the cloud dependency but hands you back the perimeter you were trying to get rid of in the first place. Air-gapped and OT shops don't usually get to pick, since on-prem relay is the requirement there, not a preference.

Stack these three together and you get the actual deployment profile. Most enterprise SSE platforms land on agent-based, outbound tunnel, cloud-hosted. Industrial deployments tend toward agentless, reverse-proxy, on-prem relay. Neither is wrong; they're built to solve different problems entirely.

How the outbound tunnel model eliminates inbound exposure (and where it stops)

The security case is simple enough to fit on an index card: application servers carry zero inbound firewall rules, zero listening ports, no discoverable IP, so to an unauthenticated network scan, the app just isn't there.

In the broker variant, the user's agent and the app-side connector each build their own outbound tunnel to a cloud edge, and the edge stitches them into a session without either side ever learning the other's IP address. It's a one-to-one connection, not network adjacency. That's the whole trick: a session existing doesn't open a lateral path through your network.

Here's what it doesn't fix, though. If the cloud broker goes down or gets compromised, the tunnel drops, and now your uptime is somebody else's infrastructure problem to solve on their timeline. The connector VM itself is a good target too: crack it and you inherit everything on the local segment it can reach, so microsegmentation inside your network is still on you. Lateral movement doesn't disappear, it just relocates from the perimeter to the application tier. ZTNA kills the VPN's inbound exposure problem, but it doesn't replace internal segmentation, and treating one as a stand-in for the other is how quiet breaches happen.

Worth calling out on its own: a reverse-access variant built for OT and ICS, where the application itself initiates the outbound connection instead of routing through a connector agent, and the firewall stays permanent deny-all with nothing listening anywhere. TerraZone highlights that a significant share of OT intrusions exploit inbound firewall ports left open by legacy VPN. Standard outbound tunnel is architecturally sound for enterprise IT. For OT, or any tightly segmented industrial network, the reverse-access variant closes a door the standard model leaves wide open.

Zscaler Private Access: the inside-out connector at enterprise scale

Zscaler calls this "inside-out." An App Connector, a small VM, sits next to the application and only makes outbound connections; a Client Connector on the user's device does the same thing from the other end, and Zscaler's Service Edge, sitting in the cloud, brokers the session between the two.

The application never touches the network in any way a scanner could find, and users get access to one specific app, never IP-level adjacency to the subnet it lives on. Over 8,000 customers run this setup, including 40% of the Fortune 500, making it one of the most broadly adopted enterprise ZTNA platforms available.

The friction shows up in predictable spots. Traffic hairpins through Zscaler's cloud PoPs, so latency tracks PoP proximity directly, and in regions with thin PoP coverage that adds up fast. App Connector deployment needs a VM per network segment, and in a large environment with dozens or hundreds of private subnets, that's real sprawl to manage over time. Agentless access exists, but it's clearly the backup mode here, not the design center. This fits large enterprises retiring global VPN under compliance pressure, especially ones already bought into the ZIA-plus-ZPA bundle. The 2025 Gartner SSE Magic Quadrant named Zscaler a Leader.

Palo Alto Prisma Access and ZTNA 2.0: what the version number actually changes

"ZTNA 2.0" is Palo Alto's name for patching first-generation ZTNA's weak spots: access controls too blunt to tell an app from one specific function inside it, no ongoing trust check once a session starts, thin inline inspection for threats or data loss.

The connector plumbing itself isn't a huge departure. Prisma Access's ZTNA Connector runs outbound tunnels from a connector appliance or VM, the same basic shape everyone else uses. Onboarding automation is genuinely easier here, but that's an operational win, not an architectural one. The real differentiator is the unified policy model: branch offices on SD-WAN and remote users on ZTNA both run through the same Panorama policy engine. Neither Zscaler nor most competitors match that without duct-taping separate products together.

That breadth costs you elsewhere. Prisma Access carries a reputation in practitioner discussions for operational complexity to deploy and tune, and pricing is not publicly listed, so total cost of ownership requires direct engagement before a proof of concept. It landed Leader status in the 2025 Gartner SSE Magic Quadrant for the third year running, with Netskope ranking first in Completeness of Vision ahead of both Zscaler and Palo Alto on that axis. The right call for shops already standardized on Palo Alto firewalls or Panorama, where the unified policy story earns its keep in daily operations instead of just sitting in the sales deck.

Netskope Private Access: when data protection requirements drive the connector choice

Netskope's pitch isn't really about the connector mechanism at all. It's about what happens to traffic after it passes through, since one DLP engine enforces one policy across SaaS traffic, web traffic, and private app access, with no separate rule sets bolted on per channel.

The connector, called NPA Publisher, is agent-based, deployed on-prem or in a cloud VPC, and builds an outbound tunnel to Netskope's cloud: functionally close to what Zscaler runs under the hood. The difference is what's waiting at the enforcement point, since DLP inspection is the headline here, not access brokering.

That data-first bet shows up in the numbers: first in Completeness of Vision in the 2025 Gartner SSE Magic Quadrant, ahead of both Zscaler and Palo Alto on that specific axis. Some tradeoffs are real, though. Netskope's PoP footprint is more limited, so latency in sparsely covered regions is a known issue, and on-prem connector deployment gets flagged repeatedly in practitioner writeups as fiddlier than the competition. Microsegmentation isn't part of the platform at all, so if you need both DLP and internal segmentation, you're sourcing the second piece from somewhere else. Pricing isn't published, though sources such as terrazone.io cite somewhere around $10 to $18 per user per month. This is the platform for regulated industries, financial services and healthcare especially, where one DLP policy across every channel is closer to a compliance requirement than a nice-to-have.

Edge-native connector architecture: how globally distributed enforcement changes the latency equation

Hub-and-spoke ZTNA has a latency tax baked into the design. Every request routes to a cloud enforcement point and back, so that PoP becomes a choke point, and the farther the user or app sits from it, the worse the tax gets.

Edge-native flips this around. Enforcement happens at whatever network edge sits closest to the user, instead of funneling everything to one designated cloud cluster. Policy changes propagate globally in seconds instead of waiting on connector restarts or staged regional rollouts. The connector side still works the same way, an outbound tunnel from an app-side connector, but the request itself gets processed at the nearest edge node rather than shipped off to a central broker somewhere far away.

This only works if the network is actually global, not just clustered in a handful of metro regions pretending to be worldwide. A footprint of 310-plus data centers is what gives the proximity pitch substance instead of leaving it as a slide deck claim. Access modes here typically cover public hostname reverse proxy for self-hosted apps, browser-based SSH and RDP for agentless use, and client-plus-tunnel routing at L4 through L7 for everything else, so managed endpoints, unmanaged devices, and contractors all run through one platform instead of three separate ones. Pricing undercuts the category hard too: pricing that is publicly available and undercuts much of the category, which matters a lot if you're an SMB trying to decide whether ZTNA is even worth it before committing to a full VPN retirement. Cloudflare and platforms like it are frequently noted as trailing the SSE pure-plays on DLP and CASB depth, even while they compete strongly on raw ZTNA performance.

The OT and air-gapped edge case that standard connector models don't fully address

Every outbound tunnel connector assumes it can actually reach the vendor's cloud. That assumption falls apart in air-gapped networks, in OT environments with hard segmentation, and in ICS deployments where installing a new software agent kicks off a validation cycle measured in months, not days.

The OT exposure is worth repeating because it carries the whole argument on its back: a substantial share of OT intrusions exploit inbound firewall ports left over from legacy VPN, a pattern TerraZone flags as a primary driver for reverse-access architecture. Get the connector model wrong in OT and you're not filing a support ticket, you're shutting down a production line.

The reverse-access variant is built for exactly this situation: the internal application initiates the outbound connection itself, no separate connector agent needed, and the gateway stays permanent deny-all with nothing listening and nothing discoverable. Narrow architecture, narrow problem, good fit. TerraZone builds specifically around this reverse-access model for OT environments, while mainstream ZTNA platforms tend to treat OT as an afterthought if they address it at all. Any enterprise with an OT, ICS, or air-gapped segment needs to evaluate that segment's connector architecture on its own terms. What works for remote employees and SaaS access does not automatically work on the plant floor, and pretending otherwise is how you end up in a Claroty case study.

How SASE consolidation is reshaping which connector architecture wins in procurement

Procurement used to buy ZTNA as a standalone line item, with CASB, DLP, and SD-WAN sourced separately from whoever offered the best deal that quarter. That's collapsing, because SASE bundling means the connector architecture you pick today gets locked in alongside a half-dozen other services from the same vendor, which raises the cost of a bad choice considerably. You're not swapping a component anymore; you're unwinding an entire platform.

That shift rewards vendors who can make the outbound tunnel model work across every axis at once: agent and agentless, cloud-hosted and on-prem relay where it's actually needed, without forcing you into a second vendor relationship just to cover the gaps. Knowing the three axes (agent versus agentless, reverse-proxy versus tunnel, cloud-hosted versus on-prem relay) is what lets a buyer judge fit instead of leaning on a quadrant position someone else drew up. Cloudflare and others offer variants across these dimensions, and the job was never to find the single best axis in isolation. It's matching the combination against your device population, your network topology, and how much cloud dependency you're willing to live with on a bad day. Optimize for one axis alone, and you'll find out what you missed at the next OT audit, or the next regional PoP outage, whichever gets there first.