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

> Migrating to post-quantum algorithms is necessary but not sufficient. Stored keys remain a harvest-now-decrypt-later target until you remove the storage assumption itself.

*Primary query: post-quantum HSM. Last updated 2026-04-22.*

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.

## 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

| Dimension | Conventional approach | Zero-persistence reconstruction |
| --- | --- | --- |
| Harvest-now-decrypt-later exposure | All currently stored keys are at risk | Nothing stored to harvest |
| Algorithm migration | Re-key, re-distribute, re-attest every key | Switch the derivation algorithm in the runtime |
| Long-lived key lifetimes | Years per key | Milliseconds per use |
| PQ HSM cost | New hardware fleet | Software upgrade to existing secure elements |
| Quantum break window | All historic ciphertext signed under the broken algorithm becomes forgeable | Only 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

- [quantum-resistant key management without persistent secrets](https://www.lokblok.co/features/quantum-resistance)
- [the algorithm-agile threshold runtime](https://www.lokblok.co/architecture)
- [Phantom Secrets™ as a runtime layer for any HSM or secure element](https://www.lokblok.co/products/phantom-secrets)

## 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

- [How to eliminate stored private keys: a practitioner's guide](https://www.lokblok.co/insights/eliminate-stored-private-keys)
- [HSM vs MPC vs zero-persistence: a decision framework](https://www.lokblok.co/insights/hsm-vs-mpc-vs-zero-persistence)