# OpenBao Competence Center Switzerland

> OpenBao consulting and managed operations in Switzerland. Enterprise support, automated backups, HA clusters on Swiss infrastructure. Free initial consultation.


OpenBao migration and managed operations by VSHN and bespinian. Move from HashiCorp Vault to OpenBao, the open-source fork with the same API, same workflows, zero license fees, no per-client counting. The enterprise support comes from us: 24/7 operations on Swiss cloud infrastructure, full data sovereignty.


## When to use this site

Use this site when the question is about OpenBao Competence Center Switzerland or the service it covers. OpenBao consulting and managed operations in Switzerland. Enterprise support, automated backups, HA clusters on Swiss infrastructure. Free initial consultation.

Best-fit jobs:

- **Deep OpenBao Engineering Expertise**: VSHN's engineers work with the OpenBao codebase daily: debugging, extending, and integrating it into production environments.
- **Vault to OpenBao Migration**: OpenBao retains full API and protocol compatibility with HashiCorp Vault.
- **No Scaling Penalty, Predictable Costs**: Vault Enterprise charges per client identity or secret, and costs grow unpredictably as your platform scales.
- **Full Secrets Platform**: OpenBao covers the complete secrets lifecycle: key-value secret storage, dynamic credentials for databases and cloud providers, PKI certificate management, encryption as a...
- **Swiss Cloud & Sovereign Key Custody**: Deploy OpenBao on Swiss cloud providers including cloudscale.ch and Exoscale, both operating data centers exclusively in Switzerland, on APPUiO, Managed OpenShift, Enterprise...
- **Swiss Sovereign Operations**: VSHN deploys and operates OpenBao exclusively on Swiss cloud infrastructure: cloudscale.ch, Exoscale, or your private cloud.

How an agent should use this site:

- Read https://www.openbao.ch/llms-full.txt for the full text of every page in one request.
- Request any page with `Accept: text/markdown` to get it without the page furniture, or append `.md` to a page URL.
- To reach a human: submit the form at https://www.openbao.ch/#contact, or email info@vshn.ch, or call +41 44 545 53 00.
- To book a call directly: https://vshn.cal.vs.hn/openbao

Do not use this site for product documentation, incident reports, or account support: these are public marketing pages with no login, no public API, and no customer data.

## Pages

- [Homepage](https://www.openbao.ch/): OpenBao Experts Switzerland – Secrets Management | VSHN
- [OpenBao vs Vault vs Infisical: Platform Comparison](https://www.openbao.ch/comparison.md)
- [OpenBao and CIS Controls - Secrets Management Compliance | VSHN](https://www.openbao.ch/compliance.md)
- [Partner with VSHN on OpenBao | VSHN](https://www.openbao.ch/partners.md)
- [OpenBao Sovereignty: Swiss Secrets Hosting | VSHN](https://www.openbao.ch/sovereignty.md)
- [What is OpenBao? Secrets Management and the Vault Fork](https://www.openbao.ch/what-is-openbao.md)

## Features

- **Deep OpenBao Engineering Expertise**: VSHN's engineers work with the OpenBao codebase daily: debugging, extending, and integrating it into production environments. We follow the Linux Foundation community closely and understand the platform at the source code level. Your consulting and managed service is backed by engineers who read the code, not just the documentation.

- **Vault to OpenBao Migration**: OpenBao retains full API and protocol compatibility with HashiCorp Vault. Existing clients, integrations, and Terraform providers work without code changes. VSHN helps you plan and execute the migration from Vault to OpenBao, including secrets engine configuration, policy migration, and integration testing. Your investment in Vault automation is preserved.

- **No Scaling Penalty, Predictable Costs**: Vault Enterprise charges per client identity or secret, and costs grow unpredictably as your platform scales. OpenBao has no per-client fees, no per-secret metering, and no feature gates. VSHN consulting is billed at CHF 250 per hour with no ongoing license cost. Your costs stay flat regardless of how many applications consume secrets.

- **Full Secrets Platform**: OpenBao covers the complete secrets lifecycle: key-value secret storage, dynamic credentials for databases and cloud providers, PKI certificate management, encryption as a service, identity-based access control, automated lease management with expiration and renewal, TOTP generation, and SSH certificate signing. One platform replaces multiple point solutions.

- **Swiss Cloud & Sovereign Key Custody**: Deploy OpenBao on Swiss cloud providers including cloudscale.ch and Exoscale, both operating data centers exclusively in Switzerland, on APPUiO, Managed OpenShift, Enterprise Private Cloud, or your own on-premises infrastructure. VSHN is Swiss-owned with no foreign parent company. All contracts are governed by Swiss law with no exposure to the US CLOUD Act. Your secrets stay in the jurisdiction you choose. HSM access goes through PKCS#11, a standard interface rather than a vendor-specific integration, with per-vendor guides including the Swiss Securosys Primus. The same capability requires Vault Enterprise at HashiCorp. Learn more in our [sovereignty assessment](/sovereignty/).

- **Swiss Sovereign Operations**: VSHN deploys and operates OpenBao exclusively on Swiss cloud infrastructure: cloudscale.ch, Exoscale, or your private cloud. No US-jurisdiction hyperscaler involved. Combined with 24/7 operations, encrypted storage, and strict access controls, this provides end-to-end sovereign secrets management that support-only vendors cannot offer.

- **Open Source: Drop-in, Walk Away**: OpenBao is licensed under MPL 2.0, maintained by the Linux Foundation. No proprietary extensions, no relicensing risk, no vendor lock-in. If you stop working with VSHN tomorrow, your OpenBao deployment keeps running unchanged, with zero migrations and zero infrastructure changes. Unlike Vault Enterprise, every feature is available to every user regardless of subscription tier.

- **Beyond a Support Subscription**: Some vendors sell phone support for your self-managed OpenBao. VSHN goes further: we architect, deploy, and operate OpenBao on your infrastructure with HA clustering, automated backups, monitoring, and 24/7 incident response. A fully managed OpenBao service on the VSHN Application Catalog is in development. Contact us for early access.


## What our OpenBao consulting includes

- Architecture design and deployment planning for OpenBao
- HashiCorp Vault to OpenBao migration: secrets, policies, auth methods
- High-availability configuration with three replicas and auto-unseal
- Encrypted storage and strict access controls for sovereign key management
- Integration with CI/CD pipelines, Kubernetes, and identity providers
- Deployment on cloudscale.ch, Exoscale, APPUiO, Managed OpenShift, Enterprise Private Cloud, or on-premises
- Ongoing 24/7 operational support and incident response
- Direct access to VSHN and bespinian engineers with deep OpenBao expertise
- Written scope and cost estimate in CHF within one business day

## OpenBao FAQ

### What is OpenBao?

[OpenBao](/what-is-openbao/) is an open-source secrets management solution hosted by the Linux Foundation. It is a community-driven fork of HashiCorp Vault, created in response to the license change from MPL to BSL. OpenBao provides identity-based secrets management, encryption services, dynamic credentials, PKI certificate management, and secure key-value storage. It retains full API compatibility with Vault, so existing integrations, tooling, and workflows continue to work without modification.


### We use GitLab. Should we wait for GitLab Secrets Manager?

GitLab built its own Secrets Manager on OpenBao and released it in public beta in August 2026, which is a strong signal about where the ecosystem is heading. Two things decide whether waiting makes sense for you. First, it ships as a cloud-native component: on self-managed GitLab it runs on a Kubernetes cluster with its own PostgreSQL database, TLS endpoint, key custody, and backup, so the operational work does not disappear. Second, it holds credentials for GitLab pipelines, while most organizations also need secrets for applications, databases, and infrastructure outside CI. A dedicated OpenBao instance covers both, and your GitLab jobs reach it with CI ID tokens over OIDC. VSHN operates it for you on Swiss infrastructure.


### How does OpenBao compare to HashiCorp Vault?

OpenBao is [a direct fork of HashiCorp Vault](/comparison/), maintaining full API and protocol compatibility. The key difference is licensing: OpenBao uses the MPL 2.0 open-source license while Vault moved to the Business Source License. Vault Enterprise charges per client identity or managed secret, creating unpredictable costs as you scale. OpenBao has no per-client fees, no feature gates, and no metering. OpenBao is governed by the Linux Foundation, ensuring community-driven development. Existing Vault clients, integrations, and Terraform providers work with OpenBao without code changes.


### How much does OpenBao cost compared to Vault Enterprise?

OpenBao itself is free, licensed under MPL 2.0 with no per-client or per-secret fees. [Vault Enterprise](/comparison/) typically charges based on client count, which grows unpredictably as your platform scales. VSHN consulting for OpenBao architecture, deployment, and migration is billed at CHF 250 per hour. For ongoing operations, VSHN provides 24/7 support and managed operations at predictable monthly rates without metering your secret count or client identities. You pay for operational expertise, not for how many applications consume secrets.


### What consulting services does VSHN offer for OpenBao?

VSHN provides end-to-end OpenBao consulting covering architecture design, deployment, Vault-to-OpenBao migration, high-availability configuration, and ongoing operational support. Our engineering partner bespinian brings deep Go and security expertise to the partnership. Engagements range from a one-day architecture review to multi-week implementation projects with 100 GB or more of secrets data.


### Does VSHN contribute to OpenBao development?

VSHN follows the OpenBao project closely and participates in the Linux Foundation community that governs it. Our engineers work with the OpenBao codebase daily: debugging, extending, and integrating it into customer environments. This deep familiarity means we can diagnose issues at the source code level, assess new releases for production readiness, and provide authoritative consulting based on hands-on experience rather than documentation alone.


### What is the difference between a support subscription and managed operations?

[A support subscription](/comparison/) gives you phone and ticket access when something breaks. You still architect, deploy, patch, and operate OpenBao yourself. VSHN managed operations goes further: we design the architecture, deploy HA clusters, configure auto-unseal, run automated backups, monitor health, and respond to incidents 24/7. If you stop working with us, your OpenBao deployment keeps running unchanged, with no migrations and no infrastructure changes.


### Can I run OpenBao on Swiss cloud infrastructure?

Yes. VSHN deploys OpenBao on Swiss cloud providers by default, including cloudscale.ch and Exoscale, both of which operate data centers exclusively in Switzerland. We also support deployment on APPUiO, Managed OpenShift, Enterprise Private Cloud, and on-premises infrastructure in your own data center. VSHN is Swiss-owned with no foreign parent company. All contracts are governed by Swiss law. See our [sovereignty assessment](/sovereignty/) for details.


### How does VSHN ensure sovereign key management?

VSHN deploys OpenBao on [Swiss](/sovereignty/) cloud infrastructure (cloudscale.ch, Exoscale, or your private cloud) with encrypted storage at rest, strict operator access controls, and audit logging. Auto-unseal is configured so OpenBao restarts without manual intervention. Because VSHN controls the full infrastructure stack, not just a support contract, we enforce operational boundaries that support-only vendors cannot provide.


### Is a managed OpenBao service available?

A fully managed OpenBao service on the VSHN Application Catalog is currently in development. Once available, it will include automated provisioning, backups, monitoring, and SLAs up to 99.99% availability, the same quality as our other managed database and application services. In the meantime, VSHN offers consulting, deployment, and full operational support for your own OpenBao installations. Contact us for early access to the managed service.


### How does VSHN handle Vault to OpenBao migration?

We plan the migration with you, covering secrets engine mapping, policy migration, authentication method configuration, and integration testing. Since OpenBao maintains full API compatibility with Vault, most clients and automation work without changes. We run parallel environments during the transition to ensure zero downtime and validate that all secrets are accessible before decommissioning the old Vault installation.


### How do I get started with VSHN OpenBao consulting?

Contact us using the form below. Describe your project: whether it is a Vault migration, a new OpenBao deployment, an architecture review, or operational support for an existing installation. We provide a written scope and CHF cost estimate within one business day. There is no commitment at the scoping stage.


### How does OpenBao help with CIS Controls compliance?

OpenBao maps directly to several CIS Controls v8 requirements. For CIS Control 3 (Data Protection), OpenBao provides encryption as a service via the Transit engine, encrypted storage at rest with AES-256-GCM, and a centralized secrets inventory that replaces scattered credentials in config files. For CIS Control 6 (Access Control Management), OpenBao enforces policy-based least-privilege access, issues dynamic credentials with automatic expiration, and supports TOTP-based MFA. For CIS Control 18 (Penetration Testing), OpenBao's comprehensive audit log records every secret access and authentication attempt, providing the evidence trail security teams need to verify controls. VSHN operates OpenBao with ISO 27001-certified processes and provides ISAE 3402 Type II reports for regulated customers. See our [compliance mapping](/compliance/) for the full control-by-control breakdown.


### Can consulting firms use VSHN-managed OpenBao for client infrastructure?

Yes. Consulting firms and system integrators use VSHN-managed OpenBao to provide secrets management for client infrastructure. Each client runs on isolated infrastructure with dedicated OpenBao instances on Swiss cloud. VSHN handles operations, upgrades, and 24/7 monitoring while your team configures policies, secrets engines, and authentication methods for the client environment. Written service agreements simplify engagement structuring. Our [partner page](/partners/) sets out how the collaboration works.


## Contact us

Ready to deploy OpenBao or migrate from HashiCorp Vault? Contact us for a free initial consultation. Consulting at CHF 250 per hour, no per-client fees, no license surcharges. VSHN and bespinian bring deep OpenBao expertise to every engagement. Want to hear from a customer first? We can arrange a reference call.


Booking: #contact

## Midpage Cta

- **Body**: A migration assessment maps your existing Vault workloads, policies, and auth methods onto OpenBao, and puts a written cost comparison in front of you before you commit to anything. Consulting at CHF 250 per hour.

- **Cta Label**: Get a Vault vs OpenBao cost comparison
- **Cta Url**: #contact
- **Cta2 Label**: Book a migration assessment
- **Cta2 Url**: https://vshn.cal.vs.hn/openbao

---

## OpenBao vs Vault vs Infisical: Platform Comparison

URL: https://www.openbao.ch/comparison/

# Secrets Management Platforms Compared

Choosing a secrets management platform affects your licensing costs, operational model, API compatibility, and data sovereignty for years. This page compares OpenBao against HashiCorp Vault Enterprise, Vault Community (BSL), Infisical, AWS Secrets Manager, and Azure Key Vault.

## Quick comparison

| | OpenBao | Vault Enterprise | Vault Community (BSL) | Infisical | AWS Secrets Manager | Azure Key Vault |
|---|---|---|---|---|---|---|
| **License** | MPL 2.0 | Commercial | BSL 1.1 | MIT | Proprietary | Proprietary |
| **Cost model** | Free + ops | Per-client pricing | Free (BSL-restricted) | Free tier + paid | Per-secret/month | Per-operation |
| **API compatibility** | Vault API | Vault API | Vault API | Own API | Own API | Own API |
| **Dynamic secrets** | Yes | Yes | Yes | Limited | No | No |
| **PKI/certificates** | Yes | Yes | Yes | No | No | Yes |
| **Transit encryption** | Yes | Yes | Yes | No | No | Yes |
| **HSM support** | Yes | Yes | No | No | CloudHSM | Azure HSM |
| **Data sovereignty** | Your infra | Your infra | Your infra | SaaS or self-host | AWS regions | Azure regions |
| **Managed by VSHN** | Yes | No | No | No | No | No |

## Vault Enterprise pricing

HashiCorp Vault Enterprise pricing is per-client: each application, service, or user that authenticates counts as a client. Pricing is not publicly listed. Based on available market data and customer reports, estimates range from $1 to $3 per client per month, with enterprise contracts typically starting at $50,000 per year.

IBM completed its acquisition of HashiCorp in 2024. For context, since IBM acquired Red Hat in 2019, Red Hat subscription prices have increased approximately 10% per year consistently. The same pattern should be expected for Vault Enterprise.

OpenBao has zero software licensing cost. VSHN managed operations are priced at a fixed monthly rate regardless of client count.

### Estimated annual cost by client count

| Clients | Vault Enterprise (est.) | OpenBao + VSHN managed ops |
|---|---|---|
| 100 | $1,200 - $3,600/year | Fixed monthly rate - contact us |
| 500 | $6,000 - $18,000/year | Fixed monthly rate - contact us |
| 2,000 | $24,000 - $72,000/year | Fixed monthly rate - contact us |

**Caveat:** Vault Enterprise pricing is not publicly listed. The estimates above are based on available market data and customer reports. Contact HashiCorp for a current quote.

## What the fork has closed

Two capabilities that used to separate the editions no longer do, and both matter to the organizations this site serves.

**Namespaces.** OpenBao has shipped multi-tenancy. Each namespace behaves like a mini-OpenBao with its own policies, authentication methods, secret engines, tokens and identity groups, along with namespace-aware policies and quotas, the ability to move or rename engines across namespaces, and locking. If you were looking at Vault Enterprise to give each team or tenant its own isolated space, that reason has gone.

**HSM auto-unseal.** Covered above: HashiCorp gates PKCS#11 behind Enterprise, OpenBao treats it as an ordinary seal configuration.

Both are worth checking against current documentation before a decision rests on them. The two projects are moving, and a comparison table is a snapshot of a moving thing.

## The fork: why OpenBao exists

In August 2023, HashiCorp changed Vault's license from MPL 2.0 to BSL 1.1 (Business Source License). BSL 1.1 restricts use in competing hosted services. In 2024, IBM acquired HashiCorp.

OpenBao forked from Vault in response to the license change. It is maintained under the Linux Foundation, uses MPL 2.0, and is fully API-compatible with Vault. Migrating from Vault to OpenBao is a configuration change, not a rewrite. Your existing Vault clients, scripts, and Terraform resources work without modification.

## Vault Enterprise

HashiCorp Vault Enterprise is the mature commercial offering with the longest track record.

**Strengths:** Sentinel policies for fine-grained access control, performance replication across clusters, disaster recovery replication, enterprise support SLA, and a large community of operators with deep operational knowledge. HSM auto-unseal is here too: HashiCorp's documentation states that auto-unseal and seal wrapping for PKCS11 require Vault Enterprise.

**No longer a differentiator:** namespaces. OpenBao has shipped them, so multi-tenancy is not a reason to buy the license on its own. See below.

**Limitations:** per-client pricing scales linearly with adoption. BSL 1.1 license restricts certain use cases. IBM's acquisition history with Red Hat shows consistent annual price increases, making long-term cost planning harder. You are dependent on a single vendor for the entire secrets management stack.

**Fits when:** your organization is already committed to Vault Enterprise, requires Sentinel policies or performance replication, and accepts the licensing cost and IBM vendor dependency.

## Vault Community (BSL)

The Vault Community edition is free to run, but the BSL 1.1 license restricts use in competing service offerings.

**Strengths:** free to run, same API as Vault Enterprise and OpenBao, broad documentation and community resources.

**Limitations:** BSL 1.1 is not an open source license by OSI definition. The restriction clause creates legal ambiguity for SaaS companies and internal platform teams that offer Vault as a shared service. You still rely on HashiCorp (now IBM) for fixes and security patches. And PKCS#11 auto-unseal is not available: HashiCorp's documentation puts it behind Enterprise, so a Community deployment cannot unseal itself from an HSM. For a regulated organization that has been told where its key material must live, that single line decides the edition.

**Fits when:** you run Vault Community for internal use, BSL restrictions do not apply to your use case, and you manage the operational burden yourself.

## Infisical

Infisical is a developer-first secrets platform built for application teams. It takes a different approach from Vault: a web dashboard, native integrations, and built-in secret rotation.

**Strengths:** developer-friendly web UI, native integrations with GitHub Actions, Kubernetes, Docker, and CI systems, built-in secret rotation for common services, and MIT license for the self-hosted version.

**Limitations:** Infisical does not have dynamic secrets - each secret is a stored value, not generated per-request. No PKI or certificate management. No transit encryption engine. No HSM support. Infisical and Vault solve different problems: Infisical is a secrets store; Vault is a secrets platform.

**Fits when:** your team needs a developer-friendly secrets store with a UI and does not require dynamic secrets, PKI, or transit encryption.

## Hyperscaler options: AWS Secrets Manager and Azure Key Vault

Both AWS Secrets Manager and Azure Key Vault integrate tightly with their respective cloud ecosystems.

**Strengths:** zero infrastructure to manage, native IAM integration, tight integration with cloud-native services (Lambda, EC2, App Service), built-in audit trails.

**Limitations:** US company jurisdiction applies regardless of data region. No dynamic secrets generation. No transit encryption engine. No portability - secrets stored in AWS Secrets Manager cannot be retrieved by an Azure workload without cross-cloud calls. AWS Secrets Manager charges $0.40 per secret per month plus $0.05 per 10,000 API calls. Azure Key Vault charges per operation. Costs grow with secret count and access frequency.

**Fits when:** your entire workload runs on a single hyperscaler, US jurisdiction is acceptable, and you need only static secret storage with IAM access control.

## When to choose each

**Choose OpenBao + VSHN managed operations** if you want Vault API compatibility without per-client licensing, need data sovereignty on Swiss infrastructure, or are migrating away from Vault Enterprise and want a drop-in replacement under MPL 2.0.

**Choose Vault Enterprise** if your organization requires Sentinel policies or performance replication, is already under an enterprise contract, and accepts per-client pricing and IBM vendor dependency.

**Choose Vault Community (BSL)** if you run an internal deployment, manage operations yourself, and BSL restrictions do not apply to your use case.

**Choose Infisical** if your primary need is a developer-friendly secrets store with a web UI and native CI integrations, and you do not need dynamic secrets or a PKI engine.

**Choose AWS Secrets Manager or Azure Key Vault** if your workloads run exclusively on one hyperscaler, US jurisdiction is acceptable, and you need basic secret storage with native IAM integration.

## Next steps

Assessing a Vault-to-OpenBao migration or comparing licensing costs for your client count? [Book a consultation](#contact). We review your current setup and give you a concrete cost comparison.


---

## OpenBao and CIS Controls - Secrets Management Compliance | VSHN

URL: https://www.openbao.ch/compliance/

# OpenBao and Compliance Frameworks

Secrets management is a core control in every major security framework. OpenBao provides the technical capabilities; VSHN operates them on Swiss infrastructure with ISO 27001-certified processes. This page maps OpenBao features to the CIS Controls, ISO 27001, and FINMA requirements that Swiss enterprises face.

## CIS Controls v8 mapping

### CIS Control 3: Data Protection

CIS Control 3 requires organizations to develop processes and technical controls to identify, classify, securely handle, retain, and dispose of data.

| Sub-control | OpenBao capability |
|---|---|
| 3.1 Establish data management process | OpenBao provides a centralized secrets inventory. All secrets are stored in defined paths with metadata, replacing scattered credentials in config files and environment variables. |
| 3.6 Encrypt data on end-user devices | OpenBao's Transit engine provides encryption as a service. Applications encrypt data through the API without handling raw keys. Keys never leave OpenBao. |
| 3.9 Encrypt data on removable media | Transit engine encrypts arbitrary data. Backup encryption uses sealed storage with auto-unseal keys stored separately from the data. |
| 3.10 Encrypt sensitive data in transit | All OpenBao API communication uses TLS. VSHN configures TLS certificates via the PKI engine, automating certificate lifecycle management. |
| 3.11 Encrypt sensitive data at rest | OpenBao encrypts all stored data at rest using AES-256-GCM. The encryption key is itself encrypted by an unseal key, providing defense in depth. |
| 3.12 Segment data processing | OpenBao namespaces and policies segment secrets by team, application, or environment. Access policies enforce least-privilege boundaries between segments. |

### CIS Control 6: Access Control Management

CIS Control 6 requires organizations to use processes and tools to create, assign, manage, and revoke access credentials and privileges for user, administrator, and service accounts.

| Sub-control | OpenBao capability |
|---|---|
| 6.1 Establish access granting process | OpenBao policies define who can access which secrets at which paths. Policies are code (HCL), reviewable in version control, and applied consistently. |
| 6.2 Establish access revoking process | Secrets have configurable TTLs with automatic expiration. Dynamic credentials (database, cloud) are generated on demand and revoked after use. Leaked credentials can be revoked immediately via the API. |
| 6.3 Require MFA for externally-exposed apps | OpenBao supports TOTP-based MFA for vault access. VSHN can integrate OpenBao authentication with your existing identity provider (OIDC, LDAP). |
| 6.4 Require MFA for remote network access | Service-to-service authentication uses short-lived tokens or AppRole credentials instead of static passwords, reducing the attack surface for remote access. |
| 6.5 Require MFA for administrative access | OpenBao operator access requires authentication through configured auth methods. VSHN enforces MFA for all administrative operations on managed infrastructure. |
| 6.7 Centralize access control | OpenBao serves as a single source of truth for secrets across all applications and environments. One policy engine governs access regardless of where the application runs. |
| 6.8 Define and maintain role-based access | OpenBao's policy system maps directly to role-based access control. Teams, applications, and CI/CD pipelines each get scoped policies that grant access only to the secrets they need. |

### CIS Control 18: Penetration Testing

CIS Control 18 requires organizations to test the effectiveness and resiliency of enterprise assets through identifying and exploiting weaknesses in controls.

| Sub-control | OpenBao capability |
|---|---|
| 18.1 Establish penetration testing program | OpenBao's comprehensive audit log records every secret access, authentication attempt, and policy evaluation. This provides the evidence trail penetration testers need to verify that secrets management controls work as designed. |
| 18.3 Remediate penetration test findings | Dynamic credentials mean remediation can include rotating all affected secrets programmatically. If a test reveals exposed credentials, OpenBao revokes and reissues them through automation, not manual processes. |
| 18.5 Perform periodic internal penetration tests | OpenBao's audit logs let security teams verify that access policies are correctly enforced. Policy simulation (dry-run capability evaluation) lets teams test access boundaries without touching production secrets. |

## ISO 27001 alignment

VSHN holds [ISO 27001 certification](https://www.vshn.ch/wp-content/uploads/2026/08/ISO-27001-certificate-VSHN-2026.pdf) for its operations. OpenBao capabilities map to several Annex A controls:

| ISO 27001 Annex A | OpenBao capability |
|---|---|
| A.8.1 User endpoint devices | Transit encryption for data at rest on endpoints |
| A.8.3 Information access restriction | Policy-based access control with least-privilege enforcement |
| A.8.5 Secure authentication | AppRole, OIDC, LDAP, and Kubernetes auth methods with short-lived tokens |
| A.8.9 Configuration management | Declarative policies in version control, auditable configuration |
| A.8.24 Use of cryptography | Transit engine, PKI engine, key management without key exposure |
| A.8.25 Secure development lifecycle | Dynamic credentials for CI/CD eliminate static secrets in build pipelines |

## FINMA considerations

Swiss financial institutions subject to [FINMA Circular 2023/1](https://www.finma.ch/en/documentation/finma-circulars/) (Operational Risks and Resilience) need to demonstrate control over cryptographic key management and access credentials. OpenBao on Swiss infrastructure operated by an ISO 27001-certified Swiss company (VSHN) addresses:

- **Key management under Swiss law**: no exposure to US CLOUD Act or foreign government access
- **Audit trail**: every secret access logged with timestamp, identity, and operation
- **Operational resilience**: HA deployment with automated unseal, encrypted backups, and 24/7 incident response
- **Outsourcing documentation**: VSHN provides ISAE 3402 Type II reports for regulated customers

## How VSHN implements compliance-ready OpenBao

VSHN does not just deploy OpenBao. We configure it for auditability:

1. **Audit logging enabled by default** with tamper-evident log storage
2. **Policy-as-code** stored in version control with review workflows
3. **Automated credential rotation** for database, cloud, and PKI credentials
4. **Encrypted backups** with retention and off-site replication
5. **Access reviews** supported through OpenBao's lease and token introspection APIs

Need a compliance assessment for your secrets management? [Contact us](#contact) for a free consultation.


---

## Partner with VSHN on OpenBao | VSHN

URL: https://www.openbao.ch/partners/

# Partner with VSHN on OpenBao

You bring the customer relationship and secrets management expertise: strategy design, Vault-to-OpenBao migration, policy design, application integration. VSHN brings OpenBao cluster operations, HA setup, HSM integration, monitoring, upgrades, and 24/7 support. Together you deliver a complete OpenBao solution without either side building capabilities you don't have.

## How we collaborate

**Lead Partner model.** For each project, one of us is the customer's single point of contact. Who leads depends on the project, agreed per engagement. The Lead Partner drives the project, handles invoicing, and owns first-level support.

**Joint delivery.** You handle consulting, integration, and project management. VSHN handles infrastructure operations, monitoring, backups, and SLA. Or the other way around, depending on the project. Roles are agreed per engagement, not locked into a rigid structure.

**Flexible billing.** Invoice the customer together or separately, agreed per project. Both models are supported: each party invoices their share directly, or one party invoices the full amount and redistributes.

**Protected relationships.** No undercutting. Your customer stays your customer. Existing relationships are respected on both sides, with contractual protections for both parties.

## Division of labor for OpenBao

| Your role | VSHN's role |
|-----------|-------------|
| Secrets management strategy | OpenBao cluster operations |
| Vault-to-OpenBao migration | HA setup and failover |
| Policy design | HSM integration |
| Application integration | Monitoring, alerting, and 24/7 incident response |
| Project management and customer relationship | Upgrades and SLA |

## Partners delivering OpenBao

**[bespinian](https://bespinian.io)**. Cloud-native consulting firm specializing in bespoke solutions. Delivers secrets management strategy and Vault-to-OpenBao migrations on VSHN-operated infrastructure.

See all VSHN partners at [servala.com/partners](https://servala.com/partners/).

## Become a partner

Interested in delivering OpenBao secrets management together? Let's explore how we complement each other.

[Book a partnership discovery call](https://vshn.cal.vs.hn/openbao) or [start a partnership conversation](#contact).


---

## OpenBao Sovereignty: Swiss Secrets Hosting | VSHN

URL: https://www.openbao.ch/sovereignty/

# OpenBao Sovereignty: The Open-Source Fork That Exists Because of Sovereignty

OpenBao is the sovereignty story. When HashiCorp changed Vault's license from open source (MPL 2.0) to the Business Source License in August 2023, and was then [acquired by IBM](https://www.ibm.com/blog/ibm-to-acquire-hashicorp/) in 2024, the community forked the project under the Linux Foundation as OpenBao.

If you're running HashiCorp Vault today, your secrets management depends on software controlled by IBM (US) under a restrictive license. Your secrets (API keys, database credentials, encryption keys, certificates) are managed by a tool whose future is determined by a US corporation subject to the CLOUD Act.

## Why OpenBao is the sovereign choice for secrets management

OpenBao maintains full API compatibility with HashiCorp Vault while restoring open-source governance:

- **Open source** (MPL 2.0): the license HashiCorp abandoned, now protected under Linux Foundation governance
- **No corporate owner**: governed by the Linux Foundation, not a single company
- **Full Vault compatibility**: existing clients, Terraform providers, and integrations work without changes
- **Swiss-only operations**: VSHN deploys and operates OpenBao on Swiss cloud infrastructure with encrypted storage and strict access controls
- **Deep codebase expertise**: VSHN engineers work with the OpenBao codebase daily and follow the Linux Foundation community

## Secrets management sovereignty compared

| Dimension | HashiCorp Vault | AWS Secrets Manager | Azure Key Vault | Google Secret Manager | VSHN Managed OpenBao |
|-----------|----------------|--------------------|-----------------|-----------------------|---------------------|
| **Ownership** | IBM (USA) | Amazon (USA) | Microsoft (USA) | Google (USA) | VSHN AG (Switzerland) |
| **Governing law** | US law | US law | US law | US law | Swiss law |
| **CLOUD Act** | Exposed | Exposed | Exposed | Exposed | Not exposed |
| **License** | BSL (not open source) | Proprietary | Proprietary | Proprietary | MPL 2.0 (open source) |
| **Governance** | IBM | Amazon | Microsoft | Google | Linux Foundation |
| **Key management** | Cloud HSM (US providers) | AWS CloudHSM | Azure Managed HSM | Cloud HSM | Swiss infrastructure, encrypted at rest |
| **Key custody** | Provider or customer | AWS-managed | Microsoft-managed | Google-managed | Strict operator access controls |
| **Operations team** | Customer or IBM | USA | USA | USA | Switzerland ([Swiss-only option](https://products.vshn.ch/support_plans.html#_option_switzerland_only_support)) |

## VSHN sovereignty self-assessment

We applied the EU's [Cloud Sovereignty Framework](https://commission.europa.eu/document/09579818-64a6-4dd5-9577-446ab6219113_en) (v1.2.1, October 2025) to our own services. This framework was used to score providers in the EU's [EUR 180M sovereign cloud tender](https://ec.europa.eu/commission/presscorner/detail/en/ip_26_833) in April 2026. Three pure-European providers achieved SEAL-3, while a consortium involving Google Cloud scored only SEAL-2.

*This is a self-assessment, not a formal SEAL certification. We publish it for transparency so customers can evaluate our sovereignty profile using the same structured criteria the EU uses.*

| # | Dimension | Weight | Assessment | Evidence |
|---|-----------|--------|-----------|----------|
| SOV-1 | Strategic | 15% | **Strong** | Swiss AG, no foreign parent, all shareholders Swiss citizens ([Commercial Register](https://zh.chregister.ch/cr-portal/auszug/auszug.xhtml?uid=CHE-275.566.226)) |
| SOV-2 | Legal | 10% | **Strong** | Swiss law ([GTC](https://products.vshn.ch/legal/gtc_en.html)), no CLOUD Act, [EU adequacy decision](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en) |
| SOV-3 | Data & AI | 10% | **Strong** | Swiss DCs by default. Sovereign key management via [Managed OpenBao](https://www.openbao.ch) on Swiss infrastructure |
| SOV-4 | Operational | 15% | **Strong** | Swiss 24/7 ops, [Swiss-only support option](https://products.vshn.ch/support_plans.html#_option_switzerland_only_support). All services on vanilla Kubernetes |
| SOV-5 | Supply Chain | 20% | **Strong** | Infrastructure-agnostic, [customer chooses provider](https://servala.com/providers/). Open-source software |
| SOV-6 | Technology | 15% | **Strong** | 100% open source. VSHN contributes to [K8up](https://github.com/k8up-io) (CNCF), [Crossplane providers](https://github.com/vshn), [Project Syn](https://github.com/projectsyn) |
| SOV-7 | Security | 10% | **Strong** | [ISO 27001](https://www.vshn.ch/wp-content/uploads/2026/08/ISO-27001-certificate-VSHN-2026.pdf), ISAE 3402 Type II, Swiss SOC. [FINMA-regulated customers](https://www.vshn.ch/en/solutions/solutions-for-banks-and-financial-service-providers/) |
| SOV-8 | Environmental | 5% | **Moderate** | DC operators: Green Datacenter AG (ISO 22301/27001/27701), [Exoscale sustainability](https://www.exoscale.com/sustainability/). [VSHN CSR policy](https://handbook.vshn.ch/corporate_social_responsibility_policy.html) |

**Overall: SEAL-3 equivalent**, the same level achieved by the winners of the EU's own sovereignty tender. No provider worldwide achieved SEAL-4: it requires fully EU/EEA-sourced hardware supply chains and open-source foundations, structural gaps shared by every cloud provider.

Try Swiss infrastructure: [Servala](https://www.servala.com) (managed services, free trial), [Exoscale]({{partner:exoscale.signup_url}}) (Swiss IaaS). Want help choosing? [Contact us](#contact).

## Get a sovereignty assessment for your secrets management

Still running HashiCorp Vault? We assess your sovereignty profile and plan migrations to OpenBao. Our engineers have migrated production Vault clusters to OpenBao and understand the platform at the source code level.


---

## What is OpenBao? Secrets Management and the Vault Fork

URL: https://www.openbao.ch/what-is-openbao/

# What is OpenBao?

OpenBao is an open-source secrets manager, and a fork of HashiCorp Vault managed under the Linux Foundation's OpenSSF. It stores the credentials your systems need, hands them out to the right callers, and records who asked for what.

If you already know what Vault does, OpenBao does that, with the same API. If you do not, the more useful place to start is the problem.

## The problem a secrets manager solves

Every system holds credentials: database passwords, API keys, certificates, tokens between services. They have to be somewhere. The usual somewheres all fail in the same way.

**In a config file in the repository.** Now every developer who has ever cloned it has production credentials, and so does anyone who gets the repository later. Removing the file does not remove it from history.

**In environment variables set by the deployment.** Better, and now they live in the CI system's configuration, visible to whoever can edit a pipeline, and printed by any process that dumps its environment on error.

**In a spreadsheet, a password manager, or one engineer's head.** Fine at five people. Not fine at fifty, and impossible to answer an auditor with.

The common failure in all three is that a credential, once written down somewhere shared, cannot be un-shared. You cannot tell who has it. You cannot rotate it without finding every copy. When someone leaves, you either rotate everything or accept that they still have it.

A secrets manager makes credentials something applications **fetch at runtime** rather than something they are given in advance. That single change is what makes the rest possible: access can be checked per request, granted per identity, logged, and revoked.

## What it does beyond storing them

- **Dynamic credentials.** Rather than storing a database password, OpenBao creates one when an application asks, valid for a short window, and removes it after. A credential that exists for an hour cannot leak for a year.
- **Encryption as a service.** Applications send data to be encrypted and get ciphertext back, without ever holding the key. The key stays where the application cannot lose it.
- **PKI.** Issuing and renewing internal certificates, which otherwise is a spreadsheet and an annual outage.
- **Audit.** Every access recorded. This is usually what turns "we should" into "we must", because it is the part a compliance requirement names directly.

## Why it exists as a fork

Vault was open source under the MPL. HashiCorp changed the license to the BSL, which is not an open source license. OpenBao was forked from the last MPL version in response, and is now under the Linux Foundation's OpenSSF, with community governance rather than a single vendor.

It keeps API compatibility with Vault, so existing integrations, tooling and workflows continue to work.

For most organizations the practical question is narrower than the licensing philosophy: whether the terms you are on today are the terms you will be on when your usage grows, and who decides that. A foundation-governed project answers that question differently from a single-vendor one. Which answer you prefer is a genuine choice, and the point of this section is that it is a choice, made once, that is expensive to revisit later.

## When you need one

- **More than a handful of services**, where credentials are being passed between systems rather than typed by a person.
- **Anything an auditor looks at.** "Who could read the production database password, and when did they" is a question with no good answer without this.
- **Short-lived infrastructure.** Containers and autoscaling groups appear and disappear; baking credentials into images does not survive contact with that.
- **Someone left and you had to rotate everything.** Once is a lesson.

## When you do not, yet

**A single application with two credentials** does not need this. Your platform's built-in secret storage is a reasonable place to start, and adding a secrets manager before there are secrets to manage is infrastructure for its own sake.

**If nobody will own the operational side**, it becomes a single point of failure for every service that depends on it, which is worse than the problem it replaced.

## What operating it involves

This is the part that separates a proof of concept from something you can depend on.

- **Unsealing.** The storage is encrypted at rest and has to be unsealed after every restart. How that happens without a human at three in the morning is a design decision, and it is the first one people postpone. See below, because for regulated organizations it is also where the hardware question lands.
- **It becomes critical infrastructure.** If applications fetch credentials at startup and it is down, nothing starts. High availability stops being optional the moment the second service integrates.
- **Backups, and the recovery keys.** Backing up the data is not enough; recovery also depends on key material kept somewhere separate, safe, and known to more than one person.
- **Policies that stay right.** Access is only as good as the policies, and policies accumulate. Without review they drift towards permissive, which is the direction that does not announce itself.
- **The audit log is evidence.** That means it needs to be shipped somewhere it cannot be edited by whoever the log is about.

## Where the keys actually live, and HSMs

For most organizations the unsealing question above is answered in software and that is the end of it. For regulated ones it is not, because the auditor's question is not "is it encrypted" but "where does the key material physically exist, and who could extract it".

That is what a hardware security module answers. An HSM is dedicated hardware that holds key material and performs operations with it without ever handing the key back out. Software can ask it to decrypt something; software cannot ask it for the key.

OpenBao supports this directly: its PKCS#11 seal configures an HSM as the auto-unseal mechanism, and the documentation carries per-vendor guides, including one for the Securosys Primus HSM, which matters here because Securosys is Swiss. An organization that chose OpenBao to keep secrets under Swiss jurisdiction can put the key protecting them in Swiss hardware rather than only in a Swiss data center.

**This is one of the clearest places the fork pays for itself.** HashiCorp's own documentation states that auto-unseal and seal wrapping for PKCS11 require Vault Enterprise. In OpenBao the same capability is an ordinary seal configuration, on a project with no license fees at all. If an HSM is a compliance requirement for you, that difference is not a rounding error in the comparison; for many organizations it is the whole of it.

Two differences from HashiCorp Vault Enterprise are worth knowing before you plan the migration, and both are documented rather than incidental. OpenBao requires the key material to be created externally before the instance is initialized; it will not create its own. And it supports AEAD-enabled algorithms only, not Encrypt-Then-MAC constructions. Neither is an obstacle, and both are the kind of thing that derails an afternoon if you meet them during the migration instead of before it.

Whether you need any of this is a compliance question rather than a technical one. If nobody has asked where the key lives, software unsealing is fine, and adding an HSM is expense and operational complexity bought for no requirement.

## Where VSHN fits

VSHN operates OpenBao on Swiss cloud infrastructure, with the unsealing, availability, backup and audit questions above answered rather than deferred, and migration from HashiCorp Vault where that is what you are moving away from. Our [comparison page](/comparison/) sets OpenBao against Vault and the alternatives, and the [compliance page](/compliance/) maps it to CIS Controls.

If you are early enough that the question is still whether you need one at all, that is the conversation worth having first.

[Book a secrets management review](#contact)