Vaults & HSM — Overview
One uniform interface over every key store: software, MPC, HSM and cloud KMS.
State machine
Key lifecycle states
Key states and allowed transitions, per NIST SP 800-57 Part 1.
One interface, many backends
In Cockpit v2 all key material sits behind a single, uniform vault interface. Every backend — a local software vault, a multi-party-computation (MPC) cluster, a hardware security module, or a cloud KMS — exposes the same operations, so applications and services never care where a key physically lives.
Uniform operations
Every backend exposes the same operations: health and version checks, key creation and deletion, public-key retrieval, encrypt / decrypt, sign / verify, and key discovery.
No key export by default
Private and symmetric key material stays in the backend. Only a key created exportable can leave, and only from a backend that allows it (Software Vault; Securosys HSM wrapped only). See Key Export.
Per-tenant credentials
Each vault record is tenant-scoped (and optionally scoped to an organizational unit); backend credentials are stored encrypted and decrypted only at use.
How a vault is selected
A vault is a stored, tenant-scoped record describing one backend instance. Keys reference their vault, and applications are linked to the vaults they may use.
Register a vault
Create a vault of a given type with its hostname/region and encrypted credentials. It carries a state — PreActive, Active, Deactivated or Compromised — and optional TLS material (client cert/key, custom CA) and PKCS#11 slot/PIN.
Link it to apps
Link the vault to the applications that may use it. A key created for an app is bound to a specific vault.
Resolve at runtime
On each crypto call the platform loads the matching vault, decrypts its credentials, and routes the operation to the correct backend — so create / encrypt / decrypt / sign / verify always reach the right place.
If no vault is resolved, the platform falls back to the in-memory Software Vault. That is convenient for development but not for production — see Software & DuoKey MPC KMS.
Supported key types
The key-type catalog is shared across every backend (individual backends accept a subset):
| Family | Key types |
|---|---|
| RSA | RSA-2048, RSA-4096 |
| ECC | EC-P256, EC-P384 |
| Symmetric / MAC | AES-128, AES-256, HMAC |
| Post-quantum KEM | ML-KEM-512 / 768 / 1024 (FIPS 203) |
| Post-quantum signatures | ML-DSA-44 / 65 / 87 (FIPS 204), SLH-DSA-128f / 128s (FIPS 205) |
Signing algorithms span RSA PKCS#1 v1.5 and RSA-PSS (SHA-256/384/512), ECDSA (SHA-256/384), HMAC (SHA-256/384/512) and the PQC schemes above.
The backends
DuoKey-operated software and MPC, the Securosys HSM, and the Sepior (Blockdaemon) MPC vault are documented in depth on their own pages. Cloud KMS and PKCS#11 HSM backends run through the same adapter interface.
| Backend | Category | Notes |
|---|---|---|
| Software Vault | DuoKey software | In-memory, local crypto — development / test only |
| DuoKey Software HSM | DuoKey MPC | Key shares across a 3+ node MPC cluster — the default DuoKey KMS |
| Securosys Primus | HSM | Swiss HSM via the Transaction Security Broker (TSB); PQC in hardware |
| Sepior (Blockdaemon) | MPC | Threshold MPC vault via the DuoKey KMS API |
| HSM Agent | On-prem HSM (bring your own) | Connects a customer-owned on-premises HSM over an outbound-only tunnel — no inbound connectivity required |
| Azure Key Vault | Cloud KMS | Managed-HSM tier for AES/HMAC |
| AWS KMS | Cloud KMS | Available where enabled in your deployment |
| Google Cloud KMS | Cloud KMS | Project / location / key-ring scoped |
| Alibaba Cloud KMS | Cloud KMS | Available where enabled in your deployment |
| HashiCorp Vault · OpenBao | Software KMS | Transit engine |
| Fortanix DSM | Cloud HSM | SGX-enclave crypto |
| Atos · Thales · Crypto4A · Utimaco | PKCS#11 | Network HSMs via a PKCS#11 REST proxy |
Securosys is DuoKey's lead HSM partner. The other HSM and KMS backends are supported through the same uniform adapter, so you can bind each tenant to the key store it requires.
Capability matrix
Not every backend offers every capability. The key distinctions:
| Capability | Where it is available |
|---|---|
| Post-quantum keys & signing (ML-KEM / ML-DSA / SLH-DSA) | Software Vault and Securosys only |
| Classical RSA / ECC / AES | All backends |
| HMAC | All except Azure Key Vault |
| Wrap / unwrap | Securosys (full HSM wrap/unwrap) |
| Key export (PKCS#8, PKCS#12, RSA-AES wrapped, KMIP) | Keys created exportable: Software Vault (all formats), Securosys (wrapped only, inside the HSM). See Key Export |
| AWS KMS | Available where enabled in your deployment |
If you issue post-quantum or hybrid certificates (see Post-Quantum PKI), the signing CA must be backed by the Software Vault or Securosys — the only backends that support PQC key generation and signing.
Vault management
Vaults are registered, connection-tested, health-checked, benchmarked, linked to apps, and have their keys discovered and synced — all from the Cockpit console and its management API.
Vault health monitoring
Since Cockpit 2.0.7, a scheduled job checks every vault every 5 minutes, so an outage shows up before a request fails on it. It probes each vault that is active, remote, and owned by an active tenant; software vaults are not probed.
| Output | When |
|---|---|
Log line event="vault_unreachable" (ERROR) | On every pass, for each vault that cannot be reached. It carries the vault, its type, the tenant, the host name, since when it is down, the number of consecutive failures and the error. |
Log line event="vault_recovered" (INFO) | When the vault answers again. |
Activity log entries VaultUnreachable / VaultRecovered | On a change of state only. |
Metric dk_vaults_unreachable | Number of vaults currently unreachable. |
The vault page's liveness panel shows the stored checks for the last 24 hours, 7 days or 30 days: uptime (the share of successful checks), latency, failures, downtime windows and the last error. Probe Now runs a real health check. Checks are kept for 30 days.
The job calls each active remote vault, cloud KMS included, with one read-only request every 5 minutes. It can be paused under Administration → Scheduled jobs.