Originally published by **Asif Muhammad Iqbal (Founder & CEO at Logic42)* at https://logic42.ai/articles/enterprise-cyber-resilience-post-quantum.*
Post-Quantum Cryptographic Readiness for Legacy Infrastructure
Post-quantum cryptographic readiness is an enterprise inventory challenge before it is a mathematical upgrade. You can't migrate cryptography you can't find. In most production estates, automated asset discovery and lifecycle classification take significantly longer than swapping the underlying algorithms.
Post-quantum readiness is usually discussed as a cryptography problem, which is why it usually stalls. The algorithms are standardised and available. What isn't 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's also unglamorous, largely a discovery and asset-management exercise, and it determines whether your 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 urgency isn't uniform. Data with a short secrecy lifetime (such as session tokens or ephemeral API responses) is largely unaffected. Data with a long one (patient records, contract terms, credentials, source code, or anything with regulatory retention) is where the actual problem lives. Any programme that treats all encrypted traffic as equally urgent won't sequence its work effectively.
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're already late for that data class.
The useful property is that it makes the argument concrete without requiring anyone to predict Z precisely. You don't need an exact 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 can defend that assumption.
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.
| Standard | Primary Algorithm | Function | Classical Predecessor | Key / Signature Footprint |
|---|---|---|---|---|
| FIPS 203 | ML-KEM (CRYSTALS-Kyber) | Key Encapsulation (KEM) | RSA-2048, ECDH (P-256) | 1,184-byte public key / 1,568-byte ciphertext |
| FIPS 204 | ML-DSA (CRYSTALS-Dilithium) | Primary Digital Signatures | RSA-PSS, ECDSA | 1,312-byte public key / 2,420-byte signature |
| FIPS 205 | SLH-DSA (SPHINCS+) | Stateless Hash Signatures | RSA, Ed25519 (Conservative fallback) | 32-byte public key / ~17KB signature |
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're 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 don't control. You can't 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's frequently forgotten until an auditor asks.
Hardware. HSM firmware, TPMs, secure elements, and OT devices may need vendor updates that don't exist yet, or replacement, for equipment that will never receive another firmware update. Industrial and embedded estates should expect to find devices whose cryptography won't ever 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're 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 can't 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; don't 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's the step most often skipped.
- Sequence with Mosca. Rank by X + Y against a Z you're 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're 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's 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 an exact 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 don't know where all their keys are. Automated 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.
What Is Harvest-Now-Decrypt-Later (HNDL) and Why Is It Urgent Today?
Harvest-Now-Decrypt-Later (HNDL) is an active surveillance strategy where adversaries intercept and store encrypted enterprise network traffic today to decrypt it once cryptographically relevant quantum computers (CRQCs) arrive. Organizations handling sensitive data with a secrecy lifetime exceeding five to ten years face immediate exposure because captured ciphertexts cannot be retroactively protected.
The Takeaway
Nobody credible can tell you when Z arrives. That isn't the obstacle it appears to be, because the first three steps (inventory, classification, and edge hybrid key exchange) 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 aren't the ones that pick the right algorithms. They're the ones that can change algorithms on demand, and know exactly where they need to.
Run the Interactive ISO/IEC 27001:2022 & Sovereign AI Workload Security Audit
Evaluating this architectural bottleneck in production? Benchmark your stack in 3.5 minutes with instant Stage 1 blocker detection and a downloadable boardroom PDF dossier:
👉 Launch the Diagnostic on Logic42 (https://logic42.ai/assessments/iso-27001)
Or model your 2026 frontier MoE HBM3e VRAM residency and 24-month bare-metal payback:
🧮 Sovereign MoE VRAM & GPU Repatriation Calculator (https://logic42.ai/assessments/gpu-tco)
Top comments (0)