ZTNA connector architectures compared across enterprise platforms

A VPN gateway listens. It sits on the network edge, announces itself to the internet, and waits for someone, anyone, to knock. A ZTNA connector does the opposite: it reaches out from inside the network to a cloud broker, and nothing on the public internet ever learns the internal infrastructure exists. That single inversion, inbound versus outbound, is the decision buried under every enterprise ZTNA purchase, and it produces most buyers never evaluating it directly.

Why connector architecture is the real ZTNA decision

Enterprise security teams spend months comparing ZTNA platforms on feature checklists, pricing tiers, and where each vendor lands on an analyst's quadrant chart. None of that tells a team whether its applications stay invisible to the public internet, whether its firewall can stay closed, or how far its BYOD policy can reach.

The VPN model puts a gateway on the edge of the network and tells it to listen for inbound connections. That gateway is an address, and an address is a target: scanners and exploit kits treat every listening port as an invitation. The ZTNA model flips the direction of initiation. A small connector sits inside the network and reaches outbound to a cloud broker, so there is no listening port for anything to find. Internal infrastructure simply does not appear on the public web.

That difference is a structural property baked into the platform at deployment, and it cannot be retrofitted once the rollout is underway. The connector model a team picks on day one ends up shaping every access policy it writes afterward, every firewall rule it maintains, and every decision it makes about letting contractors or personal devices onto the network. Platforms like Cloudflare Zero Trust, whose connector (cloudflared) initiates outbound-only connections with no inbound firewall exposure, embed that decision into every access policy and firewall rule downstream, making the initial architectural choice as durable as it is consequential. The platform decision is a multi-year commitment whether or not anyone frames it that way at purchase time.

The three connector models that underlie every enterprise ZTNA platform

Underneath the branding, every enterprise ZTNA platform runs on one of three connector models, and the model it picks determines what the platform can and cannot do, as a matter of architecture rather than configuration.

Service-initiated broker routing places a connector next to the application, and that connector opens an outbound connection to the ZTNA broker. Users never talk to the application directly. They talk to the broker, and the broker routes their traffic through the tunnel the connector already opened, so the application side needs no inbound firewall ports at all. A stricter version of this model pushes the idea to its limit: the application-side component initiates every connection outbound, the broker never pushes anything back in, and the firewall sits in a permanent deny-all state, no listening services, no discoverable IP address, nothing for an outsider to find. Because every packet passes through a central broker, this model is the one platforms reach for when they want a secure web gateway, a cloud access security broker, or threat prevention sitting inline, inspecting traffic as it moves.

The lightweight reverse-proxy tunnel model trims the appliance out of the picture. A single small process, not a virtual machine, not a dedicated box, runs on the application's own infrastructure and opens an outbound-only connection to an edge network. The edge then proxies authenticated requests to that process, and the application itself is never directly reachable. Because the connector is just a process, it runs as a Linux daemon, a Docker container, or a Kubernetes sidecar, and deployment friction drops close to zero. The lightweight reverse-proxy tunnel model suits distributed deployment for exactly this reason: a process can run anywhere a daemon or container can run, without provisioning a dedicated appliance for every application. That same design lets a platform evaluate policy at the edge, on every single request rather than once at login, so pulling someone's access takes effect immediately rather than waiting for a session to expire.

Peer-to-peer mesh throws out the central gateway. Every device becomes a node, and a coordination server hands out encryption keys and enforces access control lists, but the actual data traffic runs directly between peers through encrypted tunnels that never pass through a central point. That design kills the hub-and-spoke latency problem that traditional VPNs carry, and it works well for developer teams and small organizations where every endpoint is under management. The tradeoff is structural: because traffic never transits a broker, there is no single point in the path where a secure web gateway, a CASB, a DLP engine, or threat prevention can sit and inspect anything.

Two deployment modes cross all three models rather than belonging to any one of them. Client-initiated access puts an agent on the endpoint and supports protocols beyond the browser, RDP, SSH, SMB, the stuff of internal infrastructure. Service-initiated, or clientless, access runs through a browser with no agent to install, which is the mode that makes BYOD and contractor access workable for web applications.

Six criteria that expose what a connector architecture delivers

A feature like "protocol coverage" or "PoP density" means nothing on a spec sheet until a team knows which connector model it's attached to. If you ask them in order, six questions turn the abstract architecture into something you can actually act on.

Does the connector require any inbound port at all, or does the firewall stay closed in both directions? The answer sorts platforms into their underlying model faster than any other single question, because it's the one property a vendor can't fudge with a marketing slide.

Does the team need more than a browser? Web-only access covers HTTP and HTTPS, but plenty of enterprise environments still run RDP, SSH, SMB, or custom TCP/UDP ports for internal tools, and a platform that only supports clientless browser access simply cannot reach those protocols. A team whose engineers need RDP into internal servers can cross clientless-only platforms off the list before looking at anything else.

What does the connector cost to run, not in license fees but in operational weight? A VM-based appliance needs provisioning, patching, and monitoring, instance by instance, while a process-level binary adds almost none of that overhead. The gap between the two appears in how many people a team needs on staff just to keep connectors alive.

Can a SWG, a CASB, a DLP engine, or a threat-prevention system actually sit in the traffic path? That depends entirely on the model. Peer-to-peer mesh makes inline inspection structurally impossible, not missing, not disabled, impossible, because traffic never passes through anything central enough to inspect it.

Does the platform work with whatever identity provider you already run, or does it demand a move to a specific vendor's identity stack? And once a user is authenticated, is ZTNA policy evaluated on the same engine as the rest of the organization's access controls, or does it live on a separate plane that someone has to keep in sync by hand?

Can an unmanaged device, a contractor's laptop, a vendor's personal phone, get in through a browser with no agent installed? That capability depends on a specific architectural choice, and not every connector model can deliver it without putting an agent on the device first.

Finally, how many points of presence does the provider actually run, and where are they? ZTNA routes every request through cloud relay nodes, so if you work outside the home office, the number and placement of those nodes sets the floor on your latency. That question only makes sense for broker-routed architectures, because peer-to-peer mesh has no relay network to measure.

Comparing the four major platforms by connector architecture

If you run the same six questions against four platforms, the differences stop looking like marketing and start looking like physics.

Cloudflare Zero Trust uses the cloudflared tunnel, an outbound-only connector with nothing listening for inbound traffic. The firewall stays in deny-all, the application has no externally reachable endpoint, and there's no IP address for anything to discover. Browser-based access covers web applications with no client install required, and non-HTTP protocols, SSH, RDP, private network access, run through the WARP client, client-side cloudflared, or, for SSH and RDP specifically, a browser-rendered terminal that also needs no install. The agentless advantage is strongest for web apps; organizations sitting on a large catalog of legacy TCP/UDP applications should weigh that before assuming clientless covers everything. The connector itself is a single binary, no appliance to provision, deployable straight into Kubernetes as a sidecar, which cuts both cost and operational load compared to VM-based connectors, especially in environments with many small application segments. Because traffic transits Cloudflare's edge, the full policy engine, WAF, DLP, Gateway filtering, device posture checks, runs on every request rather than only at login, and pulling someone's access takes effect immediately rather than waiting for a session to time out. The platform works with any SAML or OIDC identity provider, and it can combine identity signals with device posture, location, and network context in one policy. It runs on Cloudflare's global network of 300+ data centers, which keeps latency low regardless of where a user sits. Cloudflare was named the only Visionary in both the 2026 Gartner Magic Quadrant for SASE Platforms and the 2026 Gartner Magic Quadrant for SSE.

Palo Alto Prisma Access runs the Prisma Access Agent, successor to GlobalProtect, on top of service-initiated broker routing. ZTNA Connectors deploy per data center and per cloud environment, AWS VPC, Azure VNet, GCP project, and a large deployment typically needs several App Connectors per data center just for high availability. No inbound ports are required, since the connectors initiate every connection outbound. Where Prisma Access pulls ahead is inline inspection depth: the same App-ID, User-ID, and WildFire threat prevention signatures that run on physical appliances in a data center apply equally to a remote worker's traffic, the strongest inline inspection depth in this comparison. That depth comes with a tradeoff in operational weight, custom enterprise pricing and the highest configuration overhead for on-premises scenarios in this comparison. The platform fits organizations already standardized on Palo Alto tooling, where a single unified policy across physical and cloud infrastructure is worth the added connector complexity.

Microsoft Entra Private Access brokers connections through Private Network connectors deployed inside the customer's own network, which establish outbound connections to Microsoft's Security Service Edge, while the Global Secure Access client on user devices routes traffic for configured private DNS names and IP ranges. No inbound ports are needed here either. What sets this platform apart is the policy plane: every web request and every private-application connection runs through the same Conditional Access engine built into Microsoft Entra ID that already governs Microsoft 365 and Azure, so there's no separate policy plane for the secure web gateway and no separate plane for ZTNA. For an organization already running on Microsoft identity, that consolidation is the platform's strongest selling point. The identity provider, though, is Entra ID and only Entra ID, so any organization not already anchored to Microsoft's identity fabric has to decide whether taking on a new IdP dependency is worth it. Managed devices need the Global Secure Access client installed, but browser-based access for unmanaged or BYOD devices is only in preview. The platform fits organizations already deep in the Microsoft identity and compliance stack, where skipping a net-new vendor outweighs the identity constraint.

Tailscale takes a different shape entirely, a WireGuard-based peer-to-peer mesh where a coordination server distributes keys and ACL policy, enforcement happens locally at each node, and the actual data traffic runs peer-to-peer without a central gateway in the middle. That design removes the hub-and-spoke latency penalty of a traditional VPN and works well for developer teams and small organizations where every endpoint is managed. The same design that makes Tailscale fast also makes it structurally unable to run inline inspection: no CASB, no SWG, no DLP, no threat inspection anywhere in the path, because the architecture has no central point to put it. A lightweight agent runs on every device, with agentless access available through subnet routers for devices that can't take the agent, and through Tailscale PAM's agentless connector model, which was in beta as of August 2026. Identity providers include Apple, Google, GitHub, Microsoft, Okta, OneLogin, and OIDC. The platform fits small developer teams or internal tooling environments where mesh connectivity is the actual goal and inline inspection isn't a requirement; it is not a fit for enterprises carrying compliance obligations that demand DLP or threat prevention sitting in the traffic path.

How connector architecture determines DDoS exposure and misconfiguration risk

Connector architecture decides more than how traffic moves from one point to another. It decides what an attacker can even see, and where a single policy mistake turns into an outage rather than a minor ticket.

Applications sitting behind a true reverse-proxy or an outbound-only tunnel have no externally reachable endpoint. There's no IP address to scan, no port to probe, and the firewall's permanent deny-all state means an attacker has nothing to flood in the first place. That's a different claim than saying the risk is managed or reduced. The DDoS surface is eliminated at the structural level, not mitigated after the fact by rate limiting or scrubbing traffic once it arrives. Protocol coverage and PoP density only matter once that structural question is settled, since a network with hundreds of points of presence enforcing Zero Trust policy close to the user only helps if the connector itself is outbound-initiated and brokerless to begin with, removing the hub-and-spoke bottleneck that would otherwise cap how far that network advantage reaches.

The same architectural logic applies to misconfiguration, just on the policy side instead of the network side. If a platform evaluates access on every single request, the way edge-based policy engines do, it can catch a bad permission change the moment the next request comes in. A platform that checks policy only at session establishment lets a misconfigured rule ride along silently until that session happens to end, which could be hours, which could be a workday. Neither failure mode is theoretical: they're both direct, mechanical consequences of where in the traffic path a given connector model evaluates policy, and that's precisely the kind of detail a feature checklist never surfaces, because feature checklists ask what a platform does, not where in the architecture it does it.