Preparing for Q-Day: A Post-Quantum Cryptography Migration Playbook

Post-quantum migration is frequently deferred on the reasoning that cryptographically relevant quantum computers do not yet exist. That reasoning fails for a specific and well-understood reason: encrypted traffic captured today can be stored and decrypted later. For any data whose confidentiality must outlast the arrival of such a machine, the exposure has already begun.

The inequality that determines your deadline

Mosca's inequality frames the decision precisely, and it turns an unanswerable question about quantum timelines into an answerable question about your own data and your own systems.

Z is genuinely uncertain and nobody can supply it. X and Y are not — they are properties of your business, and both are usually larger than people assume. Medical records, government material, long-term contracts and identity documents carry X measured in decades. Y, for an enterprise that does not know where all its cryptography lives, is comfortably five to ten years. With X + Y frequently exceeding thirty years, the inequality holds under almost any credible estimate of Z.

What quantum computing actually breaks

The threat is not uniform, and treating it as such produces both wasted effort and missed exposure.

The practical summary: every public-key algorithm in production must be replaced, and symmetric cryptography needs only larger parameters. That is a smaller problem than it sounds and a much larger one, because public-key cryptography is embedded in every protocol, certificate, signed artefact and hardware root of trust in the estate.

The standards exist, which removes the remaining excuse

NIST completed its selection process and published final standards: ML-KEM for key encapsulation, ML-DSA for digital signatures, and SLH-DSA as a hash-based signature alternative whose security rests on different assumptions from the lattice-based schemes. Deployment is no longer blocked on standardisation.

The engineering consequence is size. Post-quantum keys, ciphertexts and signatures are substantially larger than their elliptic-curve equivalents, and that lands on protocols, packet sizes and storage.

These sizes have consequences that are easy to miss until integration. A TLS ClientHello carrying a post-quantum key share may exceed a single packet, and some middleboxes handle that badly. Constrained IoT devices with kilobytes of RAM may not hold a certificate chain at all. DNSSEC responses risk fragmentation. Each is solvable, and each is discovered late by teams that treated migration as an algorithm substitution.

Hybrid first, because it is the only option that fails safely

The lattice problems underpinning ML-KEM have been studied for decades but have far less deployment history than elliptic curves, and a classical cryptanalytic advance against them is not impossible. Hybrid key exchange removes the need to bet either way: perform both a classical and a post-quantum exchange and combine the results, so the session is secure unless both are broken.

Confidentiality should move to hybrid now. Signatures are less urgent — a signature forged in 2040 cannot retroactively compromise a session from 2026 — but long-lived trust anchors are the exception, because a root certificate or firmware signing key issued today may still be validating in twenty years.

Firmware signing deserves separate treatment

A device shipping today with an ECDSA root of trust burned into fuses cannot have that root replaced in the field. If the device is still deployed when the algorithm falls, it can no longer verify updates — which is to say it can no longer be patched, permanently.

Stateful hash-based signatures are the mature answer for this specific case. Their security depends only on the hash function, with no new mathematical assumption, and they are standardised for exactly this use. The cost is real: they are stateful, and reusing a one-time key catastrophically breaks the scheme, so key state management must be correct with no margin for error. For a signing operation that happens in a controlled facility a few times a year, that is an acceptable constraint — and provisioning a post-quantum trust anchor alongside the classical one at manufacture is far cheaper than the alternative.

Start with the inventory, because you cannot migrate what you cannot find

The first deliverable is not a new algorithm. It is a cryptographic bill of materials: every place the organisation uses public-key cryptography, what algorithm, what key length, what data it protects, how long that data must stay confidential, and who owns it. Most enterprises cannot produce this document, and producing it routinely surfaces hardcoded keys, unowned certificates, expired-but-still-trusted anchors and protocol implementations nobody remembers deploying.

Then prioritise by X — data lifetime — rather than by system importance. A payment system with a fifteen-minute confidentiality requirement is far less exposed to harvest-now-decrypt-later than an archive of employee records nobody considers critical. And build for crypto-agility as you go, because the actual lesson of this migration is that there will be another one, and organisations that can change algorithm without changing application will spend a fraction of what everyone else does.