Every cloud provider in 2026 claims to offer a “sovereign cloud.” The term has become so diluted that it now appears in marketing copy for products that violate the core principles of sovereignty by design. Hyperscalers slap the label on region-restricted instances. European consortiums build sovereign wrappers around American hyperscaler infrastructure. Managed service providers call themselves sovereign because they operate in a single country.
None of this is sovereignty. It is marketing.
Sovereign cloud has a real definition, with real requirements that most providers cannot meet. This post defines what sovereignty actually means, identifies where the industry’s most prominent “sovereign” offerings fall short, and explains why genuine sovereignty matters more now than at any point in the last two decades.
A Rigorous Definition of Sovereign Cloud
Sovereign cloud is cloud infrastructure where the data, the operations, the legal jurisdiction, the personnel, and the supply chain are all subject to the laws of a single nation – and only that nation. It is not a feature you enable. It is an architectural and organizational property that either exists across the entire stack or does not exist at all.
Sovereignty requires five pillars. If any one of them is missing, the provider is not sovereign.
1. Data Residency
All customer data – compute, storage, backups, snapshots, metadata, API logs, billing records – must physically reside within the borders of the sovereign jurisdiction. No cross-border replication. No global metadata stores. No centralized telemetry pipelines that aggregate data across regions in other countries.
Data residency is the most basic requirement, and the one most providers claim to satisfy. But residency alone is not sovereignty.
2. Operational Control
The infrastructure must be operated by personnel within the sovereign jurisdiction. This includes system administration, incident response, security monitoring, hardware maintenance, and customer support. If a support ticket can be routed to a team in another country, or if a security incident is investigated by analysts in a foreign jurisdiction, operational sovereignty is broken.
3. Legal Jurisdiction
The legal entity operating the cloud must be incorporated in and subject to the laws of the sovereign jurisdiction – and not simultaneously subject to conflicting foreign legal obligations. A US subsidiary of a Chinese parent company is subject to Chinese national security laws regardless of where it operates. A European subsidiary of a US hyperscaler is subject to US CLOUD Act obligations. Dual jurisdiction is the opposite of sovereignty.
4. Personnel Nationality
For workloads subject to export controls (ITAR, EAR), defense requirements (CMMC), or classified processing, the nationality and clearance status of personnel with access to the infrastructure matters. Sovereign cloud for regulated US workloads requires that all personnel with logical or physical access to customer environments are US persons operating within US jurisdiction.
5. Supply Chain Transparency
The customer must be able to verify who has access to their data and through what chain of subprocessors. Opaque subprocessor agreements, undisclosed fourth-party vendors, and global support escalation paths that route through foreign jurisdictions all undermine sovereignty. If you cannot enumerate every entity with potential access to your data, you do not have sovereignty.
How Hyperscalers Fail the Sovereignty Test
AWS, Azure, and Google Cloud all offer region selection. Some offer dedicated regions, government-specific clouds, or sovereignty-branded products. None of them deliver genuine sovereignty for most customers. Here is why.
Global Control Planes
Hyperscaler infrastructure is architected around global control planes. IAM, billing, DNS, API gateways, logging, and telemetry systems operate as globally distributed services. Even if your VM runs in us-east-1, the metadata about that VM – who created it, when, what API calls were made, what network policies are applied – may be processed and stored in systems that span multiple countries.
AWS GovCloud and Azure Government partially address this by isolating control planes for government workloads. But these are separate products with separate pricing, separate feature sets, and FedRAMP authorization requirements that put them out of reach for most commercial enterprises.
Multinational Legal Exposure
All three major hyperscalers are US-headquartered multinational corporations with operations in dozens of countries. They are simultaneously subject to US CLOUD Act obligations, EU GDPR requirements, and whatever data access laws exist in every jurisdiction where they operate. This creates conflicting legal obligations that no amount of contractual language can fully resolve.
For a European customer seeking sovereignty from US law, a hyperscaler’s EU region does not help – the US parent company can still be compelled to produce data under the CLOUD Act. For a US customer seeking sovereignty from foreign law, a hyperscaler’s US region does not help – the provider’s foreign subsidiaries and operations create legal surface area that a purely domestic provider does not have.
Offshore Operations Teams
Hyperscalers employ tens of thousands of engineers, support staff, and contractors across the globe. Support tickets filed in the US may be handled by teams in India, Ireland, or the Philippines. Security incidents may be triaged by a global SOC with analysts in multiple countries. Hardware maintenance may be performed by contractors whose corporate structure and personnel are outside US jurisdiction.
None of this is secret. It is how global companies operate. But it is incompatible with sovereignty.
Opaque Subprocessor Chains
Try to get a complete list of every entity with potential access to your data on a hyperscaler. You will receive a subprocessor list that names high-level categories of vendors without disclosing the specific companies, their locations, or what access they have. For enterprises with strict supply chain requirements – defense contractors, financial institutions, healthcare organizations – this opacity is a compliance problem.
The European Sovereign Cloud Landscape
Europe has invested heavily in sovereign cloud initiatives, driven by legitimate concerns about US legal reach (CLOUD Act, FISA Section 702) and strategic dependence on American technology. The results are mixed.
GAIA-X
GAIA-X launched in 2019 as a Franco-German initiative to establish European digital sovereignty. It was supposed to create a federated data infrastructure governed by European values and regulations. Six years later, GAIA-X has produced standards documents and governance frameworks but no meaningful cloud infrastructure. It has also been criticized for allowing non-European hyperscalers to participate as members, which undermines its stated sovereignty goals.
GAIA-X is a standards body, not a cloud provider. It defines what sovereign cloud should look like without actually building one.
Bleu (Orange + Capgemini + Microsoft)
Bleu is a joint venture between Orange, Capgemini, and Microsoft designed to offer Azure and Microsoft 365 services under French operational control. The idea is that French companies operate the infrastructure, French law governs the data, and Microsoft provides the technology under license without direct access to customer environments.
This is a creative legal structure, but it has a fundamental problem: the technology stack is still Microsoft’s. Software updates, security patches, and feature releases originate from Redmond. If Microsoft decides to change how Azure works, Bleu inherits those changes. The operational independence is real at the infrastructure layer but illusory at the software layer.
T-Systems Sovereign Cloud (with Google)
T-Systems, a subsidiary of Deutsche Telekom, partnered with Google Cloud to offer a sovereign cloud for German and European customers. T-Systems controls access, manages encryption keys, and operates the infrastructure. Google provides the cloud platform technology.
The pattern is the same as Bleu: European operations wrapped around American technology. It addresses legal jurisdiction and operational control, but the technology dependency remains. If Google discontinues a service, changes an API, or modifies licensing terms, T-Systems has limited recourse.
These are not sovereign clouds. They are sovereign wrappers around non-sovereign technology. The distinction matters for organizations that need genuine independence across all five pillars.
Why US Sovereign Cloud Matters Now
The sovereignty conversation has been dominated by European perspectives – GDPR, Schrems II, transatlantic data transfer frameworks. But US organizations have their own sovereignty requirements that are growing more urgent by the month.
Defense and Intelligence
ITAR-controlled data, CMMC-regulated workloads, and classified processing all require infrastructure operated exclusively by US persons within US jurisdiction. The defense industrial base cannot rely on cloud providers with multinational operations teams or foreign parent companies, regardless of what region the workload runs in.
Healthcare
Healthcare organizations handling protected health information (PHI) face regulatory exposure when their cloud provider’s support teams, subprocessors, or parent companies operate outside US jurisdiction. A sovereign platform that supports HIPAA-eligible workloads with exclusively US-based operations eliminates an entire category of compliance risk.
Financial Services
SOX audit requirements, SEC data retention rules, and state-level financial privacy regulations all benefit from infrastructure where the complete chain of custody – data, operations, personnel, legal entity – is within US jurisdiction. Regulators are increasingly asking financial institutions to demonstrate not just where their data is stored, but who can access it and under what legal authority.
Critical Infrastructure
Energy, water, transportation, and telecommunications systems are under active cyber threat from nation-state actors. The ongoing conflict with Iran has made this concrete, not theoretical. CISA advisories have warned of Iranian cyber retaliation targeting US critical infrastructure. The Strait of Hormuz closure has disrupted global supply chains. Cyber warfare is an active theater of operations.
For organizations operating critical infrastructure, sovereign cloud is not a compliance checkbox. It is a risk management decision. Keeping data, operations, and control within US borders and US legal jurisdiction reduces the attack surface, simplifies incident response, and eliminates dependency on foreign infrastructure or personnel during a geopolitical crisis.
The Geopolitical Case for Sovereignty
Sovereignty is often framed as a compliance requirement. It is also a strategic one.
As of March 2026, the United States is in active military conflict with Iran. The Strait of Hormuz is closed. Iranian-affiliated cyber actors are targeting US infrastructure. Israel has demonstrated the capacity to disable an entire nation’s internet connectivity in a matter of hours. These are not future scenarios – they are current events.
In this environment, the question is not whether your data is in a US region. The question is whether the people who operate your infrastructure, the legal entity that controls it, and the supply chain that supports it are all within US borders and US legal jurisdiction. If any link in that chain extends to a foreign jurisdiction – whether through a parent company, an operations team, a subprocessor, or a global control plane – your data is exposed to risks that no SLA or contractual clause can mitigate.
Cloud infrastructure is national infrastructure. Treating it as a commodity that can be sourced from any global provider, in any jurisdiction, with any corporate structure, is a peacetime assumption. We are not operating in peacetime conditions.
What Open Edge Delivers
Open Edge is a US sovereign cloud provider that satisfies all five pillars of genuine sovereignty. This is not a product tier or an add-on. It is how the company is structured and how the infrastructure is built.
Data Residency
All infrastructure is physically located in US data centers. Our primary facility is Iron Mountain VA-1 in Manassas, Virginia. Our second facility, STACK Infrastructure POR02A in Hillsboro, Oregon (us-west-1), comes online in Q2 2026. All customer data – compute, storage, backups, metadata, logs – remains within US borders. No cross-border replication. No global metadata aggregation.
Operational Control
All personnel with physical or logical access to customer environments are US-based. System administration, incident response, security monitoring, and customer support are performed exclusively by US-based staff. No offshore support teams. No multinational operations centers.
Legal Jurisdiction
Open Edge is a US-based limited liability company with no foreign parent entity, no foreign subsidiaries, and no foreign investors with governance rights. We are subject to US law and only US law. There is no conflicting foreign legal obligation that could compel disclosure of customer data to a foreign government.
Personnel
Every employee and contractor with access to infrastructure is a US person operating within US jurisdiction. For customers with ITAR, CMMC, or clearance requirements, this is not negotiable – and we do not treat it as optional.
Supply Chain Transparency
We disclose the full chain of entities with access to customer environments. No opaque subprocessor agreements. No unnamed fourth-party vendors. If your compliance team needs to enumerate every entity in the data path, we provide that documentation.
Security and Compliance
Sovereignty is necessary but not sufficient. The infrastructure also needs to be secure and aligned with enterprise compliance requirements.
- FIPS 140-3 validated encryption – CMVP Certificate #5115, running on Ubuntu 24.04 LTS with OpenSSL 3.x. AES-256 encryption at rest, TLS 1.2+ in transit. Encryption keys generated and managed within US data centers.
- SOC 2 and ISO 27001 control frameworks – Open Edge follows SOC 2 and ISO 27001 control frameworks across access management, change control, incident response, encryption, and monitoring.
- HIPAA-eligible workloads – The platform supports HIPAA-eligible workloads for healthcare organizations handling protected health information.
- Contract-based engagement – Open Edge is not a self-service platform. Every customer engagement includes contractual data residency guarantees, defined SLAs, and documented security commitments. This is infrastructure for enterprises with specific requirements, not a credit card signup page.
Questions to Ask Any “Sovereign” Cloud Provider
If a provider claims to offer sovereign cloud, ask these questions. The answers will tell you whether you are looking at genuine sovereignty or a marketing label.
- Where is your parent company incorporated, and is it subject to the laws of any foreign jurisdiction?
- Are all personnel with access to customer environments – including support, operations, and contractors – based in this country?
- Where are your control plane services hosted? Is metadata processed or stored outside the sovereign jurisdiction?
- Can you provide a complete, named list of every subprocessor with potential access to customer data?
- Do your encryption keys ever leave the sovereign jurisdiction, even temporarily, for backup or disaster recovery?
- If a foreign government issued a legal demand for customer data, would any entity in your corporate structure be obligated to respond?
- Is your sovereignty a product tier (available at extra cost) or an architectural property of the entire platform?
If the provider hesitates on any of these, you do not have sovereignty. You have residency with extra steps.
Talk to Us
Open Edge is built for enterprises that need genuine sovereign cloud infrastructure – not a marketing label on a shared global platform. If your organization operates in defense, healthcare, financial services, or critical infrastructure, and you need US-sovereign cloud with FIPS 140-3 validated encryption, contractual data residency guarantees, and full supply chain transparency, we are ready to discuss your requirements.