HashiCorp Vault for Regulated Enterprises: Secrets Management & Encryption Guide

Dynamic Secrets — DORA Art. 9(4), NIS2 Art. 21(2)(i)

Instead of long-lived credentials, Vault generates short-lived, unique credentials on demand:

• Database credentials: Each application instance gets unique credentials with automatic expiration (TTL). No shared passwords.
• Cloud credentials: AWS IAM roles, Azure service principals, GCP service accounts — generated dynamically with minimal permissions
• PKI certificates: TLS certificates issued and rotated automatically. Supports the 47-day certificate lifecycle.
• Kubernetes service accounts: Dynamic K8s tokens with scoped RBAC permissions

Why it matters: Dynamic secrets eliminate credential sprawl. If credentials are compromised, they expire automatically. No more "this database password hasn't been rotated in 3 years."

Encryption as a Service (Transit) — GDPR Art. 32, NIS2 Art. 21(2)(h)

• Application-level encryption: Applications send plaintext to Vault, get ciphertext back. Encryption keys never leave Vault.
• Key rotation without re-encryption: Vault supports key versioning — rotate keys without re-encrypting all data
• Tokenisation: Replace sensitive data (credit card numbers, SSNs) with non-sensitive tokens
• Data masking: Format-preserving encryption for development and testing environments

GDPR compliance: Vault's transit engine provides the "encryption of personal data" measure explicitly called out in GDPR Article 32(1)(a) as an appropriate technical measure.

Audit Logging — DORA Art. 10, Art. 12

• Every operation logged: Every authentication, secret read, secret write, and policy change is logged with timestamp, identity, source IP, and request details
• Multiple audit backends: File, syslog, socket — send to your SIEM for centralised analysis
• HMAC hashing: Audit logs hash sensitive values by default — you can see who accessed what without exposing the secret values
• Tamper evidence: Audit log integrity can be verified

Three integration patterns for Kubernetes:

1. Vault Agent Injector: Sidecar container that automatically injects secrets into pod filesystem. Minimal application changes.
2. Vault CSI Provider: Mounts secrets as Kubernetes volumes via the Secrets Store CSI Driver. No sidecar needed.
3. Vault Secrets Operator: Kubernetes operator that syncs Vault secrets to Kubernetes Secrets. Most Kubernetes-native approach.

Recommended for regulated environments: Vault Secrets Operator for simplicity, or Agent Injector for maximum control and audit granularity.

Choose Vault if: Multi-cloud, need dynamic secrets and PKI, want a single secrets platform. Choose cloud-native if: Single cloud, simple secret storage needs, want minimal operational overhead.

1. High availability from day one — Deploy Vault in HA mode with Raft storage (3 or 5 nodes)
2. Auto-unseal with cloud KMS — Don't rely on manual unseal with Shamir keys for production
3. Enable audit logging immediately — Two audit backends minimum (if one fails, Vault stops serving requests)
4. Use namespaces for multi-tenancy — Separate teams/environments with Vault namespaces (Enterprise feature)
5. Integrate with your identity provider — OIDC, LDAP, or Kubernetes auth — no standalone Vault passwords