Same primitives, one less product to operate.
Tessarac Secrets has the same KV, dynamic database credentials, internal CA, encryption services, and SSH key management you already know from Vault — except the identity it runs on, the audit log it writes to, and the RBAC it enforces are the same as the rest of your security platform. Migrating off Vault is a backend swap, not a re-architecture.
What it is, what it isn't
A direct functional swap for Vault — not a re-platforming.
If you wrote your apps against Vault's KV / Database / Transit / PKI / SSH backends, the equivalent Tessarac SDK call shape is the same. Idiomatic Go / Python / Node / Java SDKs ship with helpers that mirror the Vault API surface so most app changes are a constructor swap.
- KV v2 — versioned, hierarchical paths, TTL — same as Vault
- Database secrets engine — dynamic credentials issued per request against every major relational, document, and key-value database
- Transit / encryption-as-a-service — encrypt/decrypt without the app holding the key
- PKI / internal certificate authority — issue, rotate, revoke X.509 service certs
- SSH backend — short-lived OpenSSH certificates signed by the internal CA
- Kubernetes Secrets Engine with CSI driver, sidecar injector, ESO plugin, and direct SDK
Side-by-side: Tessarac vs. HashiCorp Vault
Honest assessment as of May 2026. Where HashiCorp Vault ships an equivalent capability we say so; where they don't we say so. Notes carry the source.
Core secrets engine
| Feature | Tessarac | HashiCorp Vault |
|---|---|---|
Static KV (versioned) | Yes | Yes |
Dynamic database credentials | Yes | Yes |
Encryption-as-a-service (Transit) | Yes | Yes |
Internal certificate authority (PKI) | Yes | Yes |
SSH backend (signed certs) | Yes | Yes |
BYOK / HYOK to your own KMS | Yes | Yes |
Kubernetes integration
| Feature | Tessarac | HashiCorp Vault |
|---|---|---|
CSI Secrets Store driver | Yes | Yes |
Sidecar injector | Yes | Yes |
External Secrets Operator plugin | Yes | Yes |
Direct SDK (idiomatic per-language) HashiCorp SDKs exist for most languages but feel less idiomatic than the per-language Tessarac SDKs. | Yes | Partial |
Hardware-bound workload identity | Yes | No |
What Vault doesn't do
| Feature | Tessarac | HashiCorp Vault |
|---|---|---|
Workforce + Customer SSO (IdP) | Yes | No |
Privileged access (SSH/RDP/DB brokering) Vault has SSH OTP/CA backends; not a full PAM brokering surface. | Yes | Partial |
Endpoint security (EDR agent) | Yes | No |
API-key management for products you ship | Yes | No |
AI-powered SOC analysis | Yes | No |
Operator surface
| Feature | Tessarac | HashiCorp Vault |
|---|---|---|
Per-tenant ECDSA P-384 trust anchor | Yes | Partial |
Customer-visible per-tenant audit | Yes | No |
Audit export to BYO destination Vault audit-device plugins exist but require operator integration; Tessarac ships the destinations. | Yes | Partial |
Open source (community edition) Vault Community is open-source; Vault Enterprise / HCP Vault are paid. Tessarac is open-core with the same shape. | Yes | Yes |
One bill for the whole platform | Yes | No |
Migration mechanics
Import paths from Vault and the cloud-native vendors.
Tessarac Secrets ships an importer that reads from Vault's KV (v1 + v2), database role configurations, PKI roles, and SSH role configurations. Every major cloud secrets manager has its own import path. Most teams move one secrets engine at a time and keep the others on Vault until ready.
- Per-engine importer — KV first, then database roles, then PKI, then SSH
- Shadow-mode read — apps read from both Vault and Tessarac in parallel; assert equivalence before cutover
- Reference architecture for the parallel-run period published in the Tessarac docs
- Per-tenant compliance preset — Federal tenants get FIPS 140-3 validated cryptography enforced; standard tenants don't pay for it
Run Tessarac Secrets behind your existing Vault clients
The SDK call shape is the same. The audit log is the rest of your security platform. The bill is one line.