Overview

Enclave Vaults is a distributed virtual HSM (vHSM). Each vault instance is a small key-management service that runs inside an Intel SGX enclave: it holds typed key objects, executes cryptographic operations on them inside the enclave, and refuses to act outside the policy attached to each key. A constellation of independent vault instances forms a single logical key-management surface, with redundancy across machines and an information-theoretic distribution path for the secrets that warrant it.

This page is a one-screen orientation. The Architecture page describes the runtime in detail, and the Access Control page covers policies, principals, and approvals.

Where Enclave Vaults sits

Enclave Vaults is the right fit when you want HSM-style key custody without putting the trust of the system in any one device, provider, or operator.

Three properties to remember

1. Keys live inside attested enclaves. Typed key objects (signing keys, AES data keys, HMAC keys, derivation seeds, opaque shared secrets) sit in the enclave's sealed state. Callers ask the vault to Sign, Wrap, Mac, Derive, and so on. By default, raw key material does not cross the enclave boundary.
2. Distributed trust where it matters. Highly sensitive secrets that the owner wants to keep recoverable across the constellation can be stored as RawShare keys: the secret is split with Shamir Secret Sharing, one share per vault, and reconstructed by the owner from any quorum. A single compromised vault leaks one share, which reveals nothing about the secret.
3. Every operation is gated by a policy that the enclave enforces. A KeyPolicy describes which OIDC identities, which calling enclaves, and which fresh approvals are required for each operation. The enclave refuses anything that does not match. There is no admin override.

What is new in v0.19

The current release reorganises the vault around typed keys and in-enclave operations. Previous versions were already a meaningful step (information-theoretic distribution of opaque secrets across attested enclaves), and that path is still here as the RawShare key type. v0.19 adds:

• Typed key objects with in-enclave operations. Aes256GcmKey, Ed25519SigningKey, P256SigningKey, HmacKey, Bip32MasterSeed, WrappedBlob. By default these keys are non-exportable: the operation runs inside the enclave, only the result leaves.
• A richer KeyPolicy. Per-operation rules with composable conditions (AttestationMatches, ManagerApproval, TimeWindow, CallerHoldsRole), a separate Mutability surface, and explicit principals for owner, managers, auditors, plus optional TEE / FIDO2 / mTLS principals.
• A controlled lifecycle for caller-enclave version changes. When the customer application that consumes a key is rebuilt and its MRENCLAVE changes from v(N) to v(N+1), the new measurement is held in a pending slot until the key owner (and managers, if configured) explicitly approves promoting it into the key's attestation_profiles. The platform never auto-grants a new measurement access to existing key material; this is a protocol invariant.

Components

Honest boundaries

Enclave Vaults is a vHSM, not a FIPS 140-3 certified HSM. It does not have tamper-evident enclosures or environmental sensors. The security model rests on Intel SGX isolation, on attested identity for every connection, and (for RawShare keys) on the unlinkability of Shamir shares across independent enclaves. For most threat models this is a strict improvement over a single appliance taken on faith. Where a specific FIPS certification is a hard legal requirement, dedicated certified HSMs remain the right choice.

The architectural rationale is in the original blog post on rethinking secrets management. The motivation for the v0.19 redesign is in the v0.19 release post.