AWS KMS EU Alternative 2026: Encryption Keys, CLOUD Act, and GDPR Compliance

Post #708 in the sota.io EU Compliance Series

AWS Key Management Service (KMS) is the encryption backbone of the AWS ecosystem. Every S3 bucket using server-side encryption, every RDS database with storage encryption, every Lambda environment variable marked "encrypted" uses KMS-managed keys. Your GDPR compliance checklist says "data encrypted at rest" — you point to KMS — and you check the box.

The problem is the box should not be checked.

AWS KMS manages encryption keys. AWS is a US corporation. The CLOUD Act (18 U.S.C. § 2713) compels US corporations to produce data — including cryptographic key material — stored anywhere in the world when served a valid US government order. If a US court orders AWS to produce the key that encrypts your EU customer data, AWS must comply. The data remains encrypted until it is decrypted with that key. With the key in hand, it is not.

This is not a theoretical risk. It is the stated, documented legal obligation of every US cloud provider. The encryption that GDPR Article 32 requires you to implement is being provided by a company that can be legally compelled to hand over the keys. This is not what Article 32 intended.

What AWS KMS Manages Under US Jurisdiction

Key Types and Where Key Material Resides

AWS KMS offers several key types, and the distinctions matter for a CLOUD Act analysis:

AWS Managed Keys are created automatically by AWS services (S3-SSE-KMS, RDS, EBS). The customer never sees the key material. AWS controls creation, rotation, and deletion. This is the default for many services. Under CLOUD Act, the key material is entirely in AWS's custody — there is no customer involvement in key production that a court order would need to navigate.

Customer Managed Keys (CMKs) are created by the customer in the KMS console or via API. The customer can define key policies, enable or disable rotation, and schedule deletion. However: the key material is generated by AWS's hardware security modules (HSMs) and never leaves AWS infrastructure unless the customer explicitly exports it (a rarely-used option). The customer controls the policy around the key, not the key material itself. Under CLOUD Act, the key material remains in AWS's custody.

Customer-Provided Key Material (BYOK) allows customers to import their own key material generated outside AWS. The marketing suggests this gives customers control. The reality: once imported into KMS, the key material is stored in AWS's HSMs. It is now in AWS's custody, subject to CLOUD Act. The fact that you generated the bytes before import does not change where the bytes live after import.

External Key Store (XKS) is AWS's most recent response to sovereignty concerns, allowing key material to reside in a customer-managed HSM outside AWS. This sounds like a genuine solution. Section below explains why it is not.

What KMS Logs Under US Jurisdiction

Every KMS API call generates a CloudTrail event (see the AWS CloudTrail EU Alternative post for the full problem). This means every encrypt and decrypt operation is logged with:

{
  "eventSource": "kms.amazonaws.com",
  "eventName": "Decrypt",
  "userIdentity": {
    "arn": "arn:aws:iam::123456789012:user/alice@company.com",
    "userName": "alice@company.com"
  },
  "sourceIPAddress": "203.0.113.42",
  "requestParameters": {
    "encryptionContext": {
      "customer_id": "eu-user-8847261",
      "resource_type": "health_record"
    }
  },
  "timestamp": "2026-04-29T09:14:22Z"
}

The encryption context field is particularly problematic: developers often put identifiers (user IDs, record types, resource names) in the encryption context to bind data to its cryptographic operation. That context appears in CloudTrail in plaintext. Under CLOUD Act, US authorities can see not just that a decryption occurred, but which EU customer's health record was decrypted, by whom, from which IP, at what time — without ever receiving the decrypted data.

Combined with the key material compulsion risk, this means US authorities could in principle reconstruct both the key operations (audit trail) and obtain the key material to access the underlying data. The CloudTrail and KMS problems compound each other.

The CLOUD Act Key Compulsion Problem

The Legal Mechanism

18 U.S.C. § 2713 reads: "A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States."

Key material stored in AWS HSMs is "within [AWS's] possession, custody, or control." The location of the HSM (Frankfurt, Ohio, Singapore) is legally irrelevant. The question is whether AWS — a US entity — controls the hardware. It does.

What a Key Compulsion Order Looks Like

A CLOUD Act order compelling key material production is a novel but legally grounded scenario. The US government does not necessarily need to request key material directly; it can also request:

1. The plaintext data directly — if it can compel AWS to decrypt and produce the data
2. The key material — if it needs to demonstrate technical capability or use the key against other data
3. The key usage logs (CloudTrail) — to establish what data was accessed and by whom, without decryption

For a GDPR-focused legal analysis, scenario 3 is often sufficient to establish a compliance breach: the US government has accessed personal data (the CloudTrail records of who accessed what encrypted resource) without a legal basis recognized by EU law.

The GDPR Standard for Encryption

GDPR Article 32(1)(a) requires "the pseudonymisation and encryption of personal data" as a measure to "ensure a level of security appropriate to the risk." The recitals clarify that "state of the art" measures must be applied (Recital 83). Article 32(2) requires assessment of "risks to the rights and freedoms of natural persons."

Using encryption with keys managed by a US entity that can be compelled to surrender those keys is not "state of the art" security for EU personal data. It is encryption with an accessible backdoor — one that is not available to hackers (good) but is available to US law enforcement (bad for GDPR compliance). GDPR compliance is not about protection from attackers; it is about protection of data subjects' rights against any unauthorized processing, including US government access.

BYOK Is Not a Solution

"Bring Your Own Key" is frequently marketed as the enterprise answer to KMS sovereignty concerns. The pitch: generate your key material in your own HSM, import it into KMS, and since you generated it, you maintain control.

The logical problem: once the key bytes are in AWS's system, AWS has them. The provenance of the bytes does not determine their legal jurisdiction — their custody does.

When you import key material into KMS:

1. You generate the key outside AWS (typically in an on-premises HSM)
2. You download an AWS-generated wrapping key (an RSA public key)
3. You encrypt your key material with the wrapping key
4. You upload the encrypted key material to AWS
5. AWS decrypts it with the corresponding private key (which AWS holds) and stores the plaintext key material in their HSMs

After step 5, the key material exists in AWS infrastructure. AWS has it. CLOUD Act applies.

If the original on-premises copy of the key material is deleted after import (common for security hygiene), AWS now holds the only copy. The customer has relinquished control.

Even if the customer retains the original copy, the AWS copy is in US jurisdiction. A CLOUD Act order can compel the AWS copy without the customer's knowledge or consent. GDPR requires data subjects to have rights over their data. A key compulsion that bypasses the customer entirely is incompatible with GDPR principles.

The External Key Store Gap

AWS introduced the External Key Store (XKS) in 2022 in direct response to EU sovereignty requirements. The concept: key material never enters AWS infrastructure. Instead, AWS sends cryptographic requests to a customer-managed XKS proxy, which performs encrypt/decrypt operations using keys in a customer-controlled HSM.

This sounds like a genuine solution. Several structural problems remain:

1. The Proxy Is an AWS-Reachable Endpoint

The XKS proxy must be network-accessible to AWS. Customers can deploy it in their own data center or VPC — but it must accept connections from AWS KMS. This creates a critical dependency: AWS's control plane must be able to reach the proxy that holds the key material.

If AWS is served a CLOUD Act order to facilitate access to specific encrypted data, one legal theory is that AWS could be compelled to send crafted decrypt requests to the XKS proxy through the existing authorized channel. The XKS proxy cannot distinguish a CLOUD Act-compelled AWS request from a legitimate one.

2. Key Policy Is Still in AWS

Even with XKS, the key policy (who can use the key, under what conditions) lives in AWS KMS. A CLOUD Act order could compel AWS to modify the key policy to grant access to a government-controlled principal — before the customer is notified, if a gag order accompanies the request.

3. Latency and Reliability Dependency

XKS introduces a synchronous network call to the customer's proxy on every cryptographic operation. Operational data (what data was decrypted, when, by which service) still flows through AWS CloudTrail. The audit trail of key usage remains under US jurisdiction even when the key material does not.

4. Encryption Context Leak

The encryption context sent to the XKS proxy for each operation passes through AWS's control plane. This means AWS can observe what context was bound to which cryptographic operation without possessing the key material. For CloudTrail logging purposes, this data is already captured in the AWS-managed audit trail.

XKS is a genuine architectural improvement. It is not a GDPR compliance solution for data subjects' rights against US government access.

AWS Nitro Enclaves: Claims vs. Reality

AWS markets Nitro Enclaves as isolated compute environments where "nobody can access data, not even AWS." This claim deserves scrutiny.

What Nitro Enclaves actually provide:

• Isolated virtual CPU and memory with no network access, no persistent storage, no SSH
• Cryptographic attestation that the enclave is running specific code on specific hardware
• Integration with KMS so the enclave can request decryption of data that was encrypted specifically for this attested enclave

The CLOUD Act problem: The attestation document that proves "this is the code I expected, running on this hardware" is signed by AWS Nitro Attestation PKI — AWS's own certificate authority. The trust root is a US company. AWS controls which enclaves receive attestation certificates.

Under CLOUD Act, AWS could potentially be compelled to:

1. Issue an attestation certificate for a modified enclave (one that the government controls)
2. Allow KMS to decrypt data for that attested-but-modified enclave
3. Route the decrypted data to government servers

This is not a straightforward technical attack. It would require AWS cooperation. Under CLOUD Act, AWS cooperation with US government orders is legally mandatory. The Nitro attestation chain does not eliminate the US-entity trust problem — it concentrates it.

Who Is Affected

SaaS Developers on AWS (Most Affected)

If your SaaS stores EU customer data encrypted with AWS KMS keys, every customer's data is protected by keys under US jurisdiction. Your Art.30 Record of Processing Activities should document this — and your DPA with EU customers should disclose it. Most do not.

Regulated Industries

Healthcare (patient data under GDPR Art. 9), financial services (payment data under PSD2 and GDPR), and legal services (attorney-client privilege data) face the highest risk. Regulators in these sectors increasingly require demonstrated sovereignty over encryption keys, not just encryption existence.

Multi-Tenant SaaS Architectures

Many SaaS providers use per-customer CMKs in KMS (one key per customer tenant). This is a good security practice, but each customer's key is still in AWS's custody. A CLOUD Act order for one customer's key does not affect other customers' keys — but the provider cannot guarantee to any customer that their key is beyond US government reach.

EU-Native Encryption Key Management Alternatives

HashiCorp Vault (Self-Hosted)

The most widely deployed EU-sovereign KMS alternative. Vault can run on any EU infrastructure (Hetzner, OVH, Scaleway) and provides:

• Transit Secrets Engine: Encrypt/decrypt API equivalent to KMS, with keys managed in Vault (never exported)
• Key/Value Secrets: Stores API keys, database passwords, certificates
• PKI Engine: Certificate authority functionality
• AWS Secrets Engine: Dynamic AWS credentials (eliminates long-lived IAM keys)
• Auto-unseal with HSM: Integrate with EU-based HSMs (Thales Luna, Utimaco) for key material protection

When Vault runs on EU infrastructure owned by an EU entity, all key material is under EU jurisdiction. CLOUD Act does not apply to the Vault operator unless the operator is a US entity or the infrastructure is contracted from a US company.

# Vault Transit configuration — EU jurisdiction, Art.32-compliant
resource "vault_mount" "transit" {
  path                      = "transit"
  type                      = "transit"
  default_lease_ttl_seconds = 3600
  max_lease_ttl_seconds     = 86400
}

resource "vault_transit_secret_backend_key" "customer_data" {
  backend          = vault_mount.transit.path
  name             = "customer-data-key"
  type             = "aes256-gcm96"
  deletion_allowed = false
  exportable       = false
  allow_plaintext_backup = false
}

Vault deployed on Hetzner (Germany) by an EU-incorporated operator falls outside US CLOUD Act jurisdiction. The key material never leaves EU-controlled infrastructure.

OVHcloud Key Management Service

OVHcloud, a French company headquartered in Roubaix, launched a managed KMS offering in 2024. Key properties:

• Operated by OVH SAS (French entity, not a US subsidiary)
• HSMs physically located in France and Germany
• API compatible with AWS KMS for common operations
• Not subject to CLOUD Act (OVHcloud is not a US company)
• GDPR DPA with French law governing data processing

For teams migrating from AWS KMS who need a drop-in replacement with minimal code changes, OVHcloud KMS is the closest architectural equivalent under EU jurisdiction.

Scaleway Secret Manager

Scaleway (French company, subsidiary of Iliad Group) offers Secret Manager for storing credentials and encryption keys. The service is operated from Scaleway's data centers in Paris and Amsterdam.

Scaleway is not a US entity and is not subject to CLOUD Act. For applications requiring secret storage rather than high-volume encryption operations (KMS Transit-style), Scaleway Secret Manager provides GDPR-compliant secret storage.

Infisical (Self-Hosted EU)

Infisical is an open-source secrets manager with a UI similar to AWS Secrets Manager but also supporting encryption key workflows. Self-hosted on EU infrastructure, it provides:

• Per-environment secret management with audit logging
• Secret rotation built in
• SDK support for most application frameworks
• Full EU jurisdiction when self-hosted on EU infra

Hardware Security Modules (Physical EU Control)

For the highest assurance requirements, EU-based HSMs operated by the customer provide key material that cannot be compelled remotely:

• Thales Luna Network HSM — available through EU data center operators including Hetzner, T-Systems, Deutsche Telekom
• Utimaco HSMs — German manufacturer, HSMaaS offering from German data centers
• Yubico YubiHSM 2 — low-cost HSM for smaller workloads, operated by the customer

Physical HSMs in customer custody in EU jurisdiction represent the strongest GDPR Art.32 argument: key material cannot be compelled via US law without a physical seizure of the device (which would be an EU legal process, not a US one).

How sota.io Handles Encryption Key Management

sota.io is a European PaaS (Platform as a Service) built for EU sovereignty compliance. Our approach to encryption key management:

No AWS KMS dependency. The sota.io platform does not use AWS infrastructure. No key material is stored in AWS's HSMs or subject to CLOUD Act.

EU-infrastructure encryption. Encryption at rest uses keys managed through EU-based key management that falls outside US jurisdiction.

Customer environment isolation. Each customer deployment runs in an isolated environment with its own encryption context. No multi-tenant key reuse that would create cross-customer risk.

GDPR Art.32 documentation. Our Data Processing Agreement (DPA) documents the encryption measures and their jurisdictional basis — what DPOs need for their Art.30 Record of Processing Activities.

For teams building GDPR-sensitive applications, sota.io eliminates the KMS sovereignty problem at the infrastructure layer rather than requiring application-level workarounds.

GDPR Implications Summary

Migration Path: From AWS KMS to EU Key Management

Step 1: Inventory KMS-encrypted resources

# List all CMKs in all regions
aws kms list-keys --region eu-central-1 --query 'Keys[*].KeyId'

# For each key, find what's encrypted with it
aws kms list-resource-tags --key-id <key-id>

Step 2: Categorize data sensitivity

• Identify which KMS keys protect GDPR-relevant data (personal data, special category data)
• Map which AWS resources (S3 buckets, RDS instances, EBS volumes) use these keys
• Prioritize keys protecting Art.9 special category data (health, biometrics, religion)

Step 3: Choose EU key management target

• For managed convenience: OVHcloud KMS (API compatible, EU jurisdiction)
• For full control: HashiCorp Vault self-hosted on EU infra
• For high assurance: Physical HSM in EU customer facility

Step 4: Re-encrypt data under EU keys

• S3: Copy objects with new SSE configuration (KMS → customer managed EU key)
• RDS: Snapshot → copy with new encryption key → restore
• EBS: Snapshot → copy with new encryption key → attach

Step 5: Retire AWS keys

• Schedule AWS CMK deletion (minimum 7-day waiting period)
• Update Art.30 RoPA to reflect EU-jurisdiction key management
• Update DPA with customers to remove KMS-related disclosures

See Also

• AWS S3 EU Alternative — Where KMS-encrypted data is stored
• AWS CloudTrail EU Alternative — Where KMS key usage events are logged
• AWS Secrets Manager EU Alternative — Companion service for secret storage alongside KMS
• AWS IAM EU Alternative — Who can authorize KMS key use
• AWS RDS EU Alternative — Databases encrypted with KMS keys