Post-Quantum Cryptographic Readiness for Legacy Infrastructure

You cannot migrate cryptography you cannot find. In most enterprise estates, the inventory takes longer than the migration.

Post-quantum readiness is usually discussed as a cryptography problem, which is why it usually stalls. The algorithms are standardised and available. What is not available, in almost any large organisation, is a reliable answer to a simpler question: where is cryptography used, by which systems, with which key material, and who owns each instance?

That question is answerable. It is also unglamorous, largely a discovery and asset-management exercise, and it determines whether the actual migration takes quarters or years.

The threat that is already running

Most cryptographic risk is prospective — it materialises when the attack becomes feasible. Harvest-now-decrypt-later inverts that. An adversary captures encrypted traffic today, stores it, and decrypts it when capable hardware exists.

This means the exposure window for anything with a long confidentiality requirement has already opened. Traffic recorded this year that must remain secret for a decade is at risk from a capability that does not yet exist, because the ciphertext is already in someone's archive.

It also means the urgency is not uniform. Data with a short secrecy lifetime — a session token, an ephemeral API response — is largely unaffected. Data with a long one — patient records, contract terms, credentials, source code, anything with regulatory retention — is where the actual problem lives. Any programme that treats all encrypted traffic as equally urgent will sequence its work badly.

Deciding what is urgent

There is a clean way to reason about this, usually called Mosca's inequality. Three quantities:

X — how long your data must remain confidential (the secrecy lifetime).
Y — how long your migration will realistically take.
Z — how long until a cryptographically relevant quantum computer exists.

If X + Y > Z, you are already late for that data class.

The useful property is that it makes the argument concrete without requiring anyone to predict Z precisely. You do not need a date. You need to notice that a system holding 15-year-confidential data (X = 15) that will take three years to migrate (Y = 3) needs Z to be more than 18 years away to be comfortable — and almost nobody is willing to defend that number.

Run this per data class rather than for the estate. The output is a defensible sequencing order, which is the thing a board actually needs.

The standards are settled enough to build on

NIST finalised its first post-quantum standards in August 2024:

FIPS 203 — ML-KEM (derived from CRYSTALS-Kyber), for key encapsulation. This replaces the key-exchange role currently played by ECDH and RSA.
FIPS 204 — ML-DSA (derived from CRYSTALS-Dilithium), for digital signatures.
FIPS 205 — SLH-DSA (derived from SPHINCS+), a hash-based signature scheme with different trade-offs, useful as a hedge against structural weaknesses in lattice assumptions.

The practical implication is that "waiting for the standards" is no longer an available reason to defer. Key establishment in particular has a clear, standardised, widely-implemented answer.

Hybrid first, for key exchange

For data in transit, the established migration pattern is hybrid key establishment: perform a classical exchange (ECDH) and a post-quantum one (ML-KEM) and derive the session key from both.

The reasoning is conservative in both directions. If the post-quantum algorithm turns out to have an implementation or analysis flaw, the classical exchange still protects you. If the classical algorithm falls to quantum attack, the post-quantum one does. You are only broken if both fail.

Hybrid key exchange is already deployed at scale in TLS by major browsers and CDNs, which means the interoperability path is trodden rather than theoretical. For most organisations, enabling hybrid key exchange on externally-facing TLS is the highest-value early move: it directly closes the harvest-now-decrypt-later window on traffic in flight, and it can usually be done at the load balancer or CDN edge without touching application code.

Signatures are the harder half

Key establishment is tractable. Signatures are where legacy infrastructure genuinely resists, for reasons that are structural rather than organisational.

Size. Post-quantum signatures and public keys are substantially larger than their elliptic-curve equivalents. That matters wherever a certificate chain has a size budget: TLS handshakes, firmware images with fixed signature fields, smartcards, constrained protocol frames. Some of these have hardcoded assumptions about signature length that predate anyone currently employed.

Trust anchors. Root and intermediate CA migration is a multi-party, multi-year exercise involving parties you do not control. You cannot unilaterally decide your trust chain is post-quantum.

Long-lived signed artefacts. Code signing, document signing, and audit attestations that must remain verifiable for decades need a verification path that survives the migration. This is a different problem from encryption, and it is frequently forgotten until an auditor asks.

Hardware. HSM firmware, TPMs, secure elements, and OT devices may need vendor updates that do not exist yet — or replacement, for equipment that will never receive another firmware update. Industrial and embedded estates should expect to find devices whose cryptography will simply never change, and to plan compensating network-level controls around them instead.

Crypto-agility is the actual deliverable

The most common strategic error is scoping this as a migration to a specific set of algorithms. The algorithms will change again. What you are actually building is the capability to change them without an application rewrite.

That capability has recognisable properties:

No algorithm identifiers in application code. Cryptographic operations go through a service or library boundary; the choice of primitive is configuration, not a literal.
Certificates and keys are provisioned automatically, with short lifetimes and rotation that runs without a change request. Estates with manually-installed multi-year certificates cannot migrate quickly regardless of intent, because nobody knows where they all are.
Algorithm choice is negotiated or configured centrally, so a change is a rollout rather than a release.
An accurate, maintained inventory of cryptographic assets, generated by scanning rather than by asking teams to self-report.

An organisation with these properties can absorb the next transition as operational work. One without them will run this same programme again from the beginning.

A workable sequence

Discover. Scan for TLS endpoints, certificates, key stores, HSM-held keys, database and disk encryption, signing pipelines, VPN and SSH configuration, and embedded credentials. Generate the inventory; do not survey for it. Expect the result to disagree with your CMDB.
Classify by secrecy lifetime. Attach an X value to each data class the inventory touches. This is a business conversation, not a security one, and it is the step most often skipped.
Sequence with Mosca. Rank by X + Y against a Z you are willing to defend. Publish the ranking.
Enable hybrid key exchange at the edge. Externally-facing TLS first. Highest risk reduction per unit of effort, and it closes the harvesting window on traffic in flight.
Fix agility where it is cheapest. Automate certificate issuance and rotation, and remove hardcoded algorithm references, in the systems you are already touching for other reasons.
Plan signatures deliberately. Trust anchors, code signing, and long-lived attestations on their own multi-year track, with vendor dependencies identified early.
Ring-fence what cannot move. Some hardware will never update. Compensate at the network layer and record the accepted risk explicitly rather than leaving it undocumented.

Anti-patterns

Treating it as a cryptography project. It is predominantly discovery, asset management, and vendor coordination.
Uniform urgency. Sequencing by secrecy lifetime is the entire point; without it you spend early effort on ephemeral data.
Waiting for more certainty about Z. Mosca's inequality is designed to make the decision without a date.
Post-quantum only, no hybrid. Discards defence in depth during precisely the period when the new primitives are least battle-tested.
Self-reported inventory. Teams do not know where all their keys are. Scanning finds what surveys miss.
Ignoring long-lived signatures. Encryption gets the attention; verification of decade-old signed artefacts is the one that surprises people.
Rip and replace. Guarantees the programme is still mid-flight when requirements change again.

The honest summary

Nobody credible can tell you when Z arrives. That is not the obstacle it appears to be, because the first three steps — inventory, classification, and enabling hybrid key exchange at the edge — are worth doing regardless of the answer. They improve certificate hygiene, surface unmanaged key material, and reduce present-day risk from causes that have nothing to do with quantum computing.

The organisations that will handle this well are not the ones that pick the right algorithms. They are the ones that can change algorithms on demand, and know exactly where they would need to.