--- title: "How to Evaluate ZTNA Vendors: 18 Questions to Ask | OpenVPN Blog" description: Feature checklists don't distinguish ZTNA vendors — architecture does. Eighteen questions that reveal who really controls your access, and what good answers look like. image: https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_2_V2.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) # How to Evaluate a ZTNA Vendor When You Can't Route Auth Through Their Cloud Oct 7, 2026 • 11 min read ![](https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_2_V2.png) Share - - - - How to Evaluate ZTNA Vendors: 18 Questions to Ask | OpenVPN Blog 13:55 By Heather Walters ## 18 essential questions to ask your ZTNA vendors. Most ZTNA RFPs are feature checklists. MFA, device posture, SSO integration, split tunnelling, session recording, SIEM export. The problem is that every serious vendor ticks all of them. Feature parity arrived in this category a few years ago, which means a checklist-driven evaluation produces a shortlist of products that look identical on paper and are architecturally quite different underneath. The questions that actually separate them are about *where things happen*. Who decides whether a session is allowed. Who holds the key that signs your credentials. What your vendor learns about your network in the course of doing its job. And what happens to your access when their service has a bad afternoon. Here are eighteen of them, organised by what they reveal, with notes on what a good answer sounds like. They work in a demo, a security questionnaire, or a procurement document. ## **Start here: where do the packets go, and where is the decision made?** If you ask two questions, ask these. **1. Does my traffic ever transit your infrastructure — including on fallback?** **2. Where does the policy engine run — on my infrastructure or yours?** The first is about the data plane, the second about the control plane, and almost everything downstream follows from the pair. The data-plane question comes first because it's the one buyers skip: evaluations get pulled toward features and policy long before anyone asks where the packets actually go.[As we've written elsewhere](https://claude.ai/cowork/cse_01T35qKrAvFLZgU212KNunTE#), a genuinely self-hosted ZTNA deployment keeps five things inside your trust domain: the **data plane**, the control plane, the certificate authority, the policy store, and the logs. Both planes, not one. That matters because the two planes come apart independently, and there are exactly three positions on the market: | **Data plane** | **Control plane** | **What it's called** | | --- | --- | --- | | Vendor | Vendor | Cloud-delivered | | Yours (mostly) | Vendor | Split — mesh and connector platforms | | Yours | Yours | Self-hosted |   None of these is a trick. Each is a legitimate architecture with real advantages. But "your traffic never passes through our cloud" is a claim about one plane, and buyers routinely hear it as a claim about the whole system. [![Subnet Calculator Blog Image CTA ](https://no-cache.hubspot.com/cta/default/43411546/d6dc0237-1a8c-4671-8c67-4261b3f56777.png)](https://cta-redirect.hubspot.com/cta/redirect/43411546/d6dc0237-1a8c-4671-8c67-4261b3f56777) ## **Availability: what breaks when your vendor breaks?** **1. If your control plane is unreachable, can a user establish a *new* session?** The word "new" is doing the work. Existing sessions often survive an outage, and that's frequently offered as reassurance. It isn't the same as being able to onboard someone during an incident. **2. Can an administrator change a policy during your outage?** Relevant during a security incident, which is exactly when you'll want to revoke someone. **3. What's your measured availability over the last 24 months, and where is it published?** Ask for the history, not the SLA. An SLA is a refund promise; the incident record is the actual behavior. **4. Is there a documented degraded mode?** Some products cache policy at the enforcement point so access continues without the control plane. Good engineering, worth knowing about, and it should be documented rather than folklore. **5. What happens if we stop paying?** Not a hostile question. Does access fail closed immediately, or is there a grace period? For the infrastructure your workforce depends on, [the answer belongs in the contract](https://openvpn.net/access-server/pricing/). ## **Trust: who is the root?** **6. Who holds the signing key for client credentials?** If the vendor mints your credentials, the vendor can in principle mint one for anybody. **7. Can I bring my own certificate authority?** The cleanest answer to question 6. If yes, you remain the root of trust and the vendor is an enforcement mechanism rather than an authority. **8. Can your staff issue a credential valid on my deployment, and what stops them?** You're asking about internal controls, not accusing anyone. Good answers involve hardware security modules, dual authorization, and audit logs the customer can see. A vague answer is itself informative. **9. Are the client agents open source, and is the server component?** Frequently the client is and the server isn't. Worth knowing which half you can inspect. ## **Knowledge: what does the vendor learn?** **10. What metadata do you hold about my deployment, and for how long?** Any coordination service has to know your device inventory, your resource list, and connection timing to function. That's inherent, not a flaw. The question is what's retained and for how long. **11. Do you hold my access policy, and can you read it?** Your policy is a detailed description of what you consider sensitive and who you trust with it — meaningful intelligence about your organization whether or not anyone looks at it. **12. Which jurisdictions is that data stored and processed in, and which legal regimes reach it?** For non-US organizations this is often the question that decides the whole evaluation, and the answer isn't a region picker. Data residency is where bytes sit; jurisdiction is who can compel their disclosure. **13. Have you received government requests for customer data, and do you publish a transparency report?** A vendor that publishes one is easier to assess than one that doesn't. ## **Evidence: whose logs are they?** **14. Can I produce a complete access log without querying your systems?** This decides whether your audit trail is a record you hold or an export from someone else's platform. Assessors increasingly care about the difference. **15. What's in your logs that isn't in mine?** Sometimes a lot. Worth establishing before an incident rather than during one. **16. If you were breached, what of mine would be exposed?** A vendor who has genuinely thought about this will answer specifically. One who says "nothing, it's all encrypted" hasn't engaged with the metadata question. ## **The data path, including the part nobody mentions** **17. Does traffic ever transit your infrastructure — including on fallback?** The fallback clause is the whole point. Direct peer-to-peer architectures generally relay through vendor-operated servers when NAT traversal fails, which is normal, documented, and rarely mentioned in the sales conversation. Ask what proportion of connections relay in practice, and whether you can find out which of yours did. **18. Can I self-host the relays?** Some products let you. It substantially changes the answer to 17. [![openvpn\_ztna-research-report\_email\_800x200](https://blog.openvpn.net/hs-fs/hubfs/openvpn_ztna-research-report_email_800x200.png?width=2500&height=625&name=openvpn_ztna-research-report_email_800x200.png)](https://go.openvpn.net/ztna-research-report-2026) ## **How the common architectures answer** Briefly, since the three positions are covered properly in the pillar post — check current vendor documentation before quoting any of this in a decision. **Cloud-delivered** (Zscaler, [Cloudflare Access](https://blog.openvpn.net/comparing-openvpn-cloudconnexa-and-cloudflare-one), Netskope, Palo Alto's Prisma Access, and our own [CloudConnexa](https://openvpn.net/cloud-vpn/)): the trade sits in questions 10 through 17. Expect usually strong answers on 3 and 4 — better than a self-hosted deployment will manage. **Split** ([Tailscale](https://blog.openvpn.net/comparing-openvpn-cloudconnexa-and-tailscale), ZeroTier, [Twingate](https://blog.openvpn.net/comparing-openvpn-cloudconnexa-and-twingate) and the connector-based platforms): press question 17, and 18 too, since some vendors let you self-host the relays and that changes the answer materially. Note the metadata exposure is essentially the same as cloud-delivered; what you gain is the data path, most of the time. **Self-hosted** (where OpenVPN Access Server sits): expect weaker answers on 3 and 4 than a cloud vendor gives you. Your availability is your own, and honest self-hosted vendors will say so. **Without a vendor at all** (NetBird, Pomerium, Octelium, Headscale, the OpenVPN community edition): questions 1 through 18 answer the way you'd want, because there's nobody on the other side. The cost lands elsewhere — no support contract, community-paced roadmap, and nobody to name when procurement asks who's responsible. ## **How to use this** Don't score all eighteen equally. Pick the three or four that map to a constraint you can actually articulate, and weight those heavily. A useful exercise before you talk to anyone: write down what would have to be true for you to *reject* an otherwise excellent product. If nothing on that list involves where the control plane runs, then cloud-delivered ZTNA is almost certainly your answer and you can evaluate on features and price with a clear conscience. That's a real outcome and a large majority of buyers land there. If something on the list does involve control-plane location — a sovereignty requirement, a compliance regime, a contract restricting third-party processing, an isolated network — then you've just discovered that most of the market can't meet your requirements, and you'd rather discover that now than in month four of a procurement. ## **What a good answer sounds like** Across all eighteen, the pattern that should reassure you isn't a particular architecture. It's specificity. A vendor who says "the policy engine runs in our cloud, here's exactly what we hold, here's our retention period, here's our transparency report, here's the degraded mode, and here's why we think that trade is worth it for most customers" has given you everything you need to make a decision. That's a good vendor with a cloud architecture. A vendor who answers architectural questions with the word "secure" repeatedly, or treats question 8 as an insult, or describes a self-hosted data plane as a self-hosted product, has told you something too. We build in the thinnest bucket here, so weight our enthusiasm for the category accordingly. But the questions work regardless of who you buy from, and a buyer who asks all eighteen ends up with a better deployment than one who compares feature matrices — even if they buy from someone else. ### 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 ### **Is ZTNA better than a VPN?** For most remote access use cases, ZTNA's model is stronger: access to a specific application rather than a network segment, continuously re-evaluated rather than decided once at login. But "better" depends on the job. VPNs remain better suited to full network access for administrators, protocols that don't proxy cleanly, and devices that can't run an agent. Many organizations run both for years, and the more useful framing is that broad network-level access is being replaced by application-level access — which can often happen on VPN infrastructure you already own. ### **What are the disadvantages of Zero Trust?** The practical ones: it's an architecture rather than a product, so there's no single thing to buy that delivers it; policy design is real work and badly designed policy either blocks legitimate work or grants too much; agent requirements exclude devices that can't run one; and cloud-delivered implementations introduce a dependency on the vendor's availability and a third party into your trust boundary. Cost and complexity are usually higher during transition than steady state, which makes the middle of a migration the hardest part to defend to a budget holder. ### **Does ZTNA include MFA?** ZTNA platforms enforce MFA but generally don't provide it — they integrate with your identity provider, which is where the factors live. That's the right division of labour: your IdP should be the authority on authentication, and ZTNA should be the authority on authorization. When evaluating, the question isn't whether MFA is supported but whether it can be enforced conditionally — per application, per user group, or in response to a risk signal — rather than only globally at login. ### **How does ZTNA improve on traditional network security?** Traditional models trust based on network location: get onto the network and you can reach whatever the network reaches, which means one compromised credential yields broad lateral movement. ZTNA authenticates and authorizes each access request against a resource, so a compromised credential yields access to the resources that credential was entitled to and nothing more. It also gives you per-resource access logs rather than "this user was on the VPN for six hours." ### **What is universal ZTNA?** A term for extending the same policy engine to users both remote and on the local network, rather than treating the office as trusted. In practice it means the same identity and device checks apply whether someone is at a desk or in a hotel, often replacing traditional network access control. It's a sensible direction, though be aware it's also a term with more marketing behind it than settled definition, and vendors mean somewhat different things by it. ### **What's the difference between ZTNA and SASE?** ZTNA is one component; SASE is an architectural bundle that typically includes ZTNA plus secure web gateway, cloud access security broker, firewall-as-a-service, and SD-WAN, delivered together from a cloud edge. If you need the whole bundle, SASE vendors sell it. If you specifically need remote access to internal resources, ZTNA alone is a smaller purchase and a smaller dependency — and worth noting that SASE is definitionally cloud-delivered, so if control-plane location is a constraint for you, SASE won't resolve it. ### **How much does ZTNA cost?** Cloud-delivered ZTNA is usually per user per month, frequently with logging, device posture, and advanced policy in higher tiers — so the headline figure often isn't the figure you'll pay. Self-hosted licensing more often follows concurrent connections or instances. The comparison buyers get wrong is omitting operational cost from the self-hosted side and platform risk from the cloud side. Model both over three years, and include the cost of migrating away in year four. [Heather Walters](https://blog.openvpn.net/author/heather-walters) Heather is a writer for OpenVPN. ## Related posts from OpenVPN ### 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-07T19:00:30.255Z", "datePublished" : "2026-10-07T19:00:30.000Z", "headline" : "How to Evaluate ZTNA Vendors: 18 Questions to Ask | OpenVPN Blog", "image" : [ "https://blog.openvpn.net/hubfs/Copy%20of%20OV010_AccessServer_ZTNA_BlogHeader_2_V2.png" ], "mainEntityOfPage" : { "@id" : "https://blog.openvpn.net/how-to-evaluate-ztna-vendors-control-plane-questions", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.openvpn.net/hubfs/Dark=True%20Medium.png" }, "name" : "OpenVPN" } } ```