.png)
Cybersecurity
Jun 8, 2026
Aug 24, 2026
•
7 min read
The US CLOUD Act lets US law enforcement compel a US-headquartered company to produce data it controls, regardless of where that data is physically stored. It doesn't matter if the servers sit in Frankfurt, Paris, or Dublin. What matters is which company controls the system — and what country's courts that company answers to.
This is the part of the sovereignty conversation that gets lost when the discussion turns to encryption strength or data center location. Neither one addresses the actual legal exposure.
Encryption protects data in transit. It doesn't protect the vendor's obligations.
Every serious ZTNA and VPN platform on the market today uses strong encryption. That was never the vulnerability. The exposure sits one layer up: at the control plane, where policy decisions, authentication events, session metadata, and — in many architectures — decrypted traffic for inspection purposes are all visible to whoever operates that layer.
If a US company operates your control plane, US law can compel that company to hand over what it can see or access, through a legal process that doesn't require notifying you, and that doesn't stop at the US border. A European data-residency claim ("your data stays in our EU region") describes where bytes are stored. It says nothing about who can be legally compelled to produce them.
This is precisely the mechanism that has kept the EU-US data transfer relationship in a state of ongoing legal uncertainty. The EU-US Data Privacy Framework survived its first major legal challenge — the EU General Court dismissed the Latombe case and upheld the framework in September 2025 — but Latombe appealed, and a second review is now before the Court of Justice of the EU. Section 702 of the US Foreign Intelligence Surveillance Act is on a legislative clock toward an April 2026 sunset, and privacy advocates have publicly signaled a "Schrems III" challenge is coming. Any access architecture built on the assumption that current legal protections are permanent is building on ground that has already shifted twice.
Why this is specifically relevant to ZTNA procurement
The most widely deployed enterprise ZTNA and SASE platforms — Zscaler's Zero Trust Exchange, Palo Alto Networks' Prisma Access, and Cisco Secure Access — are all operated by US-headquartered companies, delivered as cloud services in which the vendor's own global infrastructure sits directly in the data path between users and applications. That's the architecture that makes these platforms work: traffic is routed to the vendor's point-of-presence network, inspected and policy-checked there, and forwarded on.
This is a reasonable, well-engineered architecture for the problem it solves. It is also, unavoidably, an architecture in which a US company operates and has visibility into a European organization's access-control layer — which is exactly the fact pattern the CLOUD Act, and the EU's regulatory response to it (including the control-plane and vendor-exit obligations now showing up in DORA, NIS2, and the CRA), is concerned with.
None of this implies wrongdoing on the part of any vendor. It's a description of legal exposure, not conduct. A European CISO evaluating these platforms today has to be able to answer a question that increasingly appears in board-level risk reviews and regulatory guidance alike: if a US legal order compelled our vendor to produce data or grant access, would we know, and could we do anything about it? For a cloud-delivered platform operated entirely by the vendor, the honest answer is usually "no, not really."
What changes when the enforcement point is self-hosted
Access Server removes this specific exposure by removing the third party from the architecture, not by promising stronger contractual protections around it. When Access Server is deployed on infrastructure you operate — your own data center, a European sovereign cloud provider, or a hyperscaler region you've already committed to — there is no vendor-operated control plane sitting between your users and your applications for anyone to compel. For the fuller architectural picture — clustering, high availability, and data-channel offload — see Sovereignty by Design.
That includes:
- Authentication and certificates. Access Server manages VPN certificates locally by default and can integrate with your own PKI — the identity layer stays under your operational control.
- Policy and access rules. Domain-based and role-based access rules are configured and enforced on your own server, not synced to a vendor cloud.
- Logs and session data. You decide what's collected, where it's stored, and how long it's retained — a decision no third party can override because no third party has custody of it.
OpenVPN is not immune to legal process either — no vendor anywhere is. The difference is what a legal order against OpenVPN could actually compel: at most, access to the software and to OpenVPN's own systems. It cannot compel access to a customer's self-hosted deployment, because OpenVPN never operates it, never sees its traffic, and never holds its keys. That's a structurally different exposure than a platform where the vendor is the runtime environment for every customer's traffic.
The limits of this argument
Self-hosting doesn't make an organization immune to legal process in its own jurisdiction, and it doesn't resolve every cross-border data question a business faces. It resolves one specific, well-defined problem: removing a foreign, cloud-operated control plane from the middle of your access layer. For many European organizations, that is precisely the highest-leverage, lowest-effort piece of the sovereignty puzzle to fix first — which is why it's consistently one of the first layers procurement teams flag in vendor jurisdiction reviews.
Frequently asked questions
Does the CLOUD Act apply even if data is stored in EU data centers?
Yes. The CLOUD Act's reach is based on whether a company is subject to US jurisdiction — typically by being US-headquartered or having a sufficient US presence — not on where the data is physically stored.
Are Zscaler, Palo Alto Networks, and Cisco doing anything wrong by being US companies?
No — this is a jurisdictional fact, not a conduct issue. All three are legitimate, widely used security vendors. The point for European buyers is understanding what legal exposure comes with a cloud-delivered architecture operated by a company subject to US law, and weighing that against their own regulatory and risk requirements.
Does self-hosting eliminate all legal-jurisdiction risk?
It eliminates the specific risk of a foreign vendor's cloud infrastructure sitting in your data path. It doesn't eliminate every cross-border legal consideration a business has — those depend on your broader technology stack, not just the access layer.
How is this different from a data residency guarantee?
Data residency describes where bytes are physically stored. It says nothing about which company controls the system, or which country's courts can compel that company to produce data or grant access to it — that's a jurisdiction question, not a storage-location question.
Does the CLOUD Act conflict with GDPR?
The two operate on different legal bases and can pull in opposite directions: a CLOUD Act order can require disclosure that GDPR would otherwise restrict, which is why regulators and courts have not fully resolved how they interact — the EU-US Data Privacy Framework is the current attempt to reconcile them, and it is still being litigated.
