Why Cloud KMS Isn't Enough for True Data Sovereignty (And How AltaStata Fixes It)

When companies move sensitive data to the cloud, they often rely on a Cloud Key Management Service (KMS) and Customer-Managed Keys (CMK) to maintain control. If the goal is to protect data from a cloud provider's rogue employee, a customer-owned key in a KMS helps. But if the goal is data sovereignty, it is an entirely different story.

Under regulations like the US CLOUD Act, global cloud providers can be compelled to hand over data and API access across borders. With standard KMS encryption, whoever has API access to the bucket and the key has access to all the files. For European companies bound by strict sovereignty requirements under the EU AI Act, Data Act, and DORA, unauthorized exposure to foreign jurisdictions constitutes a data breach.

The same catastrophic outcome occurs if a malicious insider or external attacker compromises a user's API credentials. In standard cloud architectures, an access token often grants the keys to the entire kingdom.

To achieve true data sovereignty, you need a system where holding cloud API access does not equal holding the data. AltaStata solves this by decoupling data security from cloud key management through a unique architectural approach.

1. Reducing the Blast Radius of Stolen Credentials

In standard cloud setups, data is often secured at the bucket level with static access groups. AltaStata shifts this by managing encryption keys per user rather than per bucket.

If an attacker manages to steal a user's access token, they do not gain access to the entire bucket. Because the encryption is tied to the individual user, the attacker only gains access to the specific subset of files that were explicitly shared with that user. This drastically reduces the "blast radius" (the extent of the damage caused by a security breach).

However, while this mitigates attacks from hackers, it does not fully protect against broad legal subpoenas or systemic provider-level compromises. For that, you need cloud-independent keys.

2. Cloud-Independent Keys (External HSMs & Private Keys)

To prevent cloud providers from being able to decrypt data—even under a legal mandate—the encryption keys must live outside the cloud's control.

AltaStata supports standard Cloud KMS, but it also natively supports external HSMs (like IBM Crypto Express) and Private Keys encrypted by a password. These keys are managed per user, and they are strictly independent of the cloud storage provider.

If a third party compels the cloud provider to hand over raw storage and API access tokens, the data remains mathematically locked. Without the external HSM or the user's password, anyone accessing the cloud infrastructure only possesses unbreakable ciphertext.

3. Two-Tier Encryption and The Multi-Cloud Split

How can we still use Cloud KMS while protecting data sovereignty?

AltaStata does not use the user's key to directly encrypt files. Instead, it uses a two-tier envelope encryption mechanism:

• Every file is encrypted using a unique AES-256 data key.

• This data key is stored within the file's metadata.

• That metadata is then encrypted by the user's private key or KMS key.

This specific architecture unlocks AltaStata's most powerful compliance feature: flexible data placement.

Because the metadata is cleanly separated from the bulk data chunks, an organization can store the encrypted file chunks on a highly scalable, cost-effective US cloud (like AWS or GCP), while storing the metadata on a sovereign European cloud.

Even if you use a global Cloud KMS to encrypt that metadata, true sovereignty is preserved. Why? Because the global cloud provider only holds the encryption keys and the bulk encrypted data chunks—but the metadata containing the AES-256 data keys resides entirely in a sovereign European cloud. If a foreign jurisdiction requests data from the global cloud provider, they receive the KMS keys and the encrypted chunks, but without the metadata from Europe, they have no way to connect the keys to the chunks or decrypt the payload. Organizations get all the benefits of massive global cloud infrastructure and native KMS without violating the EU AI Act, Data Act, or DORA.

4. Complete Data Lifecycle and Sharing Control

When Company A shares a dataset with Company B using standard cloud tools, Company A loses control over who inside Company B accesses it.

AltaStata fundamentally changes this by ensuring real, cryptographic access is granted per file, to specific users, and is fully trackable and revocable. You can even configure AltaStata to share a dataset only with a specific AI application running in a verified Confidential Container (with cryptographic attestation). This allows you to leverage third-party AI data centers for processing without ever losing sovereignty over your data.

AltaStata, KMS and Confidential Computing

Three technologies complement each other to provide a complete security lifecycle.

Component	What it Protects	What it Doesn't Protect	How it Fits In
Cloud KMS	Encryption keys and key operations.	Running code, memory, or fine-grained data policies.	Centralizes key management for authorized cloud services.
Confidential Computing	Application memory and code execution.	Data storage, lifecycle management, or external key policies.	Protects data while in use (even from cloud admins).
AltaStata	The entire data lifecycle: storage, access, sharing, and AI pipelines.	Does not replace the need for KMS or TEE.	Provides file-level encryption, access policies, secure sharing, and cloud independence.

The Bottom Line

True sovereignty means key sovereignty.

AltaStata decouples data security from the cloud provider's infrastructure. Whether you use a cloud KMS, your own independent HSM on-premises, or standalone private keys, AltaStata ensures your data protection architecture remains intact, portable, and entirely under your control.