Zero Trust Network Access (ZTNA) replaces network-level trust with per-application, identity-driven access decisions. Instead of putting a user on a subnet and hoping firewall rules catch what they shouldn't reach, ZTNA verifies the user and device, then grants access to one specific resource — nothing else.
That part isn't controversial. What's increasingly controversial in Europe is where that verification and brokering happens — and who operates the infrastructure doing it.
The dominant ZTNA model puts a vendor's cloud in the middle
Most enterprise ZTNA today products are sold as a cloud-delivered service. Platforms like Zscaler's Zero Trust Exchange, Palo Alto Networks' Prisma Access, and Cisco Secure Access route traffic through the vendor's global point-of-presence network. The user connects to the vendor's cloud; the vendor's cloud verifies identity and policy; the vendor's cloud brokers the connection to the internal application.
This is a legitimate architecture, and it solves a real problem: consistent policy enforcement for a distributed workforce without a private network. But it has a structural feature that's easy to overlook in a sales demo — the vendor isn't just supplying software. They're sitting inside your data path, permanently, for as long as you're a customer. That's a control-plane risk worth weighing on its own terms.
That means:
- Your access policies live on infrastructure you don't operate.
- Your traffic metadata — who accessed what, when, from where — passes through and is often logged by a third party.
- Your ability to enforce, audit, or change that layer is bounded by what the vendor's platform allows.
For years, this trade-off was accepted as the cost of modern security. In Europe in 2026, it's being actively re-examined.
Why the sentiment has shifted
Three things have converged to make this a board-level question rather than an IT preference.
First, the regulatory floor has risen sharply. The EU Data Act, NIS2, and the Cloud Sovereignty Framework all now ask, in various forms, the same underlying question: who can compel access to this system, and can you prove it? A European Commission scoring framework that grades providers on legal jurisdiction and operational control didn't exist a few years ago. Now it's part of procurement.
Second, enforcement against large platforms has become routine, not exceptional. The Digital Markets Act and Digital Services Act produced roughly €3.77 billion in fines against major US platforms in 2025 alone, including a €2.95 billion penalty against Google for adtech abuse and continuing cases against Apple, Meta, and X. Regardless of how any individual case is viewed, the cumulative effect has been to normalize the idea that dependence on a small number of foreign providers is a governance issue, not just a technical one. The European Parliament has gone further, formally pushing the Commission for stronger enforcement and flagging that "new challenges posed by generative AI and cloud services need to be addressed" — including, explicitly, cloud infrastructure.
Third, the concentration is measurable and getting attention at the top of institutions: roughly 70% of European cloud infrastructure runs on three US hyperscalers, and Gartner projects European sovereign cloud spending will grow 83% year-over-year in 2026. For the full regulatory and market breakdown — including the €180 million sovereign cloud procurement tender and the EuroStack initiative's roughly €300 billion ambition through 2035 — see Part II of this series.
None of this means cloud-delivered ZTNA vendors are doing anything unlawful. It means the default assumption — that routing your access layer through a foreign vendor's cloud is a neutral technical choice — no longer holds in Europe the way it used to.
Cloud-broker ZTNA vs. self-hosted ZTNA, side by side
|
Dimension |
Cloud-Broker ZTNA |
Self-Hosted ZTNA |
|
Where enforcement runs |
Vendor's global point-of-presence network |
Infrastructure you deploy and control |
|
Who operates the box |
The vendor, permanently, for the life of the contract |
Your own team (on-prem or in your own cloud account) |
|
Data-path exposure |
Traffic and metadata transit and are often logged by a third party |
No vendor point of presence in the data path for internal traffic |
|
Legal jurisdiction |
Bound by the vendor's home jurisdiction and its legal obligations (e.g., US CLOUD Act) |
Bound by wherever you choose to deploy |
|
Auditability |
You take the vendor's word for enforcement behavior |
Verifiable directly on the box (DNS logs, NAT tables) |
|
Operational overhead |
Low — vendor manages the platform |
Higher — your team runs and patches the server |
What "self-hosted ZTNA" actually means
There's a common misconception that Zero Trust requires a cloud-delivered, vendor-brokered service standing between users and applications. It doesn't. ZTNA is a security model — explicit verification, least privilege, micro-segmentation, assumed breach — not a delivery mechanism. Where the enforcement point runs is an infrastructure decision, not a security requirement.
OpenVPN Access Server is a concrete example of ZTNA implemented as self-hosted infrastructure rather than a subscribed cloud service. Through domain-based access rules, Access Server can be configured to stop granting network access entirely and instead broker access to individual applications by hostname — the same architectural pattern used by commercial identity-aware proxies, running on a server you deploy and control. (For our technical walkthrough of the DNS-based enforcement — DNS interception, NAT tables, and how to verify it — see the companion deep dive.)
- Zero Trust Application Broker functionality of Access Server verifies identity, location context, and device identity, then assigns a synthetic intermediate IP scoped to a single authorized app. The device never receives a route to the private network, making lateral movement structurally impossible.
- Access rules are evaluated against domains (app.example.com), based on source identity, so a Support group can be permitted exactly one internal tool without ever getting broad access to the network it lives on.
- The zero-trust brokering happens within your own infrastructure — there's no vendor point of presence in the data path for internal traffic.
- Enforcement is verifiable on the box itself rather than something you have to take a vendor's word for.
The difference isn't "less secure" versus "more secure." It's who operates the enforcement point, and under whose legal jurisdiction that operator sits.
This maps directly onto OpenVPN's own zero trust network access use case: per-application access without exposing the underlying network.
What this doesn't solve on its own
Self-hosting the access layer is one piece of a broader sovereignty strategy, not the whole thing. It doesn't automatically make your identity provider, your cloud storage, or your SaaS stack sovereign. It also puts more operational responsibility on your own team — someone has to run and patch the box. That box doesn't have to be a physical server in a closet, though: you can deploy it inside your own AWS, Azure, or GCP account and still keep the enforcement point under your legal and operational control. For most organizations, that's a manageable trade against the alternative: a subscription in which a foreign company also happens to own your enforcement point.
Frequently asked questions
Does Zero Trust Network Access require a cloud vendor?
No. ZTNA is a security model based on identity verification and per-application access, not a specific delivery method. It can be implemented as a cloud-brokered service or as self-hosted software running on infrastructure the customer controls.
Is self-hosted ZTNA harder to deploy than a cloud SASE platform?
It requires more initial setup and ongoing operational ownership, since there's no vendor managing the infrastructure for you. In exchange, the organization retains full control over where data and logs live and who can access the enforcement layer.
Why are European companies specifically re-evaluating cloud-delivered ZTNA?
Because EU regulation (the Data Act, NIS2, the Cloud Sovereignty Framework) increasingly scores vendors on legal jurisdiction and operational control, and because concentrated dependence on a small number of non-EU providers has become a named strategic risk in EU policy, not just a theoretical one. See our GDPR compliance overview for how OpenVPN approaches EU data-protection obligations.
Is self-hosted ZTNA only for on-premises deployments?
No. "Self-hosted" describes who controls the enforcement point, not where the hardware sits. You can run Access Server on-premises or inside your own AWS, Azure, or GCP account and keep the same jurisdictional and operational control.
How is ZTNA different from a traditional VPN?
A traditional VPN typically grants network-level access once a user authenticates; ZTNA grants per-application access after continuously verifying identity, device, and context. See How ZTNA differs from a traditional VPN for a full comparison.
Further reading
The European Access Layer series and related OpenVPN resources:
- Part I: The Hidden Risks of US-Dependent Infrastructure for European Businesses
- Part II: Why Europe Is Drawing Its Own Digital Borders
- Part III: Sovereignty by Design — How Self-Hosting Puts European Businesses Back in Control
- Technical deep dive: Self-Hosted ZTNA — Domain Routing on Access Server
- ZTNA vs. VPN: What's the Difference?
- Product: Access Server Domain Routing feature
- Use case: Zero Trust Network Access with OpenVPN