AWS Secrets Manager EU Alternative 2026: API Keys, Database Passwords, and CLOUD Act Jurisdiction

Post #690 in the sota.io EU Compliance Series

AWS Secrets Manager is where modern cloud infrastructure stores its most sensitive operational data: database connection strings, API keys for third-party services, TLS private keys, OAuth client secrets, and SSH credentials. For every AWS workload that connects to a database, calls an external API, or authenticates to another service, Secrets Manager is often the credential distribution layer that makes those connections possible.

The GDPR compliance concern with Secrets Manager goes beyond data residency. The secrets themselves are not personal data in the traditional sense — they are credentials, not customer records. But the combination of what secrets enable, how Secrets Manager is integrated into AWS infrastructure, and what the CLOUD Act means in this context creates a specific risk that most organizations underestimate: forced disclosure of secrets under US jurisdiction is equivalent to forced access to every system those secrets protect.

This article examines what AWS Secrets Manager stores, how CLOUD Act compelled disclosure interacts with GDPR obligations, and what EU-native alternatives exist for organizations that need secrets management without US-entity control over their infrastructure credentials.

What AWS Secrets Manager Stores and Processes

AWS Secrets Manager is a regional service — secrets are stored in the AWS region you specify. A secret stored in eu-central-1 (Frankfurt) has its encrypted value residing on AWS infrastructure in Germany. AWS uses AWS KMS to encrypt secrets at rest, with the encryption key under your KMS configuration (or AWS-managed defaults). This provides a degree of data sovereignty at the storage layer.

However, several dimensions of Secrets Manager operation extend beyond the encrypted value storage:

The Secrets Manager control plane is a US entity. AWS Secrets Manager is a service of Amazon Web Services, Inc., a US corporation. Regardless of which region stores your secret's encrypted value, the service itself — its APIs, control plane, service team, and legal entity — is under US jurisdiction. A CLOUD Act compelled disclosure request does not target a specific AWS region; it targets Amazon Web Services, Inc. as an entity. AWS is legally compelled to respond if it can access the data — and as the KMS key manager for most deployments, it can.

Secret rotation via AWS Lambda. Secrets Manager's native rotation feature works by invoking a Lambda function on a schedule. The Lambda function retrieves the current secret value, generates a new credential, updates the target system (an RDS database password, an IAM user access key), and stores the new value back in Secrets Manager. This rotation pipeline involves: the Lambda function code, the Lambda execution role (an IAM identity), the function's execution environment, and the Lambda invocation logs in CloudWatch. The entire rotation mechanism operates under US-jurisdiction Lambda and CloudWatch infrastructure.

CloudTrail Secrets Manager events. Every Secrets Manager API call generates a CloudTrail event: secretsmanager:GetSecretValue, secretsmanager:CreateSecret, secretsmanager:RotateSecret, secretsmanager:DeleteSecret, secretsmanager:PutSecretValue. CloudTrail records the IAM principal making each call, the source IP, the secret ARN, and the timestamp. The access log for your secrets — which service retrieved which credential at what time — is recorded under AWS CloudTrail infrastructure.

Cross-account and cross-region replication. Secrets Manager supports replicating secrets to additional AWS regions. Replication creates additional copies of your encrypted secret values in each replica region, all under the same AWS-entity control. Cross-account secret sharing via resource policies allows other AWS accounts to retrieve your secrets — access patterns that are logged but not bounded to a specific region's infrastructure.

AWS Parameter Store as a complement. Many organizations use AWS Systems Manager Parameter Store alongside Secrets Manager — Parameter Store for non-sensitive configuration, Secrets Manager for credentials. Parameter Store is also a US-entity service. Organizations that believe migrating Secrets Manager eliminates their AWS secrets exposure often find that their Parameter Store usage has its own jurisdictional profile.

The CLOUD Act Secrets Problem

Most GDPR analyses of secrets management focus on whether secrets themselves contain personal data. That framing misses the central issue.

Secrets are keys, not data. A database password stored in Secrets Manager does not contain personal data — it is a 32-character random string. But that string grants access to a database containing millions of customer records. Under CLOUD Act compelled disclosure, a US government agency that obtains the database password from Secrets Manager has effectively obtained access to all customer records that database stores. The credential is the access vector.

GDPR Art.32 and appropriate technical measures. GDPR Art.32 requires controllers and processors to implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk. This includes protection against unauthorized access to personal data. If your secrets — the credentials that protect personal data — are stored under US jurisdiction, and a US government agency can compel disclosure of those credentials, then your Art.32 measures have a structural gap. The CLOUD Act can nullify your technical controls at the credential layer.

CLOUD Act jurisdiction follows the company, not the data. This is the point that AWS's EU region marketing frequently glosses over. AWS Secrets Manager encrypts your secret in Frankfurt. The KMS key used for that encryption is managed by AWS KMS, a service of Amazon Web Services, Inc. Amazon Web Services, Inc. is a US corporation subject to the CLOUD Act. A CLOUD Act request for the KMS key used to decrypt your Frankfurt secrets reaches Amazon Web Services, Inc. — not Frankfurt. AWS can technically comply with that request regardless of which region your data is stored in, because AWS controls the KMS keys.

GDPR Art.46 and compelled third-country disclosure. The Court of Justice of the EU (CJEU) in the Schrems II decision (C-311/18) found that FISA 702 surveillance programs made EU-US data transfers structurally problematic because EU data subjects had no effective legal remedy against US government access. CLOUD Act requests — which can compel US cloud providers to disclose data stored anywhere — create the same structural problem for data-at-rest. Using AWS KMS for secrets encryption when AWS is the key custodian creates an Art.46 transfer risk that storing secrets in Frankfurt does not eliminate.

GDPR Implications for Regulated Organizations

For organizations subject to enhanced scrutiny — financial services under DORA, healthcare under national health data laws, critical infrastructure under NIS2 — the Secrets Manager CLOUD Act exposure has specific compliance dimensions:

DORA Art.9: ICT security policies. The Digital Operational Resilience Act requires financial entities to maintain comprehensive ICT security policies covering "authentication and access management" and "cryptographic key management." DORA Art.9(3) explicitly addresses the security of credentials and access controls. Storing the credentials that protect financial system databases under US-jurisdiction key management creates a jurisdictional gap in your DORA Art.9 compliance posture. The European Banking Authority (EBA) guidelines for DORA implementation emphasize data sovereignty for financial entities.

NIS2 Art.21(2)(h): Access control policies. NIS2 requires essential and important entities to implement access control policies and asset management as part of their cybersecurity measures. Secrets are your access controls — they are the credentials that implement the logical separation between services. Storing secrets under US-entity control is a structural gap in your access control posture under NIS2.

CloudTrail access logs as GDPR-relevant data. The CloudTrail events recording which IAM principal accessed which secret at what time are themselves processing records. For organizations with privileged access management obligations — particularly financial services and healthcare — these access logs are audit evidence. Storing audit evidence under US-entity CloudTrail infrastructure creates a secondary GDPR exposure: the audit trail that proves your access controls work is under US jurisdiction.

EU-Native Secrets Management Alternatives

Option 1: HashiCorp Vault (Self-Hosted)

HashiCorp Vault is the open-source secrets management standard. Originally developed by HashiCorp (now IBM), Vault is released under the Business Source License (BSL 1.1) — the open-source Vault Community Edition supports all core secrets management capabilities. Organizations that require enterprise features (disaster recovery replication, namespace isolation, HSM seal integration) use Vault Enterprise.

Vault's secrets engine architecture covers the full range of secrets management use cases:

• KV Secrets Engine v2: General-purpose key-value store for static secrets (API keys, credentials). Full versioning with configurable retention.
• Database Secrets Engine: Dynamic secrets for PostgreSQL, MySQL, MongoDB, Oracle, MSSQL. Vault generates short-lived, unique database credentials per request and automatically revokes them on TTL expiry. No long-lived database passwords.
• PKI Secrets Engine: Internal certificate authority for issuing short-lived TLS certificates. Integrates with cert-manager for Kubernetes.
• AWS/GCP/Azure Secrets Engines: Vault can generate short-lived cloud provider credentials (AWS IAM temporary credentials, GCP service account tokens) on-demand. This eliminates static AWS credentials entirely.
• Transit Secrets Engine: Encryption as a service — Vault encrypts and decrypts data for your applications without exposing key material.
• SSH Secrets Engine: Dynamic SSH certificate issuance for short-lived, auditable server access.

Self-hosting Vault on EU infrastructure (Hetzner, Scaleway, OVHcloud, or sota.io) places all secrets under your control. No US-entity has access to your secrets or your secret access logs. Vault's audit log, stored on your infrastructure, provides the complete access trail.

Vault Agent and External Secrets Operator solve the "last mile" delivery problem for Kubernetes workloads: pods receive secrets as environment variables or mounted files via Vault Agent Sidecar or the External Secrets Operator, without any application code change required.

HA deployment example (Raft integrated storage):

# Vault HA cluster with integrated Raft storage
# values.yaml for Helm deployment on sota.io or Hetzner
server:
  ha:
    enabled: true
    replicas: 3
    raft:
      enabled: true
      setNodeId: true
  dataStorage:
    storageClass: hcloud-volumes  # Hetzner CSI
    size: 10Gi
  auditStorage:
    enabled: true
    size: 5Gi

ui:
  enabled: true
  serviceType: ClusterIP

injector:
  enabled: true  # Vault Agent Sidecar Injector

Dynamic database credentials — eliminating static DB passwords:

# Configure Vault database secrets engine for PostgreSQL
vault secrets enable database

vault write database/config/postgres-prod \
  plugin_name=postgresql-database-plugin \
  allowed_roles="app-read,app-write" \
  connection_url="postgresql://{{username}}:{{password}}@postgres.eu-internal:5432/prod" \
  username="vault-admin" \
  password="<vault-admin-password>"

# Create role — Vault generates credentials with 1h TTL
vault write database/roles/app-read \
  db_name=postgres-prod \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="4h"

# Application requests a credential — unique per request, auto-expiring
vault read database/creds/app-read
# Key                Value
# username           v-app-read-abc123
# password           A1B2C3D4-auto-generated
# lease_duration     1h

With dynamic secrets, there are no long-lived database passwords to steal. Compelled disclosure of a dynamic credential reveals a credential that expired hours ago.

Jurisdictional status: Self-hosted on EU infrastructure. Zero US-entity data exposure for both secret values and secret access logs.

Option 2: Infisical (Self-Hosted or Infisical Cloud EU)

Infisical is an open-source secrets manager (MIT licensed) that provides a developer-friendly alternative to HashiCorp Vault. Founded in 2022 (Y Combinator W23), Infisical offers both a self-hosted option and a managed cloud service with EU-region hosting.

Key Infisical capabilities:

• Secret versioning and point-in-time recovery
• Secret sharing and access policies (per environment, per project)
• Native integrations: GitHub Actions, GitLab CI, Vercel, Railway, Kubernetes External Secrets, Terraform
• Dynamic secrets for AWS, PostgreSQL, MySQL (subset of Vault's engine breadth)
• Secret scanning for detecting accidentally committed secrets
• Audit logs with per-user access tracking
• CLI and SDK (Go, Python, Node.js, Java)

Infisical Cloud EU hosts infrastructure in Frankfurt (AWS eu-central-1 via their cloud infrastructure). For organizations that want a managed service without self-hosting complexity, Infisical's EU offering is operationally simpler than Vault, though the underlying infrastructure still runs on AWS EU regions (rather than a fully EU-owned cloud). For complete US-entity independence, self-hosted Infisical on Hetzner or Scaleway is the right choice.

Self-hosted deployment:

# Docker Compose — self-hosted Infisical on Hetzner
git clone https://github.com/Infisical/infisical
cd infisical/docker-compose

# Configure .env
ENCRYPTION_KEY=$(openssl rand -hex 16)
AUTH_SECRET=$(openssl rand -hex 16)
MONGO_URL=mongodb://infisical:password@mongo:27017/infisical

docker compose up -d
# Infisical UI at https://your-domain.eu

Kubernetes External Secrets integration:

# External Secrets Operator + Infisical
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: infisical-backend
spec:
  provider:
    infisical:
      auth:
        universalAuthCredentials:
          clientId:
            secretRef:
              name: infisical-client-credentials
              key: clientId
          clientSecret:
            secretRef:
              name: infisical-client-credentials
              key: clientSecret
      hostAPI: https://secrets.yourdomain.eu/api  # self-hosted
      projectSlug: production-app
      environmentSlug: prod

Jurisdictional status: Self-hosted: user-controlled EU infrastructure. Infisical Cloud EU: AWS eu-central-1 (AWS infrastructure, but EU region). For full US-entity independence, self-hosted is required.

Option 3: External Secrets Operator + Any EU Backend

The External Secrets Operator (ESO) is a Kubernetes operator that synchronizes secrets from external backends into Kubernetes Secrets. ESO is backend-agnostic — it supports Vault, Infisical, Doppler, IBM Secrets Manager, Google Secret Manager, Azure Key Vault, and others. For Kubernetes workloads, ESO provides a uniform secrets delivery layer regardless of which backend stores the secrets.

For EU-jurisdiction deployments:

• ESO + Vault (self-hosted) = fully EU-controlled, full dynamic secrets capability
• ESO + Infisical (self-hosted) = EU-controlled, simpler operations
• ESO runs as a Kubernetes controller on your cluster — no US-entity involvement

ESO handles secret rotation transparently: when the backend secret changes, ESO automatically updates the Kubernetes Secret and optionally triggers pod restarts via annotation.

Option 4: SOPS + Age for GitOps Workflows

For organizations using GitOps with encrypted secrets in Git repositories, Mozilla SOPS (Secrets Operations) with age encryption provides a practical EU-native approach.

• SOPS encrypts YAML/JSON/ENV files in-place, committing encrypted secrets to Git
• age is a modern file encryption format (no key management server required)
• Decryption keys stored in Kubernetes Secrets, Vault, or HSM
• No server-side secrets management infrastructure — secrets are encrypted files in your Git repo

SOPS is particularly well-suited for Flux CD and ArgoCD GitOps workflows where secrets need to live close to their configuration but cannot be committed in plaintext.

# Encrypt a secret file with age
age-keygen -o key.txt
# Public key: age1xxx...

# Encrypt secrets file
sops --encrypt \
  --age age1xxx...,age1yyy... \
  --encrypted-regex '^(password|apiKey|connectionString)$' \
  secrets.yaml > secrets.enc.yaml

# Decrypt in CI/CD with private key
SOPS_AGE_KEY_FILE=key.txt sops --decrypt secrets.enc.yaml

SOPS with age requires no SaaS infrastructure — your secrets are encrypted files, your encryption keys are under your control, and no US-entity service is involved in encryption or decryption.

Comparison Table

Migration Strategy

Step 1: Inventory Your Secrets

Before migrating, understand what you are migrating and what depends on each secret:

# List all secrets and their last-accessed date
aws secretsmanager list-secrets \
  --query 'SecretList[*].[Name,LastAccessedDate,RotationEnabled]' \
  --output table --region eu-central-1

# Check which secrets have rotation enabled
aws secretsmanager list-secrets \
  --filter Key=rotation-enabled,Values=true \
  --query 'SecretList[*].[Name,RotationRules]' \
  --output json --region eu-central-1

Categorize secrets by type: database credentials, API keys, TLS private keys, OAuth client secrets. Database credentials with rotation enabled require the most careful migration planning.

Step 2: Deploy Vault on EU Infrastructure

For organizations migrating from Secrets Manager to self-hosted Vault:

# Install Vault via Helm on sota.io / Hetzner Kubernetes
helm repo add hashicorp https://helm.releases.hashicorp.com

helm install vault hashicorp/vault \
  --namespace vault \
  --create-namespace \
  -f vault-values.yaml

# Initialize and unseal (use auto-unseal in production)
kubectl exec -n vault vault-0 -- vault operator init \
  -key-shares=5 \
  -key-threshold=3 \
  -format=json > vault-init.json

# Store unseal keys in a secure offline location — NOT in Secrets Manager

For production, configure Vault auto-unseal with an HSM or cloud KMS hosted in the EU (e.g., Thales nShield, AWS KMS eu-central-1 as a bootstrap only, or PKCS#11 with an EU-hosted HSM).

Step 3: Migrate Static Secrets

import boto3
import hvac

# Read from Secrets Manager
sm_client = boto3.client('secretsmanager', region_name='eu-central-1')
secrets = sm_client.list_secrets()

vault_client = hvac.Client(url='https://vault.yourdomain.eu', token=os.environ['VAULT_TOKEN'])

for secret in secrets['SecretList']:
    name = secret['Name']
    value = sm_client.get_secret_value(SecretId=name)
    
    # Write to Vault KV v2
    vault_client.secrets.kv.v2.create_or_update_secret(
        path=name,
        secret={'value': value.get('SecretString', value.get('SecretBinary'))}
    )
    print(f"Migrated: {name}")

Step 4: Replace Rotation with Vault Dynamic Secrets

For database secrets, the migration from Secrets Manager rotation (Lambda-based, static credentials) to Vault dynamic secrets (short-lived, unique per request) is a meaningful security improvement beyond just jurisdiction:

# Before: Secrets Manager stores a long-lived DB password
# Application: reads static password from Secrets Manager, reconnects rarely

# After: Vault issues dynamic credentials per connection pool initialization
# Application: requests fresh credential from Vault on startup
# TTL: 1 hour — credential auto-expires even if the application is compromised

This eliminates the entire category of "compromised long-lived database passwords" from your threat model.

Step 5: Update Applications with External Secrets Operator

For Kubernetes workloads, replace Secrets Manager CSI driver with External Secrets Operator pointing to your Vault:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: app-database-secret
    creationPolicy: Owner
  data:
    - secretKey: DATABASE_URL
      remoteRef:
        key: database/creds/app-read
        property: connection_url

ESO automatically refreshes the Kubernetes Secret when the Vault dynamic credential expires, optionally restarting pods to pick up the new credential.

What This Means Under CLOUD Act Risk Analysis

After migrating secrets to self-hosted Vault on EU infrastructure, your CLOUD Act exposure profile changes fundamentally:

Before (AWS Secrets Manager):

• Secrets stored: AWS eu-central-1 (Frankfurt), encrypted with AWS KMS
• Encryption key custodian: Amazon Web Services, Inc. (US entity)
• CLOUD Act risk: US government request to AWS can compel KMS key disclosure → secrets decryptable
• Secondary risk: CloudTrail access logs under AWS control reveal which systems accessed which secrets

After (Vault on EU infrastructure):

• Secrets stored: Your EU infrastructure (Hetzner/Scaleway/sota.io)
• Encryption key custodian: You (Vault auto-unseal key in EU-hosted HSM or PKCS#11)
• CLOUD Act risk: None — no US entity has custody of secrets or encryption keys
• Secondary risk: Vault audit log on your infrastructure → under your control

The GDPR Art.32 technical measures for access credential protection are structurally improved: the credentials that protect personal data are no longer accessible via US legal process.

Conclusion

AWS Secrets Manager provides excellent developer experience and deep AWS service integration, but its position as a US-entity service creates a structural CLOUD Act risk at the most sensitive layer of your infrastructure: the credentials that grant access to everything else. A compelled disclosure of secrets is a compelled disclosure of every system those secrets protect.

HashiCorp Vault self-hosted on EU infrastructure is the technically complete replacement: it matches and exceeds Secrets Manager's capabilities, adds dynamic secrets that eliminate long-lived credentials entirely, and operates entirely under your control. Infisical provides a more accessible alternative for teams that find Vault's operational complexity prohibitive. For Kubernetes workloads, the External Secrets Operator provides uniform secret delivery from any EU-hosted backend without application changes.

The AWS compliance picture for this series continues: secrets protect AWS IAM identities, enable connections to AWS RDS databases, authenticate calls to AWS SES for email delivery, and secure AWS Lambda environment variables. The secrets layer sits at the center of the CLOUD Act jurisdiction problem — it is both the most sensitive layer to expose and the one where migration delivers the broadest security improvement.