zero-trust key management
Zero-trust key management: extending Never Trust, Always Verify into the cryptographic layer
Zero-trust networking dismantled the idea that a corporate perimeter could be trusted. Every request is authenticated, every device is attested, every session is short-lived. The cryptographic layer underneath has not yet caught up. We still build key-management systems on the assumption that a 'trusted key store' exists. A zero-trust key model rejects that assumption: no store is trusted, no key is allowed to persist between authorised events, and every signing operation is verified end-to-end before any key material exists.
By Sue Pontius, Chief Executive Officer, Lokblok · Published 22 April 2026
Why 'trusted key store' is an oxymoron
A trusted store has the same problem as a trusted network: it concentrates value, becomes a target, and converts every breach into a catastrophic loss. The fact that the store is an HSM or a KMS or an MPC share-cluster does not change the structural property, there is a place an attacker can aim at, and the value of compromising it grows with every key it holds.
Operationally, the 'trust' in trusted store is process trust: the operators are vetted, the access is logged, the rotations are scheduled. Zero-trust networking spent a decade arguing that process trust is necessary but never sufficient. The same argument applies to keys.
Verify the request, then reconstruct
Zero-trust key management treats every signing or decryption call the way zero-trust networking treats every connection. The identity of the caller is verified, the device is attested, the policy is evaluated, and a quorum of independent recovery agents authorises the specific operation. Only then are ephemeral shares derived inside the secure element that will use them; the resulting key exists for one operation and is destroyed before the response is returned.
Between operations there is no key store to harden, no perimeter to defend, and no privileged operator to monitor. The trust boundary collapses to the per-operation cryptographic chain, which is verifiable after the fact by anyone with the public attestation material.
Side by side
| Dimension | Conventional approach | Zero-persistence reconstruction |
|---|---|---|
| Trust model | Trusted store + procedural controls | No trusted store; per-operation attestation |
| Persistent target | Yes, the store itself | No, only public material at rest |
| Operator authority | Privileged access to read or assemble keys | None outside the authorised event |
| Identity binding | External (the operator says who is calling) | Built into the cryptographic chain |
| Audit | Log review | Cryptographic verification |
What this looks like in practice
- An enterprise issuing internal code-signing keys stops needing a hardened build-server bastion because the signing key only exists for the build-step that requested it, with the requesting CI job's identity bound into the attestation chain.
- A privileged-access management platform replaces the long-lived SSH CA key with a per-session reconstruction, so a compromise of the PAM server cannot mint backdoor certificates.
- A regulated workload with strict separation-of-duties requirements encodes the duty separation into the recovery-agent quorum directly: no signature exists unless the required roles each contributed.
Related Lokblok material
- the zero-persistence cryptographic architecture in detail
- enterprise-wide zero-trust key controls
- Phantom Gate™ for service-to-service zero-trust access
About the author
Sue Pontius
Chief Executive Officer, Lokblok
Sue Pontius is CEO of Lokblok, where she leads the company's work on zero-persistence cryptography for digital assets, identity, and high-assurance custody.
View LinkedIn profile →FAQ
- How does zero-trust key management relate to zero-trust networking?
- They share the same principle: never assume safety based on location. Zero-trust networking removes the trusted perimeter; zero-trust key management removes the trusted key store. Both replace a positional trust model with a per-event verification model that does not rely on any zone being inherently safe.
- Doesn't this just move trust to the recovery agents?
- It distributes trust to a quorum of independent recovery agents, none of which holds anything useful on its own. The trust model is a threshold: a sufficient subset of agents must authorise an operation, and any single agent can be compromised without affecting the system. This is structurally different from trusting any single store or operator.
- Is this compatible with existing zero-trust frameworks like BeyondCorp or NIST 800-207?
- Yes. Zero-trust frameworks describe the verification model for access; zero-trust key management plugs into the same identity, device, and policy signals and uses them to authorise the cryptographic operation as well as the network access.
- How is the per-operation attestation produced?
- Each step of the workflow, caller authentication, device attestation, policy evaluation, quorum vote, secure-element operation, signature emission, produces a signed record that links to the previous step. The chain is the audit artefact and is verifiable independently of the system that produced it.