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. And your existing software can reach it through the interfaces it already speaks: PKCS#11, KMIP, and a REST API.
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.
Standard interfaces, novel core.
The parts that make this vault different, policy principals bound to attested measurements, per-operation approvals from your phone, and Shamir custody across independent machines, live in no standard. So we keep that core as it is and wrap the interfaces your tools already speak around it. Your software talks a familiar protocol; the attested policy engine underneath does the work no HSM standard can express.
PKCS#11 for any crypto application
A PKCS#11 provider module lets OpenSSL, Java, TLS servers, and code-signing tools use a vault-held key with no change to the application. We ran a TLS server whose private key never left the enclave: every handshake signature happens inside the hardware, and the client still verifies the certificate as normal.
KMIP for enterprise key management
A KMIP 2.1 gateway lets existing enterprise key-management software point at the constellation and use it as a remote key manager, unchanged. The gateway itself runs as an attested confidential workload, so there is no plaintext hop between the client and the enclave.
A REST API and a CLI
Create a vault, add keys, sign, wrap, and rotate through a REST API shaped like the cloud KMS surfaces developers already know, or from the command line with the Privasys CLI. The API is a client-side proxy, so the data plane stays a direct, attested channel to the enclave.
Anyone can own keys
Key custody is no longer reserved for platform enclaves. A developer can create a vault, hold signing and wrapping keys in it, and author the policy that governs them, with the same attested guarantees the platform uses for its own secrets.
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.
Electronic signatures and seals with legal effect
Sign documents and seal artefacts with keys the vault holds. Under eIDAS, an electronic signature or seal cannot be denied legal effect in an EU court merely because it is electronic or not qualified. Policy-enforced sole control, per-signature wallet approvals, and tamper-evident results support the Regulation’s criteria for advanced signatures and seals.
The boundaries.
Enclave Vaults is a virtual HSM, not a FIPS 140-3 certified appliance. It has no tamper-evident enclosure and no environmental sensors. Its security model rests on hardware isolation, on attested identity for every connection, and, for distributed secrets, on the unlinkability of Shamir shares across independent enclaves. For most threat models we see in the wild this improves on 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.
The same honesty applies to eIDAS. Enclave Vaults is not a qualified trust service, and a vault signature does not carry the legal presumption a qualified one enjoys. What it carries is evidence, chained to roots a court already recognises: the silicon vendor’s attestation for which code ran, certified secure elements on the signer’s phone for sole control, and, when the signer’s identity is verified through the Privasys Wallet, the government’s own passport PKI for who signed. The only uncertified link is our open-source code, and it is reproducible: an independent expert can verify it instead of taking it on faith. Where the law mandates a qualified signature, use one. For everything else, we think evidence a court can examine beats a certificate it has to trust.
The standard interfaces come with a deliberate limit too. PKCS#11 and KMIP clients cannot present a wallet approval or reason about attested measurements, so operations a key gates on those conditions are simply unavailable over those interfaces, by design. A standard client gets the baseline operations; the richer policy is authored through the native API.