ADR-001: Vault OSS as Strategic Secret Management and Trust Platform
Executive Summary
OVES currently experiences immediate operational pressure from uncontrolled password-based access and fragmented credential practices. Existing mechanisms already include GitHub Secrets for CI/CD, partial Bitwarden adoption, emerging passkey adoption, Azure AD strategic direction for employee identity, and future plans for IoT identity, battery identity, cryptographic anchoring, and public blockchain integration.
The original question was whether OVES should adopt a developer-oriented secret platform (Infisical) or move directly to a more strategic trust platform (Vault).
Decision: Adopt Vault OSS as the strategic machine-secret and future trust platform. Operate it initially as Vault-Lite (simple secret management only) and defer advanced trust capabilities until organizational maturity justifies activation.
Human credential governance remains a separate concern and must be stabilized first (Phase 0).
Context
Problems
- Password-based access has become difficult to govern
- Human credentials are distributed across multiple unmanaged locations
- Bitwarden usage is inconsistent across the organization
- GitHub Secrets is used beyond its intended bootstrap role
- Machine secrets are not centrally governed
- Future architecture includes PKI, IoT identity, OTA, cryptographic asset identity, and blockchain anchoring
Evaluation Criteria
- Scales with organizational growth (70+ people today, growing)
- Remains cost-contained
- Minimizes migration regret
- Portable across clouds (not locked to AWS or Azure)
- Supports future trust requirements (PKI, device identity, blockchain anchoring)
Conceptual Separation
Secret management and trust infrastructure are different problems with different tooling.
Identity — "Who are you?"
| Tool | Scope |
|---|---|
| Azure AD | Employee identity, SSO |
| Passkeys | Passwordless authentication |
| SSO | Application access |
Secret Management — "What may be accessed?"
| Tool | Scope |
|---|---|
| Bitwarden | Human credentials (passwords, TOTP, recovery codes) |
| Vault OSS | Machine secrets (API keys, service credentials, deployment secrets) |
| GitHub Secrets | CI/CD pipeline secrets (bootstrap role only) |
Trust Infrastructure — "How do systems prove identity?"
| Tool | Scope |
|---|---|
| Vault PKI | Certificates, device identity, mTLS |
| Internal CA | Organization trust anchor |
Blockchain Anchoring — "How can trust become immutable?"
| Scope | Tool |
|---|---|
| Asset proofs | Public blockchain |
| Ownership events | Cryptographic verification |
| Notarization | Immutable ledger |
These are separate architectural layers that serve different purposes.
Decision
Vault OSS over Infisical
The initial comparison (Infisical vs Vault as "secret management tools") was misleading.
Infisical = Developer Platform. Optimizes onboarding speed, developer experience, secret injection, and operational simplicity.
Vault = Trust Platform. Optimizes trust, PKI, identity, credential issuance, and cryptographic infrastructure.
Given OVES's architectural direction — IoT, battery identity, PKI, blockchain anchoring, OEM control, long-lived infrastructure — Vault aligns better strategically.
The decision was not made because Vault has more features. It was made because trust itself is expected to become a business capability.
Cost Model
| Scale | Vault OSS | Infisical | Doppler |
|---|---|---|---|
| Solo | $0 + infra | $0 (free tier) | $0 (free tier) |
| 70 users | ~$150/mo (1 VM) | $1,260/mo | $420/mo |
| 200+ users | ~$200/mo | $3,600/mo | $1,200/mo |
Vault OSS per-user cost is zero. Only infrastructure cost scales — one VM regardless of user count.
Vault-Lite Operating Model (Phase 1)
Vault complexity is operational, not installation complexity. Deploy Vault but intentionally use only a controlled subset.
Enable
| Capability | Purpose |
|---|---|
| KV Secrets Engine | Store API keys, environment secrets, deployment secrets |
| Azure AD Auth | Human authentication via existing identity provider |
| GitHub Auth | CI/CD pipeline authentication |
| Audit Logging | All secret access becomes auditable |
| Simple Policies | developers, operations, production roles |
Secret Injection Pattern
Applications MUST NOT consume Vault directly. Use one of:
| Method | When to use |
|---|---|
| Vault Agent (sidecar) | Containerized deployments |
| External Secrets Operator | Kubernetes workloads |
CLI wrapper (vault kv get in startup scripts) |
Simple VM/bare-metal deployments |
One pattern must be chosen and documented as the organizational standard before Phase 1 completes.
Intentionally Defer
- PKI
- Dynamic Secrets
- Transit Encryption
- Service Mesh (Consul)
- Device Certificates
- Multi-region Replication
- Advanced Namespaces
Human vs Machine Credential Strategy
Human Credentials
| Aspect | Decision |
|---|---|
| System of record | Bitwarden (mandatory) |
| Identity authority | Azure AD |
| Authentication trend | Passkeys (gradual replacement) |
| Access path | Employee → Azure AD → Passkey → SSO → Application |
Allowed in Bitwarden: - Shared SaaS credentials - Administrative passwords - Secure notes - Recovery codes - TOTP tokens
Disallowed in Bitwarden: - API keys - .env files - Infrastructure secrets - Certificates
Machine Secrets
| Aspect | Decision |
|---|---|
| Strategic platform | Vault OSS |
| Access path | Application → Secret Provider → Vault |
Unseal and Recovery
Vault requires unseal keys to start after reboot. For Phase 1:
- Use Shamir's Secret Sharing (default: 5 key shares, 3 threshold)
- Key holders: OVES Architecture team members (minimum 3)
- Initial root token: revoke immediately after initial configuration
- Recovery keys: stored in Bitwarden (secure notes), split across multiple trusted individuals
- Document the unseal procedure in the team runbook
Enterprise Escalation Criteria
Remain on Vault OSS unless at least two of the following become true:
- Multiple active regions
- Independent business-unit isolation required
- Large application estate (100+ services)
- Dedicated platform engineering team
- Compliance pressure (SOC 2, PCI-DSS)
- Advanced disaster recovery requirements
- Revenue-critical trust platform
Enterprise is an operational scaling decision, not an architectural dependency.
PKI Position
PKI is strategically important for OVES but deferred to Phase 2.
| Domain | Use Case |
|---|---|
| Vehicle | Certificate → MQTT mTLS → secure OTA |
| Battery | Certificate → ownership → proof of provenance |
| Device | Certificate → identity → access control |
PKI and blockchain serve different purposes: - PKI = Identity and trust - Blockchain = Proof and immutability
Phased Implementation
Phase 0 — Credential Stabilization (30–60 days)
Objective: Stop the bleeding on human credentials.
- Mandate Bitwarden for all employees (enforced, not voluntary)
- Conduct credential inventory — all accounts, all locations
- Accelerate passkey adoption for high-value accounts
- Define credential audit deadline — non-compliant accounts get rotated
- Executive sponsorship required as Phase 0 dependency
Deliverable: Complete credential inventory.
Phase 1 — Vault-Lite (90 days)
Objective: Centralize machine secrets.
- Deploy Vault OSS (single VM or container)
- Configure KV secrets engine
- Integrate Azure AD and GitHub authentication
- Implement simple role-based policies
- Enable audit logging
- Document onboarding playbook for new team members
- Define and document the secret injection pattern
Deliverable: Vault OSS operational with audit trail.
Phase 2 — Trust Introduction (2027)
Objective: Introduce PKI for device and service identity.
- Enable Vault PKI engine
- Establish internal CA
- Issue device certificates for MQTT mTLS
- Certificate lifecycle management (issuance, rotation, revocation)
Deliverable: Vault PKI operational. Requires at least 1 dedicated person with certificate lifecycle expertise.
Phase 3 — Asset Trust (2028+)
Objective: Cryptographic trust architecture for physical assets.
- Battery identity certificates
- Device identity at scale
- Blockchain proof anchoring
- Asset registry integration
Deliverable: Cryptographic trust architecture end-to-end.
Future Trust Architecture
Human Access
├── Passkeys
├── Azure AD
└── Bitwarden
Machine Access
├── Vault KV
├── GitHub OIDC
└── Runtime Secret Injection
Trust Layer
├── Vault PKI
├── Device Certificates
└── Internal CA
Proof Layer
├── Asset Registry
├── Blockchain Anchoring
└── Cryptographic Verification
Business Layer
├── Odoo
├── ABS
└── OV Applications
Additional Recommendations
| Item | Recommendation |
|---|---|
| Secret rotation | Define rotation policy in Phase 1 — frequency and responsibility per secret type |
| Git leak detection | Run gitleaks or trufflehog in CI pipelines — complements Vault, does not replace it |
| Version pinning | Pin Vault OSS to specific releases; define upgrade cadence (quarterly recommended) |
| New hire onboarding | Document Vault access request and approval flow as part of Phase 1 |
References
- HashiCorp Vault Documentation
- ADR source discussion
- OVES Infrastructure Roadmap (internal)