./resources / blog

Preparing for Post-Quantum Cryptography

A cryptographically relevant quantum computer does not exist yet — but the data it would decrypt is being collected today. That single asymmetry, "harvest now, decrypt later," is why post-quantum migration is a present-tense problem, not a future one, and why the work should already be on your roadmap.

Most of the cryptography protecting the internet — the key exchange and digital signatures behind TLS, VPNs, code signing, and PKI — rests on a small set of hard mathematical problems: integer factorisation and discrete logarithms. A sufficiently large, fault-tolerant quantum computer running Shor's algorithm could solve those problems efficiently, breaking RSA and elliptic-curve cryptography outright. Symmetric cryptography like AES fares better; Grover's algorithm weakens it, but doubling key sizes restores the margin. The acute risk is concentrated in the public-key algorithms we rely on for key establishment and signatures.

PQC migration timeline Inventory crypto in use Assess Risk data lifetime Crypto-Agility swap-ready Hybrid classical + PQC Full PQC quantum-safe Today's encrypted data recorded now, stored for later Harvest-Now, Decrypt-Later Preemptive Cyber Security
Figure 1. The phased path to quantum-safe — while the "harvest now, decrypt later" arrow siphons today's traffic against a future break.

Harvest now, decrypt later

The reason this cannot wait for the hardware to arrive is an adversary strategy known as harvest now, decrypt later. An attacker records encrypted traffic today — VPN sessions, TLS connections, exfiltrated ciphertext — and simply stores it, betting that a future quantum computer will unlock it. For data with a long confidentiality lifetime, the threat is already live: anything that must stay secret for ten or twenty years, such as state secrets, health records, or intellectual property, is exposed the moment it crosses a network that an adversary can capture.

The clock that matters is not "when will a quantum computer exist" but "how long must this data stay secret, plus how long migration will take." If those two exceed the time until a break, you are already late.

This framing, sometimes called Mosca's inequality, is the heart of the urgency. Migration across a large enterprise takes years; long-lived secrets need to outlast that. Subtract one from the other and, for many organisations, the safe start date was already in the past.

The NIST post-quantum standards

After a multi-year public competition, the U.S. National Institute of Standards and Technology finalised the first post-quantum cryptography standards in 2024. They are built on mathematics believed to resist both classical and quantum attack — chiefly structured lattices. The headline standards are ML-KEM (FIPS 203, a key-encapsulation mechanism derived from CRYSTALS-Kyber) for key establishment, and ML-DSA (FIPS 204, derived from CRYSTALS-Dilithium) together with SLH-DSA (FIPS 205, the hash-based SPHINCS+) for digital signatures. Publishing standards is what turns "quantum-resistant" from a research topic into something vendors can implement and organisations can require. The current guidance lives at nist.gov.

These algorithms are not drop-in replacements at the byte level. Their keys and signatures are larger, their performance characteristics differ, and they interact with protocols and hardware in new ways. That is precisely why the migration is an engineering programme rather than a configuration change.

Crypto-agility: the real objective

The most important lesson from past algorithm transitions — deprecating MD5, SHA-1, or short RSA keys — is that they are painful mostly because cryptography is hard-coded and scattered. The strategic goal of post-quantum preparation is therefore crypto-agility: the ability to change cryptographic algorithms across your estate quickly, ideally without re-architecting the systems that use them.

What agility looks like in practice

Agile systems reference cryptography through abstractions rather than baking specific algorithms into application code. They negotiate algorithms rather than assuming them, they maintain an accurate inventory of where cryptography is used, and they can roll a new algorithm out through configuration and updates. Building this capability pays off regardless of the quantum timeline — it makes every future transition, for any reason, dramatically cheaper.

A phased migration

A sound programme moves through the stages in Figure 1 rather than attempting a single cutover.

Inventory comes first: you cannot migrate cryptography you cannot see. Discover where public-key cryptography is used — in TLS, VPNs, code signing, secrets management, embedded devices, and third-party products. Assess risk next, prioritising by the confidentiality lifetime of the data each system protects; long-lived secrets crossing capturable networks are the front line. Then build crypto-agility so that algorithms can be swapped without rewrites.

The rollout itself favours a hybrid stage, where a classical algorithm and a post-quantum one are combined so that the connection stays secure as long as either holds. Hybrid mode hedges against implementation flaws in the still-young PQC algorithms while delivering quantum resistance today, which is why standards bodies and browsers have adopted it as the pragmatic first move. Only once the post-quantum algorithms and their implementations are proven at scale does full PQC become the sensible end state.

Starting now, sensibly

None of this requires panic, and it does not require ripping out working cryptography overnight. It requires starting the unglamorous groundwork: inventory, risk assessment by data lifetime, and the architectural work of crypto-agility. Those steps have value on their own, they are the long pole in the tent, and they position you to adopt the standards smoothly as the ecosystem matures. The organisations that begin the inventory today are the ones that will migrate calmly rather than scramble later.

Key takeaways

  • Harvest now, decrypt later makes this a present risk for any data with a long confidentiality lifetime.
  • NIST has standardised PQC algorithms — ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures.
  • The strategic goal is crypto-agility — the ability to swap algorithms without re-architecting.
  • Migrate in phases: inventory, assess by data lifetime, build agility, run hybrid, then full PQC.
  • Start the inventory now — it is the long pole, and beginning early turns migration into a plan, not a scramble.
#pqc #cryptography #nist #migration
All articles Plan your PQC migration