HashiCorp Vault Enterprise EU Alternative 2026: DevOps Secrets & CLOUD Act

Post #1258 in the sota.io EU Cyber Compliance Series — EU-SECRET-MGMT Serie #1/5

There is a category of SaaS risk that receives almost no attention in GDPR assessments: secrets management. Organizations carefully map which personal data flows to which US-jurisdiction SaaS platforms. They conduct transfer impact assessments, negotiate DPAs, and implement supplementary measures. Then they store their CI/CD pipeline secrets — the API keys that authenticate to every other service, the database passwords that grant production access, the TLS private keys that sign internal certificates — in HashiCorp Vault Enterprise, a product now owned by IBM Corporation, a New York C-Corp, via the HashiCorp Inc. Delaware C-Corp acquisition completed in 2023.

The practical implication is significant: under 18 U.S.C. § 2713 (the CLOUD Act), the US Department of Justice can compel disclosure of the master keys to an EU organization's entire production infrastructure. Not the data itself — the credentials that authenticate access to all of it.

HashiCorp, Inc. — Corporate and Jurisdictional Profile

HashiCorp was founded in 2012, incorporated as a Delaware C-Corp, and headquartered in San Francisco, California. The company went public on NASDAQ (HCP) in December 2021. In April 2023, IBM Corporation announced the acquisition of HashiCorp for approximately USD 6.4 billion. The acquisition closed in the third quarter of 2024.

IBM Corporation is incorporated in New York State and headquartered in Armonk, New York. IBM Federal, LLC — a wholly-owned subsidiary — holds extensive US federal contracts including FedRAMP authorizations across multiple IBM Cloud and IBM Security products.

Post-acquisition, HashiCorp Vault Enterprise (now marketed as HCP Vault Dedicated and HCP Vault Secrets under IBM ownership) operates under dual US jurisdiction: the original HashiCorp Inc. Delaware C-Corp entity and the IBM Corporation New York C-Corp parent. Both are subject to compelled disclosure obligations under the CLOUD Act.

The License Change Context: In August 2023, HashiCorp changed Vault's license from the Mozilla Public License 2.0 (MPL 2.0) to the Business Source License 1.1 (BUSL 1.1). This change — announced shortly before the IBM acquisition closed — restricted use of Vault code for competing SaaS products. The community response led to the creation of OpenBao, a Linux Foundation project that forked Vault at the MPL 2.0 codebase and continues development under a genuinely open license.

CLOUD Act Exposure Analysis: 18/25

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713) requires US-incorporated providers to comply with US government data requests regardless of where the data is physically stored. The law applies to any provider subject to US jurisdiction — including all subsidiaries of US corporations.

D1 — Unternehmens-Jurisdiction: 5/5

HashiCorp Inc. is a Delaware C-Corp. IBM Corporation is a New York C-Corp. Both entities are fully subject to US jurisdiction. The acquisition creates a dual-jurisdiction exposure: DOJ subpoenas can be directed at either entity. There is no EU subsidiary structure that would interrupt this chain. Score: 5/5.

D2 — Government Ties: 3/5

IBM has extensive US government relationships. IBM Federal, LLC holds FedRAMP High authorizations for IBM Cloud. IBM has active contracts across DoD, NSA, and civilian federal agencies. HashiCorp's own FedRAMP Moderate authorization (achieved in 2021 for HCP Vault on Government) predated the acquisition. Post-acquisition, these government relationships have merged under IBM's federal contracting umbrella. Score: 3/5.

D3 — Datensensitivität: 5/5

This is the critical dimension that distinguishes secrets management from other SaaS categories. Vault stores:

• CI/CD Pipeline Secrets: API keys, OAuth tokens, and service account credentials for every cloud provider, SaaS integration, and internal service in the organization's technology stack
• TLS Private Keys: Certificate authority private keys and leaf certificate private keys for internal PKI
• Database Credentials: Production database passwords, PostgreSQL connection strings, MySQL credentials, database admin accounts
• Cloud Provider Keys: AWS IAM access keys, Azure service principal secrets, GCP service account keys
• Application Secrets: Encryption keys, JWT signing secrets, webhook secrets, third-party API keys

A CLOUD Act subpoena against a Vault Enterprise tenant does not yield one data category. It yields the master authentication material for the organization's entire production environment. Score: 5/5.

D4 — EU-Datenlokation: 3/5

HashiCorp Cloud Platform (HCP) Vault offers EU deployment regions (AWS eu-central-1 Frankfurt, AWS eu-west-1 Ireland). Self-hosted Vault Enterprise can be deployed entirely within EU infrastructure with no HCP dependency. However, HCP Vault Secrets (the SaaS-native product) and the licensing/telemetry infrastructure for Vault Enterprise remain US-based. Organizations using HCP Vault Dedicated in EU regions benefit from physical data residency, but the governing entity remains a US corporation. Score: 3/5.

D5 — Encryption Sovereignty: 2/5

Vault Enterprise supports Auto Unseal via external KMS (AWS KMS, Azure Key Vault, GCP Cloud KMS, PKCS11 HSMs). BYOK scenarios are technically possible. However, when the Vault service itself is managed by HashiCorp/IBM (HCP Vault), the seal/unseal operations and the Vault cluster management plane are controlled by the US-jurisdiction provider. For self-hosted Vault Enterprise, encryption sovereignty is significantly higher — but requires operational capability that most organizations using Enterprise specifically to avoid. Score: 2/5.

Total CLOUD Act Score: 18/25 — High exposure for HCP Vault SaaS deployments. Moderate exposure for self-hosted Vault Enterprise where EU organizations control the infrastructure.

EU Regulatory Implications

NIS2 Article 21(2)(e): Security in Development

NIS2 Article 21(2)(e) requires covered entities to implement "security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure." The Article 21 implementation guidance from ENISA explicitly includes software supply chain security and development environment credentials as in-scope.

An EU organization under NIS2 whose CI/CD pipeline secrets are stored in a US-jurisdiction SaaS cannot demonstrate that its development environment security is free from third-party jurisdiction risk. During a NIS2 incident investigation, a national CSIRT requesting production credential access could find that the competent authority in the US has already obtained the same credentials via CLOUD Act process.

CRA Article 13: Build-Secrets and SBOM

The Cyber Resilience Act Article 13 establishes obligations for software manufacturers regarding build integrity and vulnerability management. CRA Article 13(6) requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements." The SBOM requirements intersect with secrets management: build credentials used to sign software components, repository access tokens used to pull dependencies, and registry credentials used to push container images are all within the scope of CRA Article 13 compliance.

If a manufacturer's build-time credentials are accessible to a foreign government under CLOUD Act jurisdiction, the integrity of the software supply chain documentation — and the signed artifacts themselves — is subject to a jurisdictional challenge that CRA does not explicitly address but implicitly creates.

DORA Article 9: ICT Security for Financial Entities

The Digital Operational Resilience Act Article 9 requires financial entities to implement ICT security measures covering "all information assets and ICT assets, including those supporting critical or important functions." API keys, database credentials, and service certificates for financial system integrations are unambiguously ICT assets under DORA's definition.

For financial entities subject to DORA, secrets stored in US-jurisdiction SaaS create a specific third-party ICT risk under DORA Article 28 (ICT third-party risk management). The provider assessment under DORA Article 30 must address the CLOUD Act exposure of the secrets management platform as part of the contractual risk analysis.

EU-Native Alternatives

OpenBao (Linux Foundation — 0/25 CLOUD Act Score)

OpenBao is a community fork of HashiCorp Vault, created in February 2024 following the BSL license change. Governance resides with the Linux Foundation, not a US corporation. OpenBao is functionally compatible with Vault's API (99%+ API compatibility for core features), supports the same auth methods (Kubernetes, AWS IAM, OIDC, AppRole), and maintains the same secrets engines (KV, PKI, Database, Transit).

For EU organizations currently using Vault, OpenBao offers the lowest migration friction: existing Vault configurations, policies, and client integrations work without modification. Deployed in EU infrastructure under EU organization control, OpenBao achieves 0/25 on CLOUD Act exposure — there is no US-jurisdiction entity in the chain.

Deployment: Kubernetes (official Helm chart), Docker, or bare-metal. Community support via Linux Foundation governance. Enterprise support from cloud-native MSPs in DE/NL/FR.

Infisical (Self-Hosted — 0/25 CLOUD Act Score when self-hosted)

Infisical is a secrets management platform launched in 2022 (YC W23 cohort). Infisical Inc. is a Delaware C-Corp, which creates CLOUD Act exposure for the Infisical Cloud SaaS offering. However, Infisical is fully open-source (MIT license) and provides an official self-hosted deployment path.

EU organizations deploying Infisical self-hosted on EU infrastructure under their own control achieve 0/25 CLOUD Act exposure — the Delaware C-Corp entity has no access to a self-hosted deployment. Infisical provides a developer-friendly API, native GitHub Actions and GitLab CI integration, dynamic secrets for PostgreSQL/MySQL/MongoDB, and a Vault migration tool.

Key Advantage over OpenBao: Infisical has a modern web UI with team management, access requests, and approval workflows — features that Vault OSS lacks and that typically require Vault Enterprise licensing.

Bitwarden Secrets Manager (Self-Hosted — 0/25 CLOUD Act Score when self-hosted)

Bitwarden, Inc. is a US corporation, but Bitwarden's source code is fully open-source (AGPL-3.0 / GPL-3.0). The Bitwarden Secrets Manager product (launched 2023) offers machine secrets management alongside the password manager. Self-hosted deployment on EU infrastructure achieves 0/25 CLOUD Act exposure.

For organizations already using Bitwarden for password management, Secrets Manager integration provides a unified credential management platform without additional vendor relationships.

Akeyless Vault Platform (Israeli Origin, EU Deployment Options)

Akeyless is incorporated in Israel with US operations. It is not a US C-Corp in the Delaware/New York sense, which creates a different (but not zero) jurisdictional profile. Akeyless offers SaaS deployment with EU region options and a Distributed Fragments Cryptography (DFC) architecture where master keys are cryptographically split. For organizations requiring commercial SaaS support with reduced CLOUD Act exposure, Akeyless is a credible option — though the jurisdictional analysis is complex due to the Israel-US relationship under MLAT and intelligence-sharing agreements.

Migration Path: Vault Enterprise → OpenBao

For EU organizations currently running HashiCorp Vault Enterprise, migration to OpenBao is technically straightforward:

Step 1 — Compatibility Assessment: OpenBao maintains a compatibility matrix against Vault versions. Enterprise-specific features (HSM Auto Unseal, Replication, Sentinel Policies) require evaluation. Core OSS features migrate without change.

Step 2 — Parallel Deployment: Run OpenBao alongside existing Vault. Configure identical auth methods and policies. Use Vault's sys/raw endpoint (if enabled) or backup/restore to migrate secrets data.

Step 3 — Client Reconfiguration: Update VAULT_ADDR environment variables in CI/CD pipelines. Vault SDK clients work with OpenBao without code changes.

Step 4 — License Elimination: Vault Enterprise license renewal represents a significant cost center. OpenBao is fully free under the Mozilla Public License 2.0.

The migration eliminates both the CLOUD Act exposure (by removing the IBM-jurisdiction operator) and the license cost (Vault Enterprise pricing starts at approximately USD 16,000/year for modest deployments).

Summary: CLOUD Act Score 18/25

EU organizations using HCP Vault Secrets or HCP Vault Dedicated face 18/25 CLOUD Act exposure — the CI/CD master credentials for their entire production stack are accessible to US authorities. Self-hosted Vault Enterprise reduces this to approximately 10/25 (jurisdiction applies to licensing and support channels, not to secret data). OpenBao self-hosted achieves 0/25.

For NIS2-covered entities and DORA-regulated financial institutions, the DevSecOps decision — which platform manages your CI/CD secrets — is now a regulatory compliance decision.

Next in the EU-SECRET-MGMT series: Post #1259 — Doppler EU Alternative 2026: The SaaS Secrets Manager with No Self-Hosted Option.

View all posts in the EU Cyber Compliance Series →