No attest, No Key: Why Sovereign Key Custody Needs Remote Attestation

Imagine you run security at a bank. You moved your payment service to the cloud last year. Your keys live in a vault, and you generated every one of them yourself. On paper, you own them.
‍

Now imagine a Tuesday night. Someone phishes a platform admin. The attacker opens a shell on a node, copies the service credential, and asks the vault for the signing key. The vault checks the credential. It is valid. The key comes out. Nobody changed a single line of your code, and nobody broke your encryption. The vault did exactly what it was built to do: trust whoever shows the right badge.
‍

Auditors have started asking about that Tuesday night. NIS2 and DORA want you to constrain privileged access and prove it. Encryption at rest and in transit does not answer their question: while the data is in use, who can reach it, and can you show that only approved code did? This is the story of how enclaive vHSM answers it. Attestation is built into vHSM: a key leaves the vault only when the workload proves what it is, and the same control runs across cloud and on-prem, clustered for HA, with every decision logged as audit evidence.
‍

Ownership is not control
‍

Think of a key like a house key. Bring Your Own Key means you cut it yourself. Hold Your Own Key means you keep it in your own pocket instead of the landlord’s drawer. Both answer the question “whose key is this?” Neither answers “who gets to open the door, and when?”
‍

That second question is where sovereignty lives or dies. If a hyperscaler admin can walk up and get the door opened anyway, your pocket does not matter. vHSM separates two roles that usually blur together: the operator who runs the building and the authority who decides who gets in. The decision never looks at a login. It looks at what is standing at the door.
‍

How attestation-gated release works
‍

Picture your payment service starting up inside a confidential environment. It needs its signing key. Here is what happens in the seconds before it gets one.
‍

1. Evidence. The CPU takes a fingerprint of everything that booted: boot chain, kernel, the exact image of your service. It signs that fingerprint in hardware. No software on the machine can fake it.
   ‍
2. Verification. Nitride looks at the fingerprint and compares it with what you approved: this image hash, this configuration, this policy version. It answers pass or fail and hands over the verified claims.
   ‍
3. Policy. Vault, running inside vHSM, reads your rule: which fingerprints may hold this key, in which environment. The default answer is no.
   ‍
4. Release and log. The fingerprint matches, the key goes to that one workload. It does not match, nothing leaves. Either way, Vault writes down the decision, the claims, and the policy version in a log nobody can edit.
   
   ‍

‍

Go back to that Tuesday night. The attacker has the admin shell and the stolen credential. They ask for the key. Nitride sees a fingerprint that does not match any approved image, because the attacker’s tooling changed the runtime. Step 2 fails. The key stays put, and the log records who asked and why they were refused. The admin could start the workload. They could never collect its key.
‍

What it blocks
‍

Every security architect carries the same short list of nightmares: someone execs into a container, opens a node shell, snapshots a disk, dumps memory. Attestation-gated release does not try to close every one of those doors. It makes sure nothing worth stealing is behind them.
‍

• The stolen credential. Imagine the attacker cloning your service to another host and replaying the credential. Wrong fingerprint, no key.
  ‍
• The poisoned dependency. Imagine a library in your build gets tampered with upstream. The image hash changes. Verification fails before the workload ever sees a production secret.
  ‍
• The operator. Imagine the hyperscaler’s own staff, a managed Kubernetes operator, or your own platform team. None of them has a path that satisfies the policy, because the policy never asks who they are.
  ‍
• The slow drift. Imagine a config change six months from now that nobody reviewed. Attestation runs continuously, so the drifted workload loses its key instead of keeping it quietly.
  ‍

Evidence your auditor can read
‍

Now imagine audit week. Your GRC lead used to spend it collecting screenshots and writing narratives about controls. This time she opens the release log. It shows which code ran, where it ran, under what trust state, and which key it received. enclaive maps those entries to PCI DSS requirements and GDPR security principles and exports them in a form humans read and a form your SIEM and GRC tools ingest.
‍

Two numbers tell her the story: the share of sensitive workloads using customer-held keys with attestation-gated release, and the hours it takes to answer an auditor’s request for key-access evidence.
‍

Common objections
‍

“We already run a secrets manager.” Keep it. It checks the badge. Attestation checks the face behind the badge, and gates the key on that.
‍

“We scan images in CI.” Good, that is the photo at the entrance. Attestation checks who showed up at runtime, where the admins and the infrastructure are the ones you cannot fully trust.
‍

“Our threat model trusts cloud admins.” Then write down the Tuesday-night scenario and ask your auditor to sign it. Most NIS2 and DORA programmes no longer accept that residual risk.
‍

“We cannot replace our certified HSMs.” Nobody is asking you to. Phase one plugs into the HSM estate you run today and keeps its processes. vHSM adds attested custody for the cloud and Kubernetes workloads a physical appliance cannot reach, one workload at a time, with rollback.
‍

Where to start
‍

enclaive’s adoption path starts with key custody for a reason: it gives you an audit-defensible win inside 90 days without touching application code. Pick the workloads where admin access is an open finding. Define the fingerprints you approve. Set the policy to deny by default. Then watch the log fill up with refusals you never had to think about.
‍

Want to watch a tampered workload ask for a key and get nothing? Book a 30-minute demo of attestation-gated release.
‍

‍