Solution
Enclave Vaults
A distributed virtual HSM, rebuilt for the age of confidential computing. Your keys live inside attested enclaves spread across independent machines. Operations happen inside the hardware, governed by a policy that the silicon itself enforces. No single party, not even us, can use a key without authorisation.
The problem with traditional secrets management.
Centralised trust is a single point of failure
HSMs, cloud KMS, and software vaults all share the same weakness: one master key, one location, one operator. If that operator is compromised, coerced, or simply makes a mistake, every secret protected by that key is exposed.
You have to trust the provider
Cloud KMS encrypts your data with keys you cannot inspect, on infrastructure you cannot verify. You are told your secrets are safe. But you have no way to prove it. Compliance says yes. Cryptography says nothing.
A distributed vHSM, hardware-enforced.
Keys live inside the hardware
Signing keys, encryption keys, MAC keys, and derivation seeds live inside the enclave as typed objects. You ask the vault to sign, encrypt, or derive. By default the raw key material never crosses the enclave boundary, not even to the host or to your own infrastructure team.
Distributed trust where it matters
For the most sensitive shared secrets, every value can be split with Shamir’s Secret Sharing across a constellation of vaults on independent machines. No single vault ever holds enough to reconstruct your secret. Compromising one node reveals nothing.
Programmable policies, enforced by silicon
Each key carries a policy: which identities can use it, which enclaves can call it, which operations are allowed, and whether a fresh human approval from a Privasys Wallet is required. The enclave refuses anything that does not match. There is no admin override.
Live human approvals via your phone
Sensitive operations can require a fresh tap on a registered Privasys Wallet. FIDO2 on your phone produces a signed approval token that the vault verifies inside the enclave. The kind of ceremony that used to need bespoke key-management software is now a policy field.
Mutual attestation on every connection
Every connection to a vault is a mutually attested RA-TLS channel. The client verifies exactly which code is running inside the enclave and which configuration it was launched with. The vault verifies the caller’s attestation in return.
Owner-controlled enclave version changes
When a new version of an application enclave is built, its new identity does not automatically gain access to existing keys. The key owner reviews the change, collects the configured manager approvals, and only then promotes the new measurement into the policy. Shipping new code is the developer’s decision; granting it access to secrets stays the owner’s decision.
What you can do with it.
Protect signing keys for critical artefacts
Release signatures, container image signatures, firmware signatures: keep the signing key in the vault, sign inside the enclave, gate every signature on policy. No more keys lying around in CI runners.
Disk encryption for confidential VMs
Confidential VMs do not have a built-in way to seal data across reboots. Enclave Vaults provides one: store the LUKS key as Shamir shares, recover it at boot through mutual attestation, and never touch the disk on a machine that is not the one you provisioned.
Wrap and unwrap data keys
Use vault-held AES keys to wrap your application’s data encryption keys. Unwrap them only inside enclaves that match the policy. Your data ciphertexts can travel anywhere; they only become readable inside the right hardware, for the right caller.
Secrets for any attested workload
API credentials, OAuth client secrets, database passwords: store them once, retrieve them only from the enclaves your policy allows, with a full audit trail. Secrets stop being a static blob and become a controlled capability.
Honest about the boundaries.
Enclave Vaults is a virtual HSM, not a FIPS 140-3 certified appliance. It does not have tamper-evident enclosures or environmental sensors. What it offers is a different security model: distributed trust enforced by hardware, with cryptographic transparency instead of physical tamper resistance. For most threat models we see in the wild this is a strict improvement over a single appliance you have to take on faith. Where a specific FIPS certification is a hard legal requirement, dedicated certified HSMs remain the right choice. We believe in being precise about the trade-offs.