Why Data Sovereignty Laws Are Forcing A Shift Toward Localized Private Infrastructure
Dana CazacuAuthor
Data residency is not data sovereignty. The CLOUD Act, CADA, and Canadian procurement policy are forcing a shift toward infrastructure you can control.
On June 3, 2026, the European Commission proposed the Cloud and AI Development Act (CADA), a four-tier cloud sovereignty framework, plans to triple EU data centre capacity, and new requirements designed to strengthen European control over critical cloud and AI infrastructure.
They're wrong. But not for the reasons you might think.
The Chamber's argument rests on a false binary: either you depend on American hyperscalers for world class cloud infrastructure, or you settle for inferior local alternatives and pay the price. What that framing ignores is the reason sovereignty initiatives exist in the first place.
The legal trigger behind many modern sovereignty initiatives is the U.S. CLOUD Act of 2018. The legislation allows U.S. authorities to compel access to data held by U.S. based providers regardless of where that data is physically stored. This distinction is critical because it shifts the sovereignty discussion away from geography and toward jurisdiction. Data residency determines where information sits. Legal jurisdiction determines who can ultimately access it.
It doesn't matter if your data resides in Frankfurt, Toronto, or São Paulo. Under the CLOUD Act, data access follows corporate control rather than server location.
This is not simply a European concern.
The Canadian government has launched a Sovereign Cloud Initiative and begun incorporating data residency and jurisdictional control into federal cloud procurement. More importantly, recent procurement requirements emphasize that cloud services must remain under the control of organizations not subject to foreign laws that could compel access to Canadian data. In other words, data residency alone is no longer considered sufficient.
Several provinces have adopted similar approaches. Quebec's Law 25 requires organizations to assess foreign legal exposure when personal information is processed outside the province, while
The underlying concern mirrors the European debate. Data location matters, but jurisdiction matters more. A cloud provider can operate infrastructure within a country while still remaining subject to legal obligations imposed elsewhere.
Canada's response reflects a broader global trend. As governments place greater emphasis on resilience, operational control, and supply chain risk, sovereignty is increasingly being evaluated through the lens of jurisdiction rather than geography alone.
American providers account for the majority of Europe's cloud market, while Canadian public sector cloud adoption remains heavily concentrated among U.S. hyperscalers. Governments on both sides of the Atlantic increasingly view this not simply as a market outcome, but as a strategic dependency.
The concern extends beyond privacy or government access requests. It is also a question of concentration risk. Critical services, healthcare systems, financial institutions, industrial operations, and AI infrastructure increasingly depend on a small number of providers governed by the same legal jurisdiction.
As a result, sovereignty is becoming less about data residency and more about operational control. The EU Data Act, AI Act, NIS2, and DORA all place greater emphasis on portability, transparency, resilience, and supply chain visibility. Similar discussions are emerging across Canada through procurement requirements, provincial privacy legislation, and digital sovereignty initiatives.
Taken together, these developments point toward a future where infrastructure control is no longer simply a technical preference. It is increasingly becoming a regulatory expectation.
This shift is often framed as a privacy discussion. In reality, it is increasingly a resilience discussion. The same architecture that reduces exposure to foreign legal jurisdiction can also reduce dependence on a single vendor, cloud provider, or supply chain.
The answer is not replacing one proprietary platform with another. It is reducing dependence on vendor-controlled infrastructure altogether.
This is ultimately an architectural decision.
OpenStack provides the cloud platform layer: compute, networking, storage, identity, and bare metal provisioning. Every component is open source, auditable, and deployable without reliance on a single vendor. Kubernetes provides the workload orchestration layer: namespace isolation, node affinity, admission controllers, and policy engines that can enforce jurisdictional requirements at the scheduling layer itself.
Together, OpenStack and Kubernetes form a sovereign infrastructure stack that delivers the same cloud native operating model organizations expect from hyperscalers: automation, APIs, infrastructure as code, self service provisioning, and workload portability, without inheriting any particular vendor's legal jurisdiction.
There is no kill switch. Every layer can be audited. Every layer can be modified. Every layer can be operated on infrastructure you control.
The same architecture that protects against foreign legal interference also protects against sanctions, trade disputes, licensing changes, service suspensions, vendor exits, and geopolitical escalation. Sovereignty is ultimately about maintaining operational continuity when the political environment changes faster than the technology stack.
What follows is the technical and strategic blueprint for making that shift, from the death of the borderless cloud model, through the architecture of a sovereign OpenStack and Kubernetes stack, to the operational reality of running fragmented infrastructure across a world that has decided, jurisdiction by jurisdiction, that proximity to your data is no longer optional.
§ The Sovereignty Premium Is a Design Choice, Not an Inevitability
The open-source approach changes that equation. Kubernetes provides the orchestration and policy layer, while OpenStack supplies the underlying compute, networking, storage, identity, and bare metal services. Together, they deliver cloud native operations without introducing dependence on a single provider's legal framework.
The EU is not simply permitting this approach. It is increasingly encouraging it. The proposed CADA framework would give preference to open-source solutions in public cloud and AI procurement, while encouraging Member States to support cloud technologies built on open hardware and software.
For platform teams, the shift matters because sovereignty is increasingly being evaluated across multiple layers of the stack. Infrastructure location, operational independence, ownership, and control are all becoming part of the equation. You can read more about this in Sovereign Cloud vs. Public Cloud: What Enterprises Are Re-Evaluating in 2026 .
Kubernetes plays a critical role here. Policy engines such as OPA and Kyverno, combined with admission controllers, node affinity, and GitOps workflows, allow organizations to express jurisdictional requirements directly in code. Workloads can be scheduled, isolated, and governed according to sovereignty requirements rather than relying on manual controls and documentation.
OpenStack provides the same transparency at the infrastructure layer. Organizations can operate compute, networking, storage, and identity services within their own jurisdiction while retaining full visibility into how those systems function.
Industry analysts expect this trend to accelerate. Gartner projects worldwide sovereign cloud spending will reach approximately $80 billion in 2026, a 35.6% increase from the previous year, driven by growing demand for digital sovereignty and operational independence. The firm also expects sovereign cloud adoption to shift 20% of current workloads from global providers to local alternatives. As infrastructure becomes increasingly fragmented across jurisdictions, operational consistency becomes just as important as compliance.
The challenge is no longer deploying infrastructure in multiple locations. The challenge is operating those environments consistently. Platform teams need common deployment patterns, policy frameworks, and operational processes regardless of where workloads run.
The question is whether sovereign environments are built on platforms designed for portability, transparency, and operational control from the beginning, or whether sovereignty is being retrofitted onto infrastructure that was originally designed for a borderless world.
§ The Anatomy of a Sovereign Cloud
Every sovereignty framework we've discussed, from CADA's four tiers and Canada's sovereign procurement requirements to the CLOUD Act's extraterritorial reach, translates into the same set of engineering constraints. Your infrastructure cannot phone home. Your software supply chain must be fully auditable. Your workloads must be provably confined to a specific jurisdiction. And every policy must be enforced at the API level, not documented in a wiki and hoped for.
Here's how you build it.
The IaaS Substrate: OpenStack
Sovereignty starts below Kubernetes. You need an IaaS layer that provisions compute, networking, and storage without introducing foreign dependencies.
OpenStack delivers this. Ironic provisions bare metal directly, with operating systems installed on physical servers and managed through APIs, without a proprietary hypervisor sitting between your workloads and your hardware. Keystone handles identity and authentication entirely within your environment. Neutron provides software-defined networking with full isolation. Ceph provides distributed storage across infrastructure you own and operate.
The sovereignty critical detail is that OpenStack can run fully air gapped. No telemetry endpoints. No license servers. No external dependencies. That is the architectural consequence of open source, and in a sovereignty focused environment it becomes a significant advantage.
As we detailed in What's Inside VEXXHOST's Kubernetes Sandwich, Atmosphere's architecture runs containerized OpenStack services inside a base Kubernetes layer, with Keystone handling multi-tenancy through project-based isolation, RBAC enforcement, and quota management, extended to Kubernetes clusters via identity federation through Keycloak supporting LDAP, SAML, and OpenID Connect. Each layer is modular but tightly integrated: the base layer provides resilience, the middle manages resources, and the top connects users to the orchestration they need. This is not a theoretical reference architecture. It is a production deployment model.
The sovereignty-critical detail is that OpenStack runs fully air-gapped. No telemetry endpoints. No license servers. No external dependencies. As we explained in How Atmosphere OpenStack Supports Digital Sovereignty, Atmosphere supports air-gapped deployments where OpenStack can be deployed without internet connectivity, ensuring maximum isolation and compliance for sensitive environments. That's the architectural consequence of open source, and in a CADA world, it's the feature that separates Level 2 from Level 4.
Policy Enforcement: Admission Controllers
This is where sovereignty becomes enforceable rather than aspirational.
Every request to the Kubernetes API server passes through admission controllers that evaluate it against your policies before execution. OPA/Gatekeeper and Kyverno are the two primary engines. Both intercept API requests and enforce compliance at deployment time. Kyverno uses native Kubernetes YAML, making it intuitive for teams already operating Kubernetes. OPA uses Rego, which is well suited to more complex compliance logic and cross-platform policy frameworks.
For sovereignty, the key patterns are straightforward:
Node affinity by jurisdiction: Nodes are labeled with jurisdiction metadata. Admission policies enforce that workloads can only schedule onto nodes matching their required jurisdiction. A pod targeting the wrong jurisdiction is rejected before scheduling.
Namespace isolation as jurisdictional boundaries: Each jurisdiction gets its own namespace or, more commonly, its own cluster. Policies enforce that resources cannot cross boundaries without explicit exceptions.
Image provenance validation: Only images signed by your internal CI/CD pipeline and verified against approved registries are admitted. This prevents workloads from introducing unaudited external dependencies.
Many organizations use both Kyverno and OPA together. Kyverno handles validation and mutation policies, while OPA handles more complex compliance logic and external data integration. Both integrate naturally with GitOps workflows. Policies live in Git, are peer reviewed, tested through CI/CD pipelines, and enforced automatically. The result is continuous compliance rather than reactive auditing.
Supply Chain Integrity: SBOMs and Image Signing
CADA Level 4 requires full transparency and control over the software supply chain with no interference from a third country. Whether the regulation explicitly references SBOMs or not, the requirement points in that direction.
For a sovereign stack, SBOMs are needed at every layer. Container images can be generated at build time using tools such as Syft, Trivy, or cdxgen, exported in SPDX or CycloneDX formats, and attached as signed attestations using Cosign. Infrastructure components, including OpenStack services, Kubernetes components, and operating system packages, should be traceable back to their source.
Admission policies can then verify that every image entering the cluster carries a valid SBOM attestation and cryptographic signature from an approved signing authority.
The sovereignty advantage of open source is straightforward. You generate SBOMs from source code you can inspect. You do not have to rely on a vendor supplied document and trust that it is complete. The dependency tree is inspectable, reproducible, and verifiable.
This is where proprietary platforms face a structural challenge. Full software supply chain transparency becomes difficult when significant portions of the stack cannot be independently inspected or audited.
§ The Operational Cost of Sovereignty
The architecture from the previous section is clean. Operating it is not.
The N Cluster Problem
Sovereignty means isolation. Isolation means separate clusters. Separate clusters mean every Day 2 task multiplies.
A global deployment across five jurisdictions is not one fleet. It is five independent OpenStack clouds, each running its own Kubernetes control plane, identity stack, and storage backend. In a sovereign topology, you cannot centralize the control plane because the control plane itself would create cross border data flows.
As we described in Running Multi Region Kubernetes on OpenStack, we've seen multi region setups designed beautifully on whiteboards fail in production in ways that no whiteboard anticipated. Passive cluster drift, DNS TTL surprises, and asynchronous storage replication all compound when clusters must remain jurisdictionally isolated. The math is unforgiving: every cluster becomes a separate island of upgrades, patching, certificate rotation, capacity planning, and incident response.6t
Kubernetes Day-2 maintenance is often the work that consumes the largest share of senior engineering capacity, and that is for a single cluster. As we detailed in Zero Downtime Kubernetes Upgrades: How Navos Does It, even in a single cluster, upgrades require careful sequencing: control plane nodes upgraded one at a time via Cluster API, worker nodes cordoned and drained respecting PodDisruptionBudgets, and load balancers maintaining continuity throughout. Multiply that by several sovereign environments with no shared management plane and you need a fundamentally different operational model.
Hardware Sovereignty: The Layer Below Your Stack
You can run open source everything and still depend on proprietary firmware beneath the entire stack. The Baseboard Management Controller is a small independent processor embedded in enterprise servers that provides remote management functions. It operates independently of the host operating system, runs its own firmware and network stack, and remains active even when the server is powered off.
This creates a sovereignty challenge. Researchers have repeatedly identified severe vulnerabilities in management firmware that allow remote code execution and persistence below the operating system layer. Kubernetes policies do not inspect BMC firmware. Traditional SBOM processes often do not include it.
The mitigation path includes OpenBMC for auditable open-source firmware, Hardware Bills of Materials extending supply chain practices into hardware provenance, and continuous verification moving from vendor trust models toward independently verifiable evidence. Sovereignty at the software layer means little if the firmware layer remains opaque.
§ The Future of Sovereign Infrastructure
The era of the borderless cloud is ending. As we wrote in "Cloud First" Is Becoming "Control First", Here's What Changed, AI, regulation, and cost pressure are driving a shift to control first. Whether driven by CADA, the CLOUD Act, national procurement requirements, or broader concerns around resilience and concentration risk, organizations are increasingly being asked the same question: who ultimately controls the infrastructure their critical workloads depend on?
The answer cannot be found in contracts alone. Sovereignty is not a procurement exercise. It is an architectural one.
The technologies discussed throughout this article all serve the same goal: turning sovereignty from a policy objective into an enforceable technical property. Infrastructure ownership, workload placement, software supply chain transparency, and operational control become part of the platform itself rather than promises made by a vendor.
Platforms optimized for a specific workload pattern can become constraints when requirements change. A long-term strategy should be built around adaptability, allowing teams to support new workloads without redesigning the underlying platform. Kubernetes provides flexibility at the orchestration layer. OpenStack extends the same principle to infrastructure, creating a foundation that can evolve as applications, models, and requirements change.
The next generation of cloud infrastructure will not be defined solely by scale. It will be defined by control. Organizations that begin building these capabilities now will be better positioned to operate cloud platforms and AI systems in a world where jurisdiction, transparency, and operational independence are becoming strategic requirements rather than optional features.
Virtual machines, Kubernetes & Bare Metal Infrastructure
Choose from Atmosphere Cloud, Hosted, or On-Premise. Simplify your cloud operations with our intuitive dashboard. Run it yourself, tap our expert support, or opt for full remote operations. Leverage Terraform, Ansible or APIs directly powered by OpenStack & Kubernetes
