Post-Quantum Cryptography Migration: Three Readiness Strategies for Legacy Infrastructure

Preparing for post-quantum cryptography is fundamentally an enterprise asset inventory battle, not a mere mathematical algorithm upgrade. You cannot migrate cryptographic systems you cannot find. In most production environments, automated asset discovery and lifecycle classification consume far more time than replacing the underlying algorithm itself.

Post-quantum readiness is typically discussed as a cryptography problem, which is precisely why it often stalls. The algorithms are already standardized and available. But in virtually any large organization, a simpler question cannot be reliably answered: where is cryptography used? By which systems? Involving what key material? Who is the owner of each instance?

This question is answerable. It is not glamorous—it is primarily discovery and asset management work—but it determines whether an actual migration takes quarters or years. Logic42 founder and CEO Asif Muhammad Iqbal systematically lays out the path to solving this problem in his architecture brief.

The Threat That Has Already Arrived

Most cryptographic risks are prospective—they materialize when an attack becomes feasible. But "Harvest-Now-Decrypt-Later" (HNDL) flips this logic. Attackers capture encrypted traffic today, store it, and decrypt it later when capable hardware emerges.

This means that for any data with long-term confidentiality requirements, the exposure window is already open. Traffic recorded this year that needs to remain confidential for a decade is already threatened by a capability that does not yet exist, because the ciphertext is already sitting in someone's archive.

This also means urgency is not uniform. Data with short confidentiality lifetimes (such as session tokens or ephemeral API responses) is largely unaffected. Data with long confidentiality lifetimes (patient records, contract terms, credentials, source code, or anything with regulatory retention requirements) is where the real problem lies. Any plan that treats all encrypted traffic as equally urgent will fail to sequence the work effectively.

Harvest-Now-Decrypt-Later (HNDL) is a special category of quantum threat: it does not require the attacker to possess a quantum computer today. The attacker only needs to passively intercept and store encrypted traffic now, then later—once a cryptographically relevant quantum computer (CRQC) matures—return to break the RSA or ECC keys used at the time with Shor's algorithm. This works because modern public-key cryptosystems rely on the hardness of integer factorization and discrete logarithms, and Shor's algorithm can solve these problems in polynomial time on a sufficiently large quantum computer. The strategic implication is that the threat timeline is not the day the quantum computer arrives, but the day sensitive data is intercepted. For data with long confidentiality periods, the risk window is effectively already open and cannot be retroactively closed by future algorithm upgrades—ciphertext that has already been leaked can never be recovered.

Prioritizing with the Mosca Inequality

There is a clear way to reason about this, commonly known as the Mosca inequality. It involves three quantities:

• X: How long the data needs to remain confidential (confidentiality lifetime)
• Y: How long the migration will actually take
• Z: How long until a cryptographically relevant quantum computer arrives

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

The usefulness of this tool lies in making the argument concrete without requiring anyone to predict Z precisely. You do not need an exact date; you only need to notice that a system holding 15 years of confidential data (X = 15) with a three-year migration (Y = 3) requires Z to exceed 18 years to be safe—a assumption almost no one can defend.

Run this calculation by data category rather than across the entire portfolio. The output is a defensible ranking, which is what the board actually needs.

The Standards Are Mature Enough

NIST finalized the first post-quantum standards in August 2024:

• FIPS 203 (ML-KEM) (derived from CRYSTALS-Kyber), for key encapsulation, replacing the key exchange role currently handled 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, serving as a hedge against structural weaknesses in lattice assumptions.

Standard	Primary Algorithm	Function	Classical Predecessor	Key/Signature Size
FIPS 203	ML-KEM	Key encapsulation	RSA-2048, ECDH	1,184-byte public key / 1,568-byte ciphertext
FIPS 204	ML-DSA	Digital signature	RSA-PSS, ECDSA	1,312-byte public key / 2,420-byte signature
FIPS 205	SLH-DSA	Stateless hash signature	RSA, Ed25519	32-byte public key / ~17KB signature

The practical implication is that "waiting for standards" is no longer a legitimate reason to delay. Especially for key establishment, there is already a clear, standardized, widely implemented answer.

CRYSTALS-Kyber and CRYSTALS-Dilithium are the winning proposals in the post-quantum cryptography standardization race, both based on lattice-based cryptography. Lattice cryptography's security rests on the computational hardness of problems such as Learning With Errors (LWE) and its ring variant (Ring-LWE), for which no known classical or quantum polynomial-time algorithms exist. Kyber is used for key encapsulation mechanisms (KEM), replacing ECDH in scenarios such as TLS handshakes; Dilithium is used for digital signatures, replacing ECDSA and RSA-PSS. SPHINCS+ takes a different route, constructing signatures based on the collision resistance of hash functions, with more conservative security assumptions but at the cost of enormous signature sizes (~17KB). NIST standardized them as FIPS 203, 204, and 205 respectively, marking the transition of post-quantum migration from research to engineering deployment.

Key Exchange: Hybrid Mode First

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

This conservative strategy provides protection in both directions: if the post-quantum algorithm has implementation or analysis flaws, the classical exchange still protects you; if the classical algorithm is broken by quantum attack, the post-quantum algorithm holds the line. Only if both fail simultaneously are you compromised.

Hybrid key exchange has already been deployed at scale in TLS across major browsers and CDNs, meaning the interoperability path is well-trodden rather than theoretical. For most organizations, enabling hybrid key exchange on external-facing TLS is the highest-value early move: it directly closes the HNDL window for traffic in transit, and can often 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 truly resists, for structural rather than organizational reasons.

The size problem. Post-quantum signatures and public keys are much larger than their elliptic curve equivalents. This matters wherever certificate chains have size budgets: TLS handshakes, firmware images with fixed signature fields, smart cards, constrained protocol frames. Some of these have hardcoded assumptions about signature length that predate the tenure of any current employee.

Trust anchors. Migrating root CAs and intermediate CAs is a multi-party, multi-year effort involving parties you do not control. You cannot unilaterally decide that your trust chain is post-quantum.

Long-lived signature artifacts. Code signing, document signing, and audit attestations that need to remain verifiable for decades require a verification path that survives the migration. This is different from encryption and is often forgotten until an auditor raises it.

Hardware constraints. HSM firmware, TPMs, secure elements, and OT devices may require vendor updates that do not yet exist, or require replacing devices that will never receive another firmware update. Industrial and embedded assets should expect to discover that some devices' cryptography will never change, and plan network-layer compensating controls around them.

Trust Anchor is the ultimately trusted root certificate or root key in a public key infrastructure, to which all trust chain verification traces back. In post-quantum migration, replacing trust anchors is far more complex than key exchange: it involves multi-party coordination across root CAs, intermediate CAs, operating system trust stores, browser trust stores, and industry-specific trust systems (such as finance, government, and IoT). Migration of any single link requires cross-organizational negotiation and multi-year planning, and many trust anchors themselves have lifecycles measured in decades. More challenging still, long-lived signature artifacts (such as code signing certificates, document signatures, timestamps, and audit attestations) need to remain verifiable for decades into the future, meaning the signature verification path must handle both post-quantum and traditional signatures while maintaining backward compatibility during the transition. The fundamental difference from the encryption scenario is that encryption only needs to protect current data, while signatures need to protect the verifiability of history.

Cryptographic Agility Is the Real Deliverable

The most common strategic mistake is treating this as a migration to a specific algorithm set. Algorithms will change again. What you are really building is the ability to swap algorithms without rewriting applications.

This capability has recognizable characteristics:

• No algorithm identifiers in application code: Cryptographic operations go through service or library boundaries, and primitive selection is configuration rather than literals.
• Automatic certificate and key provisioning: With short lifetimes and rotation that runs without change requests. Environments that manually install multi-year certificates cannot migrate quickly, because no one knows where they all are.
• Centralized negotiation or configuration of algorithm selection: Making a change a single rollout rather than a release.
• Accurate, well-maintained cryptographic asset inventory: Generated through scanning, not by asking teams to self-report.

Organizations with these characteristics can absorb the next transition as operational work. Those without will run the same project from scratch again.

Cryptographic Agility refers to a system's ability to change underlying cryptographic algorithms without modifying application code—an architectural property repeatedly emphasized but often underestimated in post-quantum migration. It is not a new concept in the post-quantum era—historical transitions from DES to AES and from SHA-1 to SHA-2 exposed the cost of lacking agility, but the scale and complexity of post-quantum migration amplify this problem. Key design principles for achieving agility include: abstracting cryptographic operations into service interfaces, using configuration-driven algorithm selection, adopting short-lived certificates and automated rotation, and maintaining cryptographic asset inventories through technical means (rather than manual reporting). Organizations lacking agility treat every algorithm transition as starting a project from zero; organizations with agility can absorb algorithm changes as routine operational work.

An Actionable Migration Sequence

1. Discover: Scan TLS endpoints, certificates, key stores, HSM-held keys, database and disk encryption, signing pipelines, VPN and SSH configurations, and embedded credentials. Generate an inventory; do not rely on questionnaires. Expect results to disagree with your CMDB.
2. Classify by confidentiality lifetime: Attach an X value to each data category in the inventory. This is a business conversation, not a security conversation, and it is the most commonly skipped step.
3. Rank with Mosca: Rank by X + Y against a Z you are willing to defend. Publish the ranking.
4. Enable hybrid key exchange at the edge: Prioritize external-facing TLS. Highest risk reduction per unit effort, and it closes the collection window for traffic in transit.
5. Fix agility where it is cheapest: Automate certificate issuance and rotation for systems you are already touching for other reasons, and remove hardcoded algorithm references.
6. Plan signatures deliberately: Trust anchors, code signing, and long-lived attestations follow their own multi-year track. Identify vendor dependencies early.
7. Isolate what cannot be migrated: Some hardware will never be updated. Compensate at the network layer and explicitly document accepted risk rather than leaving it undocumented.

Anti-Patterns to Avoid

• Treating it as a cryptography project: It is primarily discovery, asset management, and vendor coordination.
• Uniform urgency: Ranking by confidentiality lifetime is the entire point; without it, you will spend early effort on ephemeral data.
• Waiting for more certainty about Z: The Mosca inequality is designed for making decisions without an exact date.
• Post-quantum only, no hybrid: Abandoning defense in depth during the period when new primitives are least battle-tested.
• Self-reported inventories: Teams do not know where all their keys are. Automated scanning finds what questionnaires miss.
• Ignoring long-lived signatures: Encryption gets attention; verification of signature artifacts from a decade ago is the thing that surprises you.
• Rip and replace: Guarantees the project will still be underway when requirements change again.

Key Takeaways

No one can credibly tell you when Z arrives. This is not the obstacle it appears to be, because the first three steps (inventory, classification, and edge hybrid key exchange) are worth doing regardless. They improve certificate hygiene, expose unmanaged key material, and reduce current risks unrelated to quantum computing.

The organizations that handle this well are not those that pick the right algorithm, but those that can change algorithms on demand—and know exactly where they need to be changed.

One-line Summary

The essence of post-quantum cryptography migration is an asset discovery and management battle, and cryptographic agility is the real deliverable.

Paragraph Summary

Post-quantum cryptographic readiness is often mistaken for an algorithm upgrade problem, but it is primarily asset discovery and management work—in large organizations, finding where cryptographic systems are located takes far more time than replacing the algorithms themselves. HNDL (Harvest-Now-Decrypt-Later) attacks mean the exposure window for long-term confidential data is already open, and migration priorities can be ranked by data category using the Mosca inequality (X + Y > Z). NIST finalized three post-quantum standards—FIPS 203/204/205—in 2024, and key exchange already has a mature hybrid deployment approach (ECDH + ML-KEM), making it the highest-value early action. However, digital signature migration faces structural obstacles including size inflation, multi-party control of trust anchors, long-lived signature verification paths, and non-updatable hardware, making it far more complex than key exchange. The organization's real deliverable is cryptographic agility—the ability to swap algorithms without rewriting applications.