Storage that answers to your laws, not your provider's.

What "sovereign" actually means in cloud storage

"Sovereign cloud storage" is a category that emerged in response to legal-process exposure of foreign-controlled cloud providers. The CLOUD Act (2018) made the issue concrete: any US-controlled cloud provider can be compelled by US law-enforcement to surrender customer data — regardless of where the data physically sits. The UK's Investigatory Powers Act, China's National Intelligence Law, and similar provisions create equivalent exposure for providers under those jurisdictions.

For data that the customer cannot afford to expose to a foreign authority — regulated personal information, intellectual property, defence-related records, financial-market activity, government correspondence — the architecture has to enforce sovereignty at the data layer. Region selection within a foreign-controlled hyperscaler does not do this. Customer-managed keys in the provider's KMS do not do this. Only architectures where the storage operator structurally cannot read the data deliver real sovereignty.

The three components of sovereign cloud storage

1. Zero-knowledge key management

The wrap key is derived on the customer device, never reaches the cloud operator in unwrapped form. The operator has no API path that returns plaintext. A subpoena to the operator yields metadata and ciphertext — not plaintext, because plaintext does not exist server-side.

2. Multi-cloud erasure coding

Single-provider sovereignty is structurally fragile — if the provider goes down, gets compromised, or gets compelled, the data is at risk. Reed-Solomon erasure coding across multiple providers means no single provider holds enough of any file to read it; up to two providers can be lost without affecting availability or data loss.

3. Jurisdictional policy enforcement

Allow-list, block-list, or strict-mode geo-policy applied at upload. The policy cascades through reseller, company, and account levels. Per-file evidence of residency is exportable as signed JSON, verifiable offline.

How SkyeConnex maps to each

The cryptographic stack is FIPS-published end-to-end: AES-256-GCM frame encryption, AES Key Wrap, ML-KEM-1024 hybrid post-quantum key wrap on the Sovereign tier, ML-DSA-87 post-quantum signatures. No proprietary algorithms. The certification path (FIPS 140-3, Common Criteria, FedRAMP) compresses from years to months as a result.

The storage substrate uses RS(5,2)">Reed-Solomon RS(5,2): five data shards plus two parity, distributed across seven providers from the customer's connexion set. Fourteen plugins ship out of the box; customers can integrate a sovereign or regional provider not in the catalogue in under 500 lines of code.

The geo-policy engine enforces customer-chosen jurisdictions at four boundaries: pre-flight (before client upload), gateway (re-checked at SigV4 hand-off), mid-upload (re-checked during long transfers), and tier-gate (auth fails below the required tier). Failures surface as deep-linked remediation banners.

What this looks like in practice

A Canadian healthcare organisation operating under PIPEDA, PHIPA, and HIPAA configures the allow-list to admit Canadian-resident providers only — AWS ca-central-1, Azure canadacentral, OVH Beauharnois, Backblaze Canadian, on-prem MinIO, plus two sovereign endpoints. Every patient record uploaded is encrypted client-side, framed into ~5 MB chunks, Reed-Solomon split into seven shards, and scattered across the seven providers. The SkyeMap shows per-record residency in real time.

A US National Security Letter served on AWS yields ciphertext fragments for 2/7 of the shards — not enough to reconstruct, and even if combined with the other five providers' shards, the AES-256-GCM key never left the customer device. The PIPEDA / PHIPA / HIPAA exposure that hyperscaler regional storage cannot solve is solved here by topology and cryptography.

The procurement test

Ask any sovereign-cloud candidate: "If a foreign court ordered you to decrypt a specific customer's data tomorrow, what would happen?" The honest answer from most candidates involves "we would resist, then comply if forced." The honest answer from SkyeConnex is "we literally cannot decrypt — the capability does not exist server-side." That distinction is the sovereignty architecture.