By this point in our series, the pattern should be familiar: EU regulation increasingly scores vendors on jurisdiction and operational control, the dominant cloud-broker ZTNA architecture puts a foreign vendor's infrastructure directly in your data path, and European procurement teams are getting better tools — and more legal reasons — to ask hard questions about both.
This post is the practical payoff: a framework for actually making the decision, and a direct comparison between self-hosted Access Server and the cloud-broker platforms most European IT teams are currently running.
The three real options
Buy a cloud-delivered ZTNA platform (Zscaler Zero Trust Exchange, Palo Alto Prisma Access, Cisco Secure Access). Fast to deploy, minimal internal operations burden, strong feature depth for very large, highly distributed enterprises. The trade-off, covered in this series' earlier posts, is a permanent third-party control plane in your access path — typically operated by a US company — plus ongoing subscription cost tied to a vendor's roadmap and pricing decisions.
Build a custom access solution. Full control, but a genuinely large undertaking: you're now responsible for the cryptography, the protocol implementation, the client software across every OS, and the ongoing security maintenance of all of it. For all but a handful of organizations with unusual requirements, this isn't a serious option — it trades a manageable vendor relationship for an unmanageable engineering commitment.
Self-host a mature, open-core platform. This is the middle path: production-grade software, built and maintained by a dedicated vendor, but deployed and operated on infrastructure you control. It's the option this series has focused on, because it's the one that actually resolves the jurisdiction and control questions without requiring you to become a cryptography shop.
Side-by-side comparison
|
Dimension |
Cloud-Broker ZTNA (Zscaler / Prisma Access / Cisco Secure Access) |
Self-Hosted Access Server |
|
Control plane location |
Vendor-operated, typically in the vendor's global PoP network |
Your infrastructure — on-prem, EU sovereign cloud, or your existing cloud region |
|
Legal jurisdiction exposure |
Bound by the vendor's home jurisdiction (typically US, subject to CLOUD Act) |
Bound by your own jurisdiction and infrastructure choices |
|
Traffic/metadata visibility |
Visible to the vendor by design (inspection happens in their cloud) |
Visible only within your own environment |
|
Codebase auditability |
Closed source; verification depends on vendor attestations |
Built on the open-source OpenVPN protocol; independently auditable |
|
DORA / NIS2 third-party risk classification |
Registered ICT third-party dependency; subject to audit-rights and exit-strategy obligations |
Software relationship, not an operated third-party service — a materially lighter dependency to document |
|
Deployment flexibility |
Fixed to vendor's cloud architecture |
On-prem, EU sovereign cloud, AWS/Azure/GCP, or hybrid — your choice |
|
Operational burden |
Low — vendor manages the service |
Moderate — your team operates the server, with vendor-supplied software and support |
|
Zero Trust capability |
Native, cloud-delivered ZTNA |
Delivers application-layer least-privilege access as a self-hosted Zero Trust Application Broker |
|
Vendor lock-in |
Moderate to high — proprietary client, policy engine, and often bundled SASE stack |
Low — built on an open, widely supported protocol; not bundled into a broader platform |
|
Pricing model |
Enterprise subscription, typically licensed per named user, tied to platform bundle |
Licensed by concurrent connected devices, not named users or seats |
Sources for competitor pricing/licensing terms: Cisco Secure Access ordering guide (licensed per covered user); Prisma Access licensing guide (licensed by unit — one unit equals one mobile user).
The pricing model difference is bigger than it looks
Most cloud-broker ZTNA platforms license by named user or seat — you pay for every person provisioned, whether or not they're connected at any given moment. Access Server licenses differently: by concurrent connected devices, not named users or seats.
That distinction matters in practice. A company with 100 employees and 50 registered devices might only ever have 25 of those 50 devices connected at the same time — a mix of shift patterns, part-time staff, contractors who log in occasionally, or simply people who aren't all online at once. Under a per-seat model, that company pays for 50 or 100 licenses regardless. Under Access Server's model, it only needs a 25-connection subscription to cover its actual peak usage, and can scale the subscription up as concurrent usage grows rather than as headcount grows.
For organizations with shift workers, distributed contractors, seasonal staff, or simply more registered devices than simultaneous users, this usually means paying for actual utilization rather than provisioned headcount — which can be a meaningfully different total cost than a comparable per-seat ZTNA subscription, on top of the jurisdictional and control advantages covered earlier in this series.
A framework for weighing the trade-off
Three questions tend to cut through most of the noise:
- Does your regulatory profile make third-party control-plane exposure a named risk? If you're a DORA-covered financial entity, an NIS2 essential or important entity, or simply selling into either category as a supplier, the answer is very likely yes — and that alone is often reason enough to move the access layer off a foreign-operated cloud.
- Is your organization's blast radius from the access layer large? Every employee, contractor, and site-to-site connection typically flows through this one layer. If a compromise or a legal-process event at this layer would be catastrophic, it's a strong candidate for bringing in-house — more so than layers with narrower exposure.
- Can your IT team take on a bounded, well-scoped migration? Unlike replatforming a customer database or switching identity providers, moving from a SaaS ZTNA platform to a self-hosted one is a project most competent IT teams can plan, execute, and close out in weeks. If your team has that capacity, the effort-to-risk-reduction ratio is unusually favorable.
If the answer to all three is yes, self-hosting the access layer is very likely the highest-leverage move available in your broader sovereignty roadmap — not because it solves every sovereignty question, but because it's one of the few places you can move from dependent to in control without rebuilding your business around it.
Getting started
Access Server supports Zero Trust Application Broker functionality from version 3.1.0 onward, providing application-layer least-privilege access alongside full operational control over where it runs, who can view the logs, and who holds the keys. It deploys on-prem, in your own data center, or on a European sovereign cloud provider.
For a deeper technical look at how the ZTNA enforcement itself works, see Self-Hosted ZTNA: How Domain Routing Turns Access Server Into an Identity-Aware Proxy. For the broader compliance case, see OpenVPN's earlier Sovereignty by Design series.
Frequently asked questions
Is self-hosting always the right answer for European organizations?
No. It's the right answer when regulatory exposure, blast radius, or jurisdictional risk at the access layer is high enough to justify the added operational responsibility. Smaller organizations with limited IT capacity and lower regulatory exposure may reasonably prioritize other layers first.
How long does migrating from a cloud ZTNA platform to self-hosted Access Server typically take?
Most IT teams can plan, execute, and close out this kind of migration in weeks rather than quarters, since it doesn't require replatforming identity, data, or application infrastructure — only the access layer itself.
Is Access Server priced per user like most ZTNA platforms?
No. Access Server is licensed by the number of concurrent connected devices rather than by named users or seats. A company with more registered users or devices than simultaneous connections only needs a subscription sized to its actual peak concurrent usage, not its total headcount.
Can Access Server match the feature depth of a full SASE platform like Prisma Access or Zscaler?
Access Server is focused specifically on secure access and Zero Trust enforcement rather than a full SASE bundle (SWG, CASB, SD-WAN, etc.). For organizations that need deep, unified secure access without adopting an entire platform ecosystem, that focus is often an advantage rather than a gap — and it avoids the lock-in of a bundled multi-product suite.
How does Access Server's per-connection pricing compare to Zscaler or Cisco Secure Access's per-user pricing in practice?
Both Zscaler and Cisco license by named or covered user, so cost scales directly with headcount. A 100-employee organization with 50 registered devices and 25 simultaneous connections pays for 100 or 50 licenses under those models regardless of actual usage; the same organization only needs a 25-connection Access Server subscription. See the Access Server pricing page for current tiers.
Does self-hosting Access Server mean giving up cloud deployment flexibility?
No. "Self-hosted" describes who operates the control plane, not where it physically runs. Access Server deploys on-prem, in a European sovereign data center, or directly on AWS, Azure, or Google Cloud — you keep full operational control while still using the cloud infrastructure you already run elsewhere.
Related posts
- Zero Trust, Bought or Built? Cloud-Broker ZTNA in Europe
- The CLOUD Act Problem Nobody's Pricing In
- DORA, NIS2, and the CRA: The Three EU Laws Rewriting Vendor Risk for Network Access
- Why Europe's Procurement Teams Are Asking for Source Code
- Part II: The Hidden Risks of US-Dependent Infrastructure for European Businesses
- OpenVPN Access Server vs. NetBird