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, the Access Control page covers policies, principals, and approvals, and the Standard Interfaces page covers the PKCS#11, KMIP, and REST surfaces your existing software can use to reach a vault-held key.

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.

Typed keys and in-enclave operations

The v0.19 redesign reorganised the vault around typed keys and in-enclave operations, and that is the shape today. The earlier information-theoretic distribution of opaque secrets across attested enclaves is still here as the RawShare key type.

• 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. Signing covers both a message the vault hashes and a pre-computed digest the vault signs raw (the path TLS stacks and code signers use).
• 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.

A user-first KMS with standard interfaces

Two capabilities were added on top of that core.

• A developer can own keys. Custody is no longer reserved for platform enclaves. Any user can create a vault, hold signing and wrapping keys in it, and author the policy that governs them, through the Privasys CLI (privasys vault ...) and a REST API shaped like the cloud KMS surfaces developers already know. The API is a client-side proxy, so the data plane stays a direct, attested channel to the constellation; the platform mints the grant and enforces quotas but never sees the key material.
• Existing software reaches a vault key unchanged. A PKCS#11 3.1 module puts a vault-held key behind OpenSSL, Java, TLS servers, and code-signing tools, and a KMIP 2.1 gateway lets enterprise key-management software use the constellation as a remote key manager. See Standard Interfaces.

Components

Boundaries

Enclave Vaults is a vHSM, not a FIPS 140-3 certified HSM. It has no tamper-evident enclosure and no 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 improves on a single appliance taken on faith. Where a specific FIPS certification is a hard legal requirement, dedicated certified HSMs remain the right choice.

The standard interfaces carry a deliberate limit as well: a PKCS#11 or KMIP client cannot present a wallet approval or reason about attested measurements, so operations a key gates on those conditions are unavailable over those interfaces and fail closed. A standard client gets the baseline operations; the richer policy is authored through the native API.

The architectural rationale is in the original blog post on rethinking secrets management. The typed-key redesign is covered in the v0.19 release post, and the standard interfaces in Enclave Vaults speaks PKCS#11 and KMIP.