Secrets management with Vault: handling API keys, DB passwords and JWT secrets correctly

What are secrets and what is secrets management?

Secrets are all access credentials a program needs at runtime that do not belong in source code. API keys (Stripe, OpenAI, Brevo), database passwords, JWT signing keys, OAuth client secrets, SSH private keys, TLS certificates, encryption keys for backups, webhook tokens. Every time a program has to prove its identity to another system, it does so with a secret.

Secrets management is the practice and tooling that stores these values centrally, distributes them under access control, rotates them regularly, and logs them on retrieval. Instead of storing each secret in a .env file on every server, the program fetches the value at start-up from a Vault instance via a short-lived token.

The anti-patterns are the majority of May 2026 data breaches. First: .env files in the Git repository – even in private repos a risk because new developers, interns, or compromised laptops suddenly have access. Second: hardcoded strings in source code – the worst case because a public open-source push distributes the keys worldwide. Third: cleartext backups of configuration files – the backup server becomes the treasure map of all keys. Fourth: shared passwords in Slack, e-mail, Notion – nobody knows who still has access after an employee leaves.

As of May 2026, HashiCorp Vault under Business Source Licence 1.1 is the de-facto standard tool. It is no longer Apache 2.0 but has an open-source clause with a competition restriction – for in-house use at an SME that is practically irrelevant; for commercial SaaS resellers it is a point to check. Alternatives: OpenBao (Apache 2.0 fork of Vault), Bitwarden Secrets Manager (OSS), Infisical (OSS), 1Password Secrets, AWS Secrets Manager, Azure Key Vault.

Why it matters

Four arguments make secrets management non-negotiable. First, practical: GitHub scans in May 2026 find thousands of compromised API keys in public repositories daily. An accidental git push with a .env file can within minutes lead to crypto-mining damages, mail-spam waves, or data theft. Damages quickly exceed CHF 10,000.

Second, regulatory: revFADP / revDSG has required a breach notification duty since September 2023 – within a short period to the EDÖB. From May 2026 the deadline is explicitly set at 72 hours, following EU GDPR practice. Anyone with a compromised API key of a bank integration has a notifiable breach. Without an audit trail in the secrets manager you cannot say which data was affected – the notification becomes uncertain and thus potentially incomplete.

Third, compliance: PCI-DSS demands key rotation every 90 days. ISO 27001 demands central key management in Annex A.10. Anyone processing Stripe payments or aiming for ISO certification cannot avoid secrets management. SOC 2 Type II also requires demonstrable rotation and access logs.

Fourth, professional secrecy: the API key for the LLM processing client data 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. Cross-link: ndsg-revfadp-ki, schatten-ki-im-unternehmen – the shadow-AI problem often starts with a leaked API key an intern uses for a personal project.

How a Vault pipeline is built

We walk through a production-ready pipeline.

Vault server: self-hosted Vault runs on a dedicated, hardened VM (Hetzner Dedicated, Infomaniak), ideally with three nodes in HA cluster and auto-unseal via AWS KMS or GCP KMS. Storage is Raft (built-in) or Consul. Vault starts in sealed state and needs an unseal – either manually with Shamir secret-sharing keys or automatically via cloud KMS.

Secrets engines: Vault organises secrets in "engines". KV v2 is the simplest for static values (API keys, DB passwords). PKI engine generates short-lived TLS certificates. Database engine generates dynamic DB credentials that expire after 1 hour. AWS engine generates short-lived AWS IAM credentials. Transit engine offers encryption-as-a-service without releasing the keys.

Authentication: every application authenticates with Vault via one of many methods. AppRole for server-to-server, Kubernetes service accounts for K8s workloads, OIDC for human users with SSO integration, GitHub for developer tooling. The result is always a short-lived token (typically 1 hour TTL) with which the application fetches secrets.

Rotation: static secrets are rotated every 90 days (PCI-DSS alignment). Vault can automate this – for database passwords it generates a new password, writes it into the DB, old tokens expire. Dynamic secrets are not rotated at all but live only for the job run (minutes to hours).

Audit trail: Vault logs every secret access: who (token-id), when (timestamp), which path (engine plus secret path), success or failure. Audit logs go into a SIEM pipeline (Grafana Loki, Splunk, ELK) and are retained for 10 years – in parallel with the audit-trail retention duty under Art. 957a CO. The audit engine cannot be turned off without sealing Vault itself.

Compromise response: 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 one would have to restart every application manually.

Tool comparison May 2026: HashiCorp Vault BSL 1.1 is the full solution with all engines, suitable from about 20 applications upward. OpenBao is the Apache-2.0 fork and as of May 2026 functionally equivalent for most use cases. Bitwarden Secrets Manager is the OSS solution for small setups, integrated with Bitwarden Vault. 1Password Secrets is the SaaS variant for teams already using 1Password for passwords. AWS Secrets Manager and Azure Key Vault are the cloud-native options – those hosting on AWS or Azure take the matching one. Infisical is a developer-friendly OSS alternative with good CLI and SDK support.

Secrets management roll-out in 5 steps

1. 01Inventory: which secrets exist where? List all .env files, configuration files, constants in code, shared passwords in Slack or Notion.
2. 02Choose tool: OpenBao or HashiCorp Vault for mid-size setups, Bitwarden Secrets or 1Password Secrets for small teams, AWS or Azure native for cloud hosting.
3. 03Set up Vault: HA cluster with 3 nodes, auto-unseal via cloud KMS or Shamir keys, audit engine to Loki or Splunk, AppRole for server auth.
4. 04Migrate applications: each application fetches secrets at start from Vault instead of .env. Library support: vault-agent for file-based apps, Vault SDK for code integration.
5. 05Rotation and compromise process: rotate static keys every 90 days, set up dynamic secrets for DBs and cloud APIs, write compromise runbook (notify within 72h).

When secrets management is mandatory

As soon as more than one employee has access to productive systems, central secrets management is mandatory – not recommended. The line is not "large vs small company" but "multi-person vs solo developer".

Concrete triggers: (a) you use paid APIs (Stripe, OpenAI, Anthropic, Brevo) with monthly costs above CHF 200 – a leaked key can cause damage in the hundreds of francs. (b) You have employees who turn over – each turnover needs a key rotation. (c) You are subject to PCI-DSS, ISO 27001 or SOC 2 certification. (d) You process personal data under revFADP with breach notification duty. (e) You are bound by professional secrecy under Art. 321 SCC. (f) You use multiple servers that would need the same secrets – a single source of truth is more efficient than manual sync.

For May-2026 SME setups: a 5-person fiduciary with 10 APIs and 3 servers is clearly in scope. A solo developer with two hobby projects can live with an encrypted .env file plus a separate key file – but as soon as the hobby projects touch customer data, the fiduciary level applies.

When a lighter setup is enough

Solo development without client data, pure demo setups, local learning projects – here a full Vault cluster is disproportional. An encrypted password-manager entry (Bitwarden, 1Password) plus an .env.encrypted file with GPG is enough. Separation of key and data is the core principle – the fully installed Vault becomes mandatory only from multi-person setup.

The opposite mistake is problematic: deploying Vault for a 2-person hobby project. The ongoing operation (3 HA nodes, auto-unseal configuration, audit SIEM, rotation) costs 1 to 2 days of maintenance per quarter. Anyone setting that up without need pays the complexity without using the value.

Second pitfall: deploying Vault but still feeding applications with .env files. Then Vault is just theatre – secrets still sit in cleartext on the servers. Migrating applications to direct Vault API calls is the critical step without which the whole setup is worthless.

Third pitfall: auto-unseal with AWS KMS without using AWS otherwise. That makes you dependent on an additional cloud provider just to start Vault. Anyone not on AWS or GCP anyway should set up manual unseal with Shamir keys – 5 keys to 5 different persons, 3 of them needed to unseal.

Trade-offs

FAQ

Related topics

Sources

1. HashiCorp Vault – official documentation · 2026-05
2. OpenBao – Apache-2.0 fork of Vault, project documentation · 2026-04
3. NIST SP 800-57 – Recommendation for Key Management Part 1 · 2026-02
4. OWASP Secrets Management Cheat Sheet · 2026-03
5. EDÖB – Meldung von Verletzungen der Datensicherheit · 2026-04
6. Gartner Magic Quadrant for Privileged Access Management 2026 · 2026-03