post-quantum HSM

Post-quantum key management: why algorithms aren't enough

Most post-quantum migration plans focus on swapping algorithms, RSA and ECC out, ML-KEM and ML-DSA in. That is necessary work. It also leaves the deeper assumption untouched: that cryptographic keys exist at rest. Any key sitting in storage today is a candidate for harvest-now-decrypt-later, and 'we will rotate it before quantum is real' is a calendar bet, not an architecture. The durable answer is to stop storing keys at all.

By Sue Pontius, Chief Executive Officer, Lokblok · Published 22 April 2026

Algorithm agility solves half the problem

NIST's post-quantum standardisation gives the industry a concrete migration target: by some date, every long-lived key should use a quantum-resistant algorithm. Crypto-agile HSMs and KMS products make the swap mechanically possible. None of this addresses what happens to the keys that are stored today.

Adversaries with significant collection budgets do not need to wait for quantum hardware to extract value. They need to record encrypted traffic and capture key material now. Encrypted backups, KMS-wrapped blobs, MPC share stores, and archived TLS sessions are the harvest-now-decrypt-later targets. The fix is not 'rotate to PQ', the rotated key is still stored, and the previously stored ciphertext is already in the adversary's hands.

Post-quantum HSMs also still concentrate risk: a single device boundary protecting a key for years is the same architecture, with a different algorithm inside.

Remove the harvest target

If the key does not exist at rest, there is nothing to harvest. Zero-persistence reconstruction stores only public Regen Tokens and reconstructs the operating key inside a secure element only at the instant of use. An adversary who records the network sees ciphertext; an adversary who breaches the storage layer finds public material with no cryptographic value.

The model is also algorithm-neutral. The threshold primitive can derive ECC keys today and ML-DSA keys tomorrow without re-architecting the surrounding system. Crypto-agility becomes a property of the runtime, not a multi-quarter migration project.

Side by side

DimensionConventional approachZero-persistence reconstruction
Harvest-now-decrypt-later exposureAll currently stored keys are at riskNothing stored to harvest
Algorithm migrationRe-key, re-distribute, re-attest every keySwitch the derivation algorithm in the runtime
Long-lived key lifetimesYears per keyMilliseconds per use
PQ HSM costNew hardware fleetSoftware upgrade to existing secure elements
Quantum break windowAll historic ciphertext signed under the broken algorithm becomes forgeableOnly signatures issued during the vulnerable window are exposed

What this looks like in practice

  • A telecom operator with subscriber identity keys stops worrying about SIM-vault harvesting because each authentication derives an ephemeral subscriber key inside a quorum-bound element.
  • A government PKI decouples PQ migration from key rotation, the same signing service can serve ECC and ML-DSA in parallel for years without holding both keys at rest.
  • A long-tail TLS workload halves its rotation budget because there is no key to rotate, only a derivation parameter.

Related Lokblok material

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

Do I still need post-quantum algorithms if there is no key at rest?
Yes, for signature verification on existing chains, for traffic in flight, and for the threshold primitive itself. Zero-persistence does not replace post-quantum algorithms; it removes the harvest-now-decrypt-later attack against keys that would otherwise sit in storage waiting for a quantum break.
What about historic ciphertext I have already encrypted with ECC?
Anything already encrypted with a quantum-vulnerable algorithm and held by an adversary is exposed when quantum hardware arrives. Zero-persistence reconstruction does not retroactively repair this; it stops the bleeding for everything you do from now on.
Can I migrate from a conventional HSM in place?
Phantom Secrets™ runs as a software layer on top of FIPS-certified secure elements, including modern HSMs. The migration path is to introduce zero-persistence operations alongside existing stored-key operations, then ramp down the stored keys as workloads move over.
How does crypto-agility actually work at the runtime layer?
The runtime decouples the key-derivation algorithm from the calling application. Switching from ECC to ML-DSA changes which primitive the secure element invokes during reconstruction; the orchestration layer, the recovery agents, and the audit chain are unchanged.

Related insights