The CLOUD Act and why data residency isn't enough

The promise of data residency

The standard pitch from every hyperscaler over the past decade has been some version of: "your data lives in this region, governed by these local laws." For most procurement teams, that was enough. For boards in 2026, it is not.

The reason is the 2018 US Clarifying Lawful Overseas Use of Data Act — the CLOUD Act. The Act grants US law-enforcement authorities the right to compel any US-controlled cloud provider to surrender customer data regardless of where in the world that data physically sits. A bucket in Frankfurt, sitting in an AWS region run by AWS EMEA, is reachable by a US National Security Letter.

Why this isn't just a US problem

The UK's Investigatory Powers Act (2016, expanded 2024) makes equivalent provision for UK-controlled providers. China's National Intelligence Law (2017) goes further. France's loi sur le renseignement. Russia's various data-localisation laws. The pattern across jurisdictions is identical: every major economy has, or is rapidly building, legal authority to compel its domestic cloud industry to surrender customer data held outside its borders.

This is not a hypothetical concern. Microsoft, Google, and Amazon all publish transparency reports that disclose hundreds-of-thousands of government data requests per year.

What customer-managed keys actually do

The next layer of defence sold by hyperscalers is customer-managed keys (CMK). The idea is that even if the provider's plane is reachable by court order, the customer holds the keys — so the provider cannot decrypt without customer cooperation.

This is technically true in a narrow sense, and operationally false in the sense that matters. CMK keys are held in the provider's KMS. When a workload running in the provider's environment requests a read, the unwrap happens within that environment. The keys are operationally in scope of the provider's plane. A court order targeting the provider's compute can, in principle, reach the unwrap operation.

What actually works

For sovereignty to be a property the customer can rely on, three things need to be true at the data layer, not just the contract layer:

1. The key never leaves the customer in unwrapped form. Zero-knowledge architecture: the storage operator has no API path that returns plaintext.
2. No single provider holds enough of the file to read it. Multi-cloud erasure coding (RS(5,2)">Reed-Solomon RS(5,2) in SkyeConnex's case): five of seven shards are required to reconstruct, and they live with five different providers in as many jurisdictions as the customer chose.
3. Jurisdictional spread is enforced at upload. Allow-list, block-list, strict-mode geo policy — applied per-shard, audited per-file, signed for verification.

This is the architecture SkyeConnex built. See it →

The board-level argument

Boards now ask their CIOs and CISOs the same question: "If a US National Security Letter lands at our hyperscaler tomorrow, what happens?" The acceptable answer is no longer "we have a contract clause." It is "they receive ciphertext shards that cannot be combined without simultaneous court orders in countries that won't cooperate."

Sovereignty by architecture moves that conversation from the legal slide into the technology slide. Which is where it belongs.

---

Published May 22, 2026 · Written by SkyeConnex Inc. · More from the SkyeConnex blog