HashiCorp Vault: industry standard for secrets management since 2015

What is HashiCorp Vault?

HashiCorp Vault is the industry-standard tool for central secrets management in May 2026. Introduced in 2015 by HashiCorp, it has been the reference for handling API keys, database passwords, TLS certificates, and encryption keys in enterprise stacks ever since. Practically every Fortune 500 company with DevOps maturity uses Vault, and in the Swiss SME mid-market Vault is the most common choice from about 20 applications upwards.

In August 2023, HashiCorp switched the license from Mozilla Public License 2.0 (MPL-2.0, fully open-source) to Business Source License 1.1 (BSL 1.1). BSL 1.1 is no longer open-source in the OSI sense but a source-available license with a competition clause: users may read, modify, and commercially deploy the code -- but not sell a competing Vault-as-a-service product. For internal own-use in an SME this is practically irrelevant. For hosting providers and SaaS platforms wanting to sell Vault as part of their offering, it is a stopper. Community reaction: the Linux Foundation fork OpenBao, based on Vault 1.14 (last MPL state) and developed further under MPL-2.0.

Vault architecture rests on four concepts. (1) Secrets engines store or generate secrets. KV v2 for static values, Database engine for dynamic DB credentials, PKI engine for short-lived TLS certificates, AWS engine for dynamic AWS IAM tokens, Transit engine for encryption-as-a-service. (2) Auth methods determine who gets a token. AppRole for server-to-server, Kubernetes service account for K8s workloads, OIDC for human users with SSO integration, GitHub token for developer tooling. (3) Policies govern which token may read or write which secret paths -- HCL-based rule language with allow/deny and capability lists. (4) Audit devices log every Vault access: who, when, which path, success or failure -- the audit engine cannot be disabled without sealing Vault itself.

Vault always starts in sealed state and needs an unseal before it issues secrets. Unseal modes: (a) Shamir secret sharing with 5 keys to 5 different persons, 3 needed to unseal; (b) auto-unseal via cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) -- the unseal key sits in the cloud KMS and is fetched automatically at start. Auto-unseal is the standard in May 2026 because manual Shamir unsealing is operationally painful on server reboots.

Why it is mandatory for Swiss SMEs with > 5 services

Three regulatory and three practical arguments make Vault a mandatory layer in May 2026 above a certain setup size.

Regulatory: Art. 8 revFADP demands state-of-the-art protective measures. Cleartext secrets in .env files on every server is no longer state of the art in 2026. PCI-DSS v4.0 demands key rotation every 90 days and central key management -- without Vault or equivalent that is not practicable. ISO 27001 demands central key management in Annex A.10. SOC 2 Type II demands demonstrable rotation and access logs.

Professional secrecy: Art. 321 SCC demands that no third party gains unauthorised access to client data. An API key for the LLM processing client queries is itself a value relevant to professional secrecy. Anyone losing the key grants an unknown person access to all client queries of the past months. Vault delivers an audit trail of who retrieved which secret when -- the basis of a compromise analysis.

72-hour notification duty: revFADP / revDSG demands notification within 72 hours on breaches with high risk. Without a Vault audit trail you cannot say which data was affected -- the notification to the EDÖB becomes uncertain and thus potentially incomplete. With Vault you can show exactly: this token retrieved the following 12 secrets between 14:23 and 14:47, no other token was active.

Practical: GitHub scans find thousands of compromised API keys in public repositories daily in May 2026. An accidental git push with a .env file can within minutes lead to crypto-mining damage, spam waves, or data theft. Vault prevents that structurally -- applications fetch secrets at runtime from Vault, they never sit in the repository.

Compromise response in minutes: on a secret compromise (e.g. a developer accidentally copied an API key into a Slack thread), the value is immediately revoked and regenerated. Vault does that in one step -- all applications still using the token get a 403 and fetch the new value on their next cycle. Without Vault, every application would have to be restarted manually.

Dynamic secrets: Vault can generate database credentials only at job start and let them expire after 1 hour. That reduces the attack window on compromise to minutes instead of weeks. Static database passwords in config files are no longer state of the art in 2026.

Setup, engines, and example integration

A productive Vault setup consists of three nodes in HA cluster with Raft storage (built-in) or Consul storage. Hetzner Dedicated or Infomaniak Public Cloud are good platforms.

Docker Compose for single-node SME setup:

```yaml version: "3.8" services: vault: image: hashicorp/vault:1.17 container_name: vault restart: unless-stopped cap_add: - IPC_LOCK environment: - VAULT_ADDR=http://0.0.0.0:8200 - VAULT_LOCAL_CONFIG={"storage":{"raft":{"path":"/vault/data","node_id":"vault-1"}},"listener":{"tcp":{"address":"0.0.0.0:8200","tls_disable":1}},"ui":true,"api_addr":"http://vault:8200","cluster_addr":"https://vault:8201","disable_mlock":true,"seal":{"awskms":{"region":"eu-central-1","kms_key_id":"alias/vault-unseal"}}} ports: - "127.0.0.1:8200:8200" volumes: - ./vault-data:/vault/data - ./vault-logs:/vault/logs command: vault server -config=/vault/config/vault.hcl ```

Initialisation at first start: vault operator init -recovery-shares=5 -recovery-threshold=3 generates 5 recovery keys (3 needed to unseal). On auto-unseal via AWS KMS the master key is held there; the recovery keys are backup in case KMS access is lost.

Example: activate KV engine for API keys ```bash vault secrets enable -path=kv kv-v2 vault kv put kv/openai api_key=sk-proj-xyz... vault kv put kv/stripe api_key=sk_live_xyz... webhook_secret=whsec_xyz... ```

Example: Database engine for dynamic Postgres credentials ```bash vault secrets enable database vault write database/config/postgres-treuhand \ plugin_name=postgresql-database-plugin \ connection_url="postgresql://{{username}}:{{password}}@postgres.treuhand.local:5432/main" \ allowed_roles="readonly,readwrite" \ username="vault-admin" password="SecretAdmin2026" vault write database/roles/readonly \ db_name=postgres-treuhand \ 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="24h" ```

Application calls at start: GET /v1/database/creds/readonly -> gets user+password+TTL 1 hour. After 1 hour the DB user expires automatically.

AppRole for server auth ```bash vault auth enable approle vault write auth/approle/role/treuhand-app \ token_policies="treuhand-policy" \ token_ttl=1h token_max_ttl=4h vault read -field=role_id auth/approle/role/treuhand-app/role-id vault write -field=secret_id -f auth/approle/role/treuhand-app/secret-id ```

The application receives RoleID and SecretID. At start: vault write auth/approle/login role_id=<role> secret_id=<secret> -> gets a token with 1h TTL and the treuhand-policy.

Vault Agent as sidecar process simplifies integration for existing applications working with .env files: Vault Agent renders a template file with current secrets to /run/secrets/.env, the application reads as usual.

Vault roll-out in 5 steps

1. 01Inventory all secrets: list .env files, config files, constants in code, shared passwords in Slack/Notion; sensitivity classification (low/medium/high).
2. 02Set up Vault cluster: 3 nodes on Hetzner Dedicated, Raft storage, auto-unseal via AWS KMS or Shamir keys (3-of-5); audit engine to Loki/Splunk.
3. 03Activate secrets engines: KV v2 for static values, Database for dynamic DB creds, PKI for short-lived certificates; one separate engine path per service.
4. 04Configure auth methods: AppRole for server-to-server (1h tokens), OIDC for human users via SSO (Authentik/Authelia), policies by least privilege.
5. 05Migrate applications: Vault Agent as sidecar for file-based apps, SDK integration for code; rotate static secrets every 90 days, document compromise runbook (72h notification).

When to deploy Vault

Vault is the right choice in the following constellations in May 2026.

SME with > 5 applications and > 1 employee: at this size, manual effort for secrets rotation becomes untenable. Each personnel change requires rotation of all keys the employee knew -- impossible to track without Vault. With Vault: revoke token, disable employee OIDC account, done.

Applications with paid API keys above CHF 200 per month: Stripe, OpenAI, Anthropic, Brevo, Twilio. A leaked key can cause damage in the hundreds of francs. Vault makes the diff between "key sits in Git forever" and "key sits only in Vault and rotates every 90 days".

Compliance duty (PCI-DSS, ISO 27001, SOC 2): all three demand central secrets management. Vault is the canonical answer auditors accept without discussion.

Multi-server setups with shared secrets: three servers that all need the same Stripe webhook secret. Without Vault: the secret sits in three .env files, rotation touches three servers, sync risk. With Vault: the secret sits in Vault once, all three servers fetch it at runtime, rotation in one step.

Database access with client data: static DB passwords are no longer acceptable in 2026. Vault Database engine generates per job run a DB user with 1h TTL. The attack window on compromise shrinks from weeks to hours.

The lower threshold: a solo developer with 1-2 hobby projects without customer data does not need Vault. An encrypted .env.encrypted file with GPG plus 1Password personal account is enough. From 2-person setups with real client data, the Vault area begins.

When Vault is too much

Three cases where Vault is the wrong choice in May 2026.

Solo setups or hobby projects without client data: Vault needs 1-2 days of maintenance per quarter (unseal key backup, HA cluster health, audit log review). For a solo hobby project with 2-3 secrets this is oversized. Pragmatic alternative: 1Password Personal with secrets feature, or Bitwarden Personal with Secrets Manager.

Pure cloud-native setups on AWS or Azure: when the whole infrastructure runs on AWS or Azure, AWS Secrets Manager or Azure Key Vault is often the more efficient choice. Deep integration with IAM roles, no additional cluster to operate, no unseal management. Vault gives more flexibility (multi-cloud, on-prem) but also more operations load.

Strict OSS policy in the company: BSL 1.1 is not open-source in the OSI sense. Anyone with a strict OSS policy or an audit on "only OSI-certified licenses" cannot avoid OpenBao -- the Linux Foundation fork of Vault 1.14 under MPL-2.0. Functionally about 90 percent of Vault in May 2026.

General pitfalls in Vault deployments: (a) auto-unseal via cloud KMS without backup recovery keys -- on KMS failure the cluster is unstartable. (b) Audit logs not mirrored to a SIEM pipeline -- on Vault crash they are gone. (c) Policies too permissive -- a token with "kv/*" reads all secrets, contradicting least privilege. (d) Vault set up but applications still fed with .env files -- Vault is then just theatre, secrets still sit in cleartext on servers. (e) Token TTL set too long (24h+) -- raises attack window on token theft. Token TTL 1h is standard.

Trade-offs

FAQ

Related topics

Sources

1. HashiCorp Vault -- official documentation · 2026-05
2. HashiCorp -- BSL 1.1 license FAQ · 2026-03
3. OpenBao -- Linux Foundation fork · 2026-04
4. NIST SP 800-57 -- Recommendation for Key Management Part 1 · 2026-02
5. OWASP Secrets Management Cheat Sheet · 2026-03