Zero Trust Network Access (ZTNA) is defined by its architecture — identity-based access, least privilege, no implicit network trust, and continuous verification — not by which protocol carries the traffic. A service can use the OpenVPN protocol as its encrypted transport and still meet every NIST SP 800-207 and CISA Zero Trust Maturity Model requirement, because protocol and architecture sit at different layers of the stack.
The conversation everyone is having
Open almost any Zero Trust briefing from the last few years — CISA's Zero Trust Maturity Model, NIST SP 800-207, the guidance circulating through procurement and audit teams — and you'll find a recurring instruction: move away from the traditional VPN, and toward Zero Trust Network Access (ZTNA). It's good advice. But somewhere between the guidance and the buying decision, a piece of shorthand crept in, quietly distorting the whole discussion.
The shorthand goes like this: "VPN bad, ZTNA good." And underneath it sits an assumption that rarely gets examined — that VPN and ZTNA are two different products you choose between, and that anything using a VPN protocol can't really be ZTNA.
That assumption is worth unpacking carefully, because it confuses two things that live at completely different layers of the stack: the architecture that decides who gets access to what, and the transport that carries the bytes. This post is about keeping those two ideas separate, because once you do, a lot of the "is it really ZTNA?" debate dissolves.
What the guidance is actually objecting to
When CISA, NIST, and the broader Zero Trust community push organizations away from "the VPN," they are not objecting to encryption, or to tunnels, or to any particular wire protocol. They are objecting to a security model — the one that most legacy VPN deployments happen to implement.
That model looks like this. A remote user authenticates once, a tunnel comes up, and the user's device is effectively dropped onto the corporate network. From that moment, the user can reach broad ranges of internal IP space. Access is governed — if it's governed at all — by network constructs: subnets, routes, and ACLs. The implicit rule is "authenticated equals trusted," and trust is granted at the level of the network, not the application.
The problems with this model are well documented. A compromised credential or device can move laterally across everything the tunnel exposes. The internal topology — IP ranges, server addresses — is visible to the connected client, which is exactly the reconnaissance map an attacker wants. And access decisions are coarse: you tend to grant a whole subnet because expressing "this user, this one application, nothing else" in ACLs is painful at scale.
So the real objection is to implicit, network-level trust with broad exposure. Notice what's not in that sentence: nothing about which tunneling protocol carries the traffic.
What ZTNA actually requires
Strip ZTNA down to its load-bearing principles and you get a short, demanding list:
- Identity-centric access. Decisions are made about a specific user and device, not about an IP address or a network location.
- Least privilege at the resource level. A user is granted access to the specific applications they need — not to the network those applications happen to live on.
- No implicit network exposure. Resources are hidden from everything except authorized sessions. Authenticating to the service does not place you "on the network."
- Continuous verification. Posture and context are checked on an ongoing basis, not just at login.
- Default deny. Nothing is reachable unless a policy explicitly allows it.
This is the heart of the model often described as an identity-aware proxy: an intermediary that authenticates the identity, evaluates policy, and brokers a connection to a named application — without ever joining the client to the resource's network or revealing that network's structure.
Every one of these requirements is about policy and architecture. None of them specifies, or even cares about, the protocol used to tunnel the session between the client and the broker. That's the crux of the whole matter.
On the "OpenVPN protocol means it isn't real ZTNA" objection
This is the objection worth meeting head-on, because it's the one that follows CloudConnexa around: "It uses the OpenVPN protocol to build tunnels, so it's a VPN, so it can't be true ZTNA."
The argument is a category error. It conflates the data-plane transport (how the session is encrypted and carried) with the control-plane architecture (how access is decided and scoped). These are independent choices.
Consider the parallel. HTTPS is "just" TLS over TCP. The fact that your bank's web portal and a random brochureware site both ride on TLS tells you nothing about their security architectures — authentication, authorization, session handling, and segmentation are where they differ, and those live above the transport. Nobody argues a bank isn't doing real access control because it "uses TCP." Yet the equivalent argument is routinely made about ZTNA and VPN tunneling protocols.
A tunnel protocol is a mechanism for establishing an encrypted, authenticated channel between two endpoints. The OpenVPN protocol is a mature, independently audited, widely deployed implementation of exactly that. What determines whether a system is ZTNA is what happens to traffic once it's inside the channel — and specifically:
- Is the client placed on a network, or connected only to a named application?
- Are internal IP addresses and routes exposed to the client, or hidden?
- Is access default-deny and scoped per resource, or open within an IP subnet?
- Is identity, device posture, and context evaluated continuously?
A system can answer those questions the zero-trust way while using the OpenVPN protocol as its encrypted transport. It can also answer them the legacy way while using OpenVPN, IPsec, WireGuard, or anything else. The protocol does not decide the architecture. A modern ZTNA service and a 2009-era full-tunnel VPN can, in principle, share a wire format and still sit at opposite ends of the security spectrum.
So the honest version of the question isn't "does it use a VPN protocol?" It's "when a session is up, what can the user actually reach, and how was that decided?" That's the test that maps to CISA and NIST guidance — and it's a test about architecture, which a transport protocol can neither pass nor fail on its own.
Where CloudConnexa fits
CloudConnexa is a cloud-delivered private networking service, and it uses the OpenVPN protocol to build the encrypted tunnels that connect users, devices, and networks to its global points of presence. That much is true and not hidden — it's the transport.
What matters for the ZTNA question is the layer above. CloudConnexa can operate so that:
- Resources are defined as Applications (identified by domain name) rather than as exposed subnets, so the client connects to a named application, not a network.
- Actual application server IPs and internal routes are cloaked from the client — an intermediary address stands in, so there's no internal map to probe.
- Access is governed by Access Groups under a default-deny posture, expressing "this identity may reach this resource" at the application level.
- Device posture, identity, and location context are verified continuously, not just at connection time.
Those are the ZTNA properties on the list above — delivered over an OpenVPN data plane. The transport is OpenVPN; the architecture is identity-aware, least-privilege, default-deny access. Both statements are true at once, and that's precisely the point this series will keep coming back to.
It's also worth being even-handed: CloudConnexa can also run in a traditional full-network mode, exchanging subnet routes and behaving like a classic VPN. That flexibility is a feature, not a contradiction — but it does mean that "is it ZTNA?" depends on how it's configured, not on the protocol it speaks. We'll dig into exactly how those two modes work in the next post.
The takeaway
The Zero Trust guidance is right to push organizations away from implicit, network-level trust. But "VPN" in that guidance is shorthand for an architecture, not a verdict on any encryption protocol. When you evaluate a tool against CISA or NIST principles, the questions that matter are about identity, scope, exposure, and continuous verification — what the system does with access — not about the wire format underneath.
Hold onto that distinction, and the "it uses OpenVPN so it can't be ZTNA" objection reveals itself for what it is: a confusion of layers. In the next post, we'll get concrete about how one service operates as a pure identity-aware proxy and as a full network — and what actually changes on the wire between the two.
Next in the series: "One Service, Two Modes — How CloudConnexa Operates as Both an Identity-Aware Proxy and a Full Network."
Frequently Asked Questions
Is ZTNA a protocol or an architecture?
ZTNA (Zero Trust Network Access) is an architecture — a set of policies about identity, least privilege, and default-deny access — not a tunneling protocol. Any encrypted transport, including the OpenVPN protocol, IPsec, or WireGuard, can carry ZTNA traffic. What makes access "zero trust" is how the system decides who can reach what, not how the bytes are encrypted.
Can the OpenVPN protocol be used for real ZTNA?
Yes. The OpenVPN protocol is a mature, independently audited method for establishing an encrypted tunnel. Whether a service built on it delivers ZTNA depends on what happens after the tunnel is up — does it expose a network, or connect the user only to a named application under a default-deny policy? CloudConnexa, for example, uses the OpenVPN protocol as its transport while enforcing identity-aware, application-level access through Access Groups and Application Domain-Based Routing.
What's the difference between ZTNA and a traditional VPN?
A traditional VPN typically places an authenticated user on the broader corporate network, governed by subnet-level rules. ZTNA instead evaluates identity and context continuously and grants access only to specific named applications, keeping the rest of the network invisible. The two aren't mutually exclusive — see our full comparison of ZTNA and VPN deployment models for how they fit together in practice.
What do NIST and CISA say about Zero Trust Architecture?
NIST SP 800-207 defines Zero Trust Architecture around continuous verification, least privilege, and assuming breach. CISA's Zero Trust Maturity Model translates those principles into a practical maturity roadmap across identity, devices, networks, applications, and data. Neither document specifies or restricts which transport protocol carries the traffic.
What is an identity-aware proxy?
An identity-aware proxy is the architectural pattern behind most ZTNA implementations: rather than routing a client onto a network, it authenticates the user's identity, checks policy, and brokers a connection to one named application at a time, without ever exposing the underlying network to the client — we break down the mechanics of this model in a companion post.
Further Reading
- Why Zero Trust Network Access (ZTNA) Implementations Fail — the deployment failure patterns to plan around once the architecture question is settled.
- How CloudConnexa Delivers the SSE Framework — how the same Access Groups and Application Domain-Based Routing map onto the three SSE pillars.
- ZTNA vs. VPN: What's the Best SMB Cybersecurity Solution? — a deployment-strategy comparison of the two models.