In the first post in this series, we looked at why data sovereignty has moved from policy debate to procurement requirement in Europe — a regulatory wave, hundreds of billions of euros in committed investment, and a clear political signal that European businesses are being asked to think harder about where the critical decisions in their stack get made.
Before we get into the risks side of that conversation, a caveat to consider: the sovereignty story is often misread as a referendum on the major US cloud providers. It isn’t. AWS, Google Cloud, and Microsoft Azure — and the EU regions they operate — remain excellent places to run compute, and many European businesses, including ones with the most demanding regulatory profiles, will keep using them for years to come.
What is changing in 2026 is not where workloads run. It’s who controls the software, the keys, the logs, and the data plane that sits on top of that compute — and what legal regime that controlling entity sits under.
With that framing in place, the risks below are showing up in legal opinions, regulatory guidance, incident reports, and the procurement questionnaires landing in IT inboxes across the continent. They apply with particular force to architectures where the control plane, not the underlying infrastructure, is operated by a third party under foreign jurisdiction.
The CLOUD Act and the question of who actually controls the data
The US CLOUD Act, passed in 2018, gives US authorities the power to compel any US-based company to produce data it legally controls — wherever in the world that data is physically stored. Frankfurt, Dublin, Stockholm, it doesn’t matter. The relevant question for the CLOUD Act isn’t where the data sits, it’s who controls it.
This sits in direct, unresolved tension with European law. The EU Data Act, which began applying in September 2025, explicitly requires cloud providers operating in the EU to take technical and contractual measures to prevent unlawful third-country access to non-personal data. GDPR has been doing the same job for personal data since 2018.
Read that way, the CLOUD Act exposure depends on who is in the data-controller seat, and that is mostly a question about software and service relationships, not about which infrastructure provider you happen to use.
A European company using a US-headquartered SaaS or managed service, in which the US vendor operates the control plane, holds the keys, and is functionally the data controller, sits squarely within the CLOUD Act’s reach. A European company running its own software in an EU region of a US cloud provider, where the company itself is the data controller and the cloud provider is a pure infrastructure host, sits in a meaningfully different position. The architectural distinction matters, and procurement teams have started to ask about it explicitly.
That distinction doesn’t make the CLOUD Act disappear. For US-headquartered service providers operating in Europe, the conflict between US extraterritorial demands and EU data-protection law is structural and unresolved. Comply with a CLOUD Act demand, and you may breach EU law. Refuse it, and you may breach US law. Many CLOUD Act demands also include non-disclosure orders, meaning the European customer whose data is being handed over may never be told.
“Data residency in an EU region” alone, then, is a necessary question but not a sufficient one. Where the bytes sit on disk is half the answer. Who legally controls them — and which jurisdiction that controller sits under — is the other half.
Adequacy is not as durable as it looks
For now, the EU-US Data Privacy Framework keeps personal data flowing across the Atlantic. The adequacy decision survived its first major legal challenge in September 2025 when a challenge brought by French politician Philippe Latombe was dismissed, and an appeal remains to be seen. Privacy activist Max Schrems, who already brought down two previous frameworks, has signaled that another challenge is coming in the form of the upcoming “Schrems III” case.
Underneath the framework, the US legal foundation it depends on is moving as well. FISA Section 702, the surveillance authority that has been the central sticking point in every Schrems case, was reauthorized in April 2024 and is scheduled to sunset on 12 June 2026. Any business whose European compliance posture quietly depends on adequacy holding is taking a position on US legislative politics, whether they know it or not.
The lesson from the last decade is not “adequacy is doomed” — it’s that adequacy is a moving target. Architectures that can absorb a Schrems III ruling without a fire drill will fare a lot better than those that cannot.
NIS2 puts personal liability behind the questions
Now let’s talk about NIS2.
NIS2 entered active enforcement in 2026. By early this year, 22 of 27 EU member states had transposed it into national law. The directive widens the definition of “essential” and “important” entities, raises penalties to up to €10 million or 2% of global turnover, and — this is the part that has changed how boards think about IT — introduces personal accountability for senior management.
A few specific requirements bring the sovereignty conversation directly into NIS2 scope:
- Supply chain security. In-scope entities are expected to assess and manage risks across their ICT supply chain, including third-party providers and their dependencies. A network and access stack whose control plane is operated by an external party under foreign jurisdiction is, by definition, a supply chain risk to evaluate.
- Incident reporting timelines. Early warning within 24 hours, an incident notification within 72 hours. Both are very hard to hit if your security team does not have full visibility into the systems sitting between users and applications.
- Governance and audit. Boards are now expected to approve and oversee cybersecurity risk-management measures. “We outsourced that part” is no longer a defensible answer.
For essential entities, NIS2 effectively pushes architecture questions out of the IT room and onto the audit committee agenda.
(Curious how OpenVPN stacks up against these requirements? See our overview of OpenVPN’s compliance posture — including ISO/IEC 27001:2022, SOC 2, and HIPAA — for how a self-hosted secure access vendor maps to these expectations.)
Vendor lock-in is now a regulatory category
For years, lock-in was a procurement concern — an annoyance you accepted as the cost of buying into a hyperscaler ecosystem. The EU Data Act has made it a legal one. Cloud and edge providers operating in the EU are now required to remove commercial, technical, and contractual barriers that prevent customers from switching providers, with transition periods being shortened over the coming years.
That changes the calculus on every long-running infrastructure decision. Architectures that assume you’ll always be on the same provider — proprietary protocols, deeply coupled identity, closed network planes — are not just a strategic risk. They are increasingly a compliance one. Buyers who once accepted lock-in are now actively penalizing it in procurement.
Concentration risk is no longer abstract
Beyond the legal and regulatory layers sits a simpler operational reality: the last two years have made it impossible to ignore how much of Europe’s digital economy depends on a very small number of providers.
A configuration change at a hyperscaler, an identity provider incident, a regional or global outage — events that used to be footnotes in trade press now take down hospitals, payment systems, airlines, and government services across multiple countries simultaneously.
For background, see our guide to cloud security architecture.
You cannot solve concentration risk with a contract clause. You solve it with architecture — by making sure that the systems your business actually depends on can keep working even if one large provider has a bad day.
Where this lands for secure access
Each of these risks lands somewhere specific in your stack. Customer databases. Identity providers. Backups. Communications. Productivity suites. And — easy to overlook, hard to fix later — the network and access layer that connects your workforce, partners, and cloud workloads.
Secure remote access is one of the points in the stack where these risks compound in a particularly inconvenient way. A SaaS VPN whose control plane runs in a US data center is, simultaneously: a CLOUD Act exposure, an NIS2 supply chain question, an adequacy dependency, a lock-in surface, and a concentration point. Every employee session, every site-to-site tunnel, every contractor connection flows through it. The blast radius is large, and the visibility — for the end-customer — is often small. See our enterprise VPN explainer for how this layer is typically structured today.
The good news is that of all the layers in a typical enterprise stack, secure access is one of the easier ones to bring back inside your own perimeter without disrupting the rest of the business. A self-hosted business VPN is one of the cleanest ways to do exactly that — which is what we’ll cover in the final post in this series.
What we’ll cover next
In the third and final post, we’ll look at what sovereignty-aligned architecture actually looks like in practice — and specifically how OpenVPN Access Server lets European businesses (and US businesses serving European customers) take an entire category of risk off the table without rebuilding their stack.
For now, the takeaway: the cost of “we’ll worry about it later” on sovereignty has gone up sharply in 2026. The regulators, the courts, and your customers are all asking the same question — who actually controls the systems your business runs on? — and they are no longer accepting vague answers.