--- title: "Self-Hosted ZTNA: The Category Few Vendors Offer | OpenVPN Blog" description: Almost every ZTNA platform requires the vendor's cloud as your control plane. Here's what self-hosted ZTNA actually means, and the three buckets every vendor falls into. image: https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_5_V1.png --- - [Blog](https://blog.openvpn.net) - [Zero Trust](https://blog.openvpn.net/tag/zero-trust) - [self-hosted](https://blog.openvpn.net/tag/self-hosted) - [ztna](https://blog.openvpn.net/tag/ztna) # Self-Hosted ZTNA: The Zero Trust Category Almost No Vendor Offers Oct 6, 2026 • 16 min read ![self-hosted server labeled ztna](https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_5_V1.png) Share - - - - Self-Hosted ZTNA: The Category Few Vendors Offer | OpenVPN Blog 19:31 By Heather Walters ## What does self-hosted ZTNA actually mean? Ask most security teams to list ZTNA vendors and you'll get a familiar set of names. Ask them which of those vendors will let you run the whole thing on your own infrastructure, and the list gets very short very quickly. Not because self-hosted Zero Trust is technically hard. Because the market consolidated around a delivery model — cloud-delivered, vendor-operated — early enough that "ZTNA" and "SaaS" became close to synonymous in the analyst categories, the buying guides, and the ad budgets. If your [requirements rule out a vendor cloud](https://openvpn.net/use-cases/zero-trust-network-access/), the standard advice has very little to say to you. This post is a map. We will discuss what self-hosted ZTNA actually means, the three genuinely different things vendors mean when they say "self-hosted," and how to sort any product on your shortlist into the right bucket in about five questions. We also want to be honest about the trade. Self-hosting costs you real things, and for a lot of organizations the cloud-delivered option is the correct answer. The point isn't that one bucket wins — it's that most people don't know the third bucket exists. ## **How ZTNA became a synonym for SaaS** Zero Trust as an architecture predates the products. NIST's SP 800-207 (August 2020) describes it in vendor-neutral terms: a **policy engine** that decides whether a given subject may access a given resource, a **policy administrator** that establishes or tears down the connection, and a **policy enforcement point** that guards the path to the resource. NIST puts the first two on the *control plane* — "judge, grant, or deny access to resources" — and the actual application traffic on the *data plane*, with the enforcement point straddling both, since it takes instruction from the control plane while sitting in the data path. Nothing in that description says where any of those components run. That's the part worth sitting with: the standard everyone cites as the definition of Zero Trust is silent on the delivery model. What happened commercially is that the first wave of ZTNA products were built by companies whose existing business was operating large global networks — secure web gateways, CDNs, cloud proxies. Delivering ZTNA from that infrastructure was the natural move, and it produced genuinely good products with genuinely real advantages: no hardware, global points of presence, someone else handling capacity and patching. The side effect is that the policy engine ended up in the vendor's cloud by default, and the industry stopped distinguishing between "Zero Trust" and "Zero Trust delivered as a service." Twelve years on, that conflation is baked into how the category gets described. ## **What "self-hosted" has to mean** Here's where most of the confusion lives, because several vendors describe themselves as self-hosted while running the part that matters on their own infrastructure. The useful test is to ask which components are inside your perimeter. There are five that count, and the first one is the one buyers most often forget to ask about: **1. The data plane.** The tunnels themselves — where your actual traffic goes. If a vendor terminates, brokers, or relays your sessions on their infrastructure, your data is transiting a network you don't control, whatever the encryption. This is the component with the most immediate consequences and it's routinely skipped in evaluations, because the conversation gets pulled toward features and policy long before anyone asks where the packets go. **2. The control plane.** The policy engine and policy administrator — the thing that evaluates each access request and decides yes or no. If this runs in a vendor's cloud, your access decisions are being made on someone else's computer, and your access depends on their availability. **3. The certificate authority and key material.** Who issues client credentials, who holds the signing key, who can revoke. If the vendor mints and distributes your credentials, they can in principle mint one for themselves. **4. The policy store.** Your access rules are a detailed description of what you consider sensitive and who you trust with it. That's meaningful intelligence about your organization regardless of whether anyone ever looks at it. **5. The logs.** Connection records, access decisions, session metadata. If your audit trail lives in a vendor's tenant, your evidence is an export from someone else's system rather than a record you hold. **Self-hosted ZTNA means all five are inside your trust domain.** Both planes, not one. That last point is what the rest of this post is organised around, because the two planes come apart independently — and the three genuinely different market positions are exactly the three combinations that exist. ## **Bucket one: cloud-delivered — vendor runs both planes** **Who's here:** Zscaler, [Cloudflare Access](https://openvpn.net/alternatives/openvpn-vs-cloudflare-zero-trust/), Netskope, [Palo Alto's Prisma Access](https://openvpn.net/alternatives/openvpn-vs-palo-alto-networks/), most of the names in the analyst quadrants — and, to be straightforward about our own portfolio, [our CloudConnexa](https://openvpn.net/cloud-vpn/). **The architecture:** the vendor operates the control plane *and* the data plane. You deploy lightweight connectors inside your network that make outbound connections to their infrastructure; users authenticate against the vendor's service; the vendor's policy engine decides what each user may reach; and the traffic itself traverses the vendor's network. **What's genuinely good about it:** fast deployment and nothing to run. No inbound firewall rules, so it works where you can't get a public IP — including behind carrier-grade NAT. Global presence, so a user in Singapore isn't hairpinning through Virginia. Capacity, patching, and availability are someone else's job, which for a small security team is worth a great deal. **What you're accepting:** the vendor knows your resource inventory, your access policy, your user directory shape, and your connection patterns — and your traffic crosses their infrastructure. New access depends on their control plane being reachable. Your audit evidence comes out of their system. And in a jurisdictional sense, their legal exposure is now part of your risk model — a point we've written about in the context of European regulation. For most commercial organizations that's a sensible trade honestly made, and it's why we sell a product in this bucket. It's only a problem if nobody told you it was a trade. ## **Bucket two: split — vendor control plane, your data plane** **Who's here:** [Tailscale is the clearest example](https://openvpn.net/alternatives/openvpn-vs-tailscale/). [Twingate](https://openvpn.net/alternatives/openvpn-vs-twingate/) and the other connector-based platforms sit here too, and so do the mesh overlays generally. **The architecture:** the vendor runs the control plane — distributing keys, holding your topology, deciding which peers may see each other — while the tunnels themselves go directly between your own endpoints. Your bulk traffic genuinely doesn't cross the vendor's network most of the time. **What's genuinely good about it:** you get most of the performance benefit of owning the data path, with none of the operational burden of running a control plane. NAT traversal is handled for you. For a distributed workforce this is often the best-performing option available. **What you're accepting:** two things, and the second is the one that gets missed. The vendor's coordination service still holds your topology, your device inventory, your connection timing, and your access policy — so the metadata exposure is essentially bucket one's. And "direct peer-to-peer" has a fallback: when a direct path can't be established, traffic relays through vendor-operated servers. Encrypted, but transiting infrastructure you don't own, usually without telling you which sessions it happened to. So this bucket owns the data plane *most* of the time, and the control plane never. Which is a real and useful position — just not the same thing as self-hosted, however the marketing reads. ## **Bucket three: self-hosted — both planes inside your trust domain** **The architecture:** all five components inside your perimeter. Control plane, data plane, CA, policy store, logs. No vendor infrastructure in the path of a decision or a packet. **Who's here:** not many. This is the thin bucket, and it's thin for structural reasons rather than technical ones. Cloud delivery is a better business: recurring revenue is cleaner, you control the deployment environment so support costs are predictable, you can ship weekly, and you're not debugging someone's bespoke network. A vendor choosing to support software running on infrastructure they can't see is choosing a harder operating model. **What you get:** access decisions and traffic that never leave your control, an audit trail no third party has ever held, and no dependency on a vendor's availability for new sessions. With a commercial vendor behind the software, you also get a named responsible party for the assessor or security questionnaire that asks who supports it. **What you're accepting:** you're running infrastructure. Patching, capacity, backups, and availability are yours. You need a reachable address, or a deployment model that works around not having one. And you don't get the global points of presence a cloud vendor operates — if your users are genuinely worldwide, that's an architectural consideration rather than a footnote. This is where [OpenVPN Access Server](https://openvpn.net/access-server/) sits, and it's why we think the category is worth naming. Not because it's the best answer for everyone — it plainly isn't, and our own CloudConnexa is in bucket one precisely because plenty of customers want that trade instead — but because a lot of teams who need bucket three have been told their only choices are bucket one and bucket two. **A note on open source:** The buckets above are about vendor delivery models, so projects without a vendor sit outside the framing. For completeness: [NetBird](https://blog.openvpn.net/openvpn-access-server-vs-netbird), Pomerium, Octelium, and Headscale are all self-hostable and capable, and they get you bucket three's architecture with no commercial support, a community-paced roadmap, and nobody to name when procurement asks who is responsible for the software. For a well-resourced platform team that's a legitimate choice. It's a poor fit for a five-person IT department in a regulated industry. ## **Sorting any vendor in five questions** Take these to a demo. Questions 1 and 2 establish which bucket you're in; the rest fill in the detail. 1. **Does traffic ever transit your infrastructure — including on fallback when a direct path fails?** The data-plane question, and the fallback clause is the whole point. Direct-path architectures generally relay through vendor servers when NAT traversal fails, which is documented rather than advertised. Ask what proportion of sessions relay in practice, and whether you can find out which of yours did. 2. **Where does the policy engine run — my infrastructure or yours?** The control-plane question. 3. **If your service is unreachable, can a user establish a new session?** If no, the control plane is theirs regardless of what the datasheet says. Note the word *new* — existing sessions often survive an outage, which gets offered as reassurance and isn't the same thing. 4. **Who holds the signing key for client credentials, and can I bring my own CA?** Determines whether you or the vendor is the root of trust. 5. **Can I produce a complete access log without querying your systems?** Determines whose evidence your audit trail is. Read the first two answers together and the bucket falls out: | **Data plane** | **Control plane** | **Bucket** | | --- | --- | --- | | Vendor | Vendor | **One** — cloud-delivered | | Yours (mostly) | Vendor | **Two** — split | | Yours | Yours | **Three** — self-hosted | There is no fourth combination on the market, because a vendor holding your data plane while you make the decisions isn't a product anyone sells. ## **What self-hosting actually costs** If we only listed the benefits, you'd rightly discount the whole post. **Operational load.** Patching, certificate renewal, capacity planning, monitoring, backups, disaster recovery. All yours. A self-hosted ZTNA deployment that stopped receiving updates eighteen months ago is worse than a cloud service you'd have grumbled about. **Reachability.** A server accepting inbound connections needs an address clients can reach. Straightforward in a data centre or cloud VPC; genuinely awkward on some networks. Cloud-delivered options sidestep this entirely, which is a real advantage and not a marketing one. **Geographic distribution.** One server in one region serves distant users worse than a global anycast network. Multiple regional deployments are the answer, and that's more infrastructure to run. **Certificate and key ownership.** Being your own root of trust is the point, and it comes with responsibilities a cloud vendor would otherwise carry: issuance, renewal, revocation, and protecting the signing key. How much of that lands on you depends on the platform. [Access Server](https://openvpn.net/access-server/features/zero-trust-app-broker/) includes [built-in PKI](https://openvpn.net/as-docs/v3/ca-certificate-management.html#generating-new-ca-certificates), certificate distribution through connection profiles, MDM support, and support for multiple CAs as well as [external PKI](https://openvpn.net/as-docs/v3/tutorials/tutorial--epki.html#tutorial--configure-external-pki-with-access-server-s-certool-script) — so most of the lifecycle is handled rather than hand-rolled. What stays yours is the decision-making: who signs, how long certificates live, and what happens when one needs revoking. That's the part being the root of trust actually means, and it's not onerous — but it isn't nothing either. ## **Who should be in which bucket** **Bucket one — cloud-delivered** suits you if your workforce is globally distributed, your security team is small, you have no regulatory constraint on where access decisions are made or where traffic goes, and speed matters more than architectural control. That's a large majority of commercial organizations. **Bucket two — split** suits you if performance across a distributed workforce is the priority and you want the data path direct, but you have no requirement about who holds your topology and access policy. The metadata exposure is bucket one's; the performance is closer to bucket three's. **Bucket three — self-hosted** suits you if you need both planes inside your perimeter for a reason you can articulate — data sovereignty, a compliance regime, an isolated or air-gapped network, contractual restrictions on third-party processing. Also worth a look if you're already operating Access Server competently, because you have the skills and the reachable address already, and the gap from VPN-style access to Zero Trust is smaller than it looks from outside. ## **The honest position** We sell in bucket one and bucket three, so treat our enthusiasm for the framing accordingly — though note that a vendor with a product in bucket one has limited incentive to talk up bucket three. What we'd genuinely say is this: the interesting question isn't which bucket is best. It's whether you chose yours. Plenty of teams are in bucket one because it was the only bucket their shortlist contained, and some of those teams have requirements that bucket one can't actually satisfy — they've just been describing the gap as an accepted risk because they didn't know there was an alternative. If that's you, the five questions above are worth an afternoon. And if you run the exercise and cloud-delivered still wins, that's a better-founded decision than the one you had yesterday.   ### Ready to see how OpenVPN can help protect your organization from attacks? Try the self-hosted Access Server solution or the managed CloudConnexa service for free, no credit card required. [See Which One is Right for You](https://openvpn.net/product-comparison/?_gl=1*1hi46u*_ga*NDgyODEwNDkyLjE3NzIxMjIzNDE.*_ga_E45Z33NTV7*czE3Nzc5ODY2ODIkbzExMiRnMSR0MTc3Nzk4ODMyMSRqNTUkbDAkaDE4NzIyNTczNDc.*_fplc*dVltNzJ6YmZ0bFZTdld4NjRtWVpVWXclMkJEV3AzZGhPUlRZaUppdWNxQkRjOER3MFN0VW84JTJCdEJGdnRDTmVYNlI5NlJBdTRLZ0VGOTNHMHc0U3l3bVFsR3NzQXk5RzJIQVdzNHE0QVJHcSUyQlVKUlRsNTM0S1RWZERyZ0V4NDNnJTNEJTNE*_gcl_au*MTM5NjEwNTIxNy4xNzcyMTIyMzQx*_ga_SPGM8Y8Y79*czE3Nzc5ODY2ODEkbzExMyRnMSR0MTc3Nzk4ODMyMyRqNTMkbDAkaDA.) ## Frequently asked questions ### **What is ZTNA?** Zero Trust Network Access is an approach to remote access that grants entry to individual applications and resources rather than to a network, and re-evaluates that decision continuously rather than once at login. Where a traditional VPN authenticates a user and then places them on a network segment, ZTNA authenticates the user, checks device posture and context, and gives them a path to one specific resource. NIST SP 800-207 describes the architecture in vendor-neutral terms. ### **What does ZTNA stand for?** Zero Trust Network Access. It's one component of a broader Zero Trust architecture rather than a synonym for it — Zero Trust also covers identity, device management, workload security, and data protection. ### **Can ZTNA be self-hosted?** Yes, although most commercial ZTNA products can't be. Nothing in the Zero Trust architecture requires the policy engine or the data path to run in a vendor's cloud; that's a delivery-model choice. Genuinely self-hosted ZTNA means all five components sit inside your trust domain: the data plane, the control plane, the certificate authority, the policy store, and the logs. Be careful with the term — some products described as self-hosted run only the data plane on your infrastructure while making access decisions in the vendor's cloud, and others do the reverse. ### **Is there an open-source ZTNA?** Several. NetBird, Pomerium, and Octelium are all open source and self-hostable, and Headscale is an open-source control plane for Tailscale-compatible clients. They're capable projects with a real trade-off: no commercial support, community-driven roadmaps, and no vendor to name when an assessor or a procurement process asks who's responsible for the software. ### **Does ZTNA replace the firewall?** No. ZTNA governs authenticated access to resources by identified users; a firewall controls traffic flow at network boundaries and inspects it for threats. They solve adjacent problems and most architectures need both. ZTNA can reduce your firewall's exposure by removing the need for broad inbound access, but it doesn't take over segmentation, egress filtering, or threat inspection. ### **What is replacing VPNs?** ZTNA is the usual answer, though "replacing" oversimplifies it. Many organizations run both for years, because a VPN is often better for the cases ZTNA handles awkwardly — full network access for administrators, protocols that don't proxy cleanly, and devices that can't run an agent. The more accurate description is that broad network-level access is being replaced by application-level access, and that transition can happen on the VPN infrastructure you already run. ### **Is self-hosted ZTNA more secure than cloud-delivered ZTNA?** Not inherently, and anyone claiming otherwise is selling something. Cloud vendors typically have larger security teams and patch faster than you will. What self-hosting changes is your *threat model*: it removes a third party from your trust boundary and eliminates a category of supply-chain and jurisdictional risk, at the cost of making patching, availability, and configuration your responsibility. Whether that's a net improvement depends entirely on how well you operate it. ### **How much does ZTNA cost?** Cloud-delivered ZTNA is typically priced per user per month, often with tiering that puts logging, device posture, and advanced policy in higher bands. Self-hosted licensing more commonly follows concurrent connections or server instances. The comparison people miss is that self-hosted costs also include the infrastructure and the staff time to operate it, while cloud pricing includes operations in the subscription. Model both over three years rather than comparing list prices. [Heather Walters](https://blog.openvpn.net/author/heather-walters) Heather is a writer for OpenVPN. ## Related posts from OpenVPN ### [![Zero Trust, Bought or Built? Why Europe Is Rethinking the Cloud-Broker ZTNA Model](https://blog.openvpn.net/hubfs/openvpn-blog-header-dream.png) Zero Trust Aug 14, 2026 Zero Trust, Bought or Built? Why Europe Is Rethinking the Cloud-Broker ZTNA Model](https://blog.openvpn.net/cloud-broker-ztna-self-hosted-europe) ### [![Buy, Build, or Self-Host: A European Decision Framework for Replacing Your ZTNA Vendor](https://blog.openvpn.net/hubfs/openvpn-blog-header-latte.png) Network Security Tools Sep 4, 2026 Buy, Build, or Self-Host: A European Decision Framework for Replacing Your ZTNA Vendor](https://blog.openvpn.net/buy-build-or-self-host-ztna-vendor-europe) ### [![Create Your Own Self-Hosted ZTNA Solution in 2026 with Access Server: Complete Setup Guide](https://blog.openvpn.net/hubfs/self-hosted-ztna-with-access-server.png) Cybersecurity Sep 30, 2026 Create Your Own Self-Hosted ZTNA Solution in 2026 with Access Server: Complete Setup Guide](https://blog.openvpn.net/create-your-own-self-hosted-ztna-solution) ### Subscribe for Blog Updates ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Heather Walters", "url" : "https://blog.openvpn.net/author/heather-walters" }, "dateModified" : "2026-10-06T22:28:59.708Z", "datePublished" : "2026-10-06T22:23:08.000Z", "headline" : "Self-Hosted ZTNA: The Category Few Vendors Offer | OpenVPN Blog", "image" : [ "https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_5_V1.png" ], "mainEntityOfPage" : { "@id" : "https://blog.openvpn.net/self-hosted-ztna-category", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.openvpn.net/hubfs/Dark=True%20Medium.png" }, "name" : "OpenVPN" } } ```