Getting quantum-ready: a practical migration to post-quantum crypto
4 July 2026 · 8 min read · Nintech Security
Nobody can tell you when a cryptographically relevant quantum computer will exist, and anyone who gives you a confident date is selling something. That uncertainty is not a reason to wait. The threat model that matters today is harvest-now-decrypt-later: traffic recorded in 2026 can be decrypted the day the machine arrives, and some of what you transmit today — health records, state secrets, long-term commercial agreements — must stay confidential for decades. The migration is now unambiguous engineering work with finalised standards behind it, and the organisations that treat it as routine platform hygiene will be fine. The ones that treat it as someone else's problem in 2035 will not.
Harvest now, decrypt later is the threat that starts the clock
Shor's algorithm, run on a sufficiently large fault-tolerant quantum computer, breaks the mathematical problems underneath RSA and elliptic-curve cryptography — which between them protect almost every TLS handshake, VPN tunnel, and SSH session on the internet. The machine does not exist yet. But an adversary with storage and patience does not need it to exist yet: record encrypted traffic today, decrypt it when the hardware arrives. Well-resourced intelligence agencies are widely assessed to be doing exactly this, and storage is cheap.
The practical consequence is that your deadline is not 'when the quantum computer arrives' but 'quantum arrival minus the confidentiality lifetime of your data'. If you handle information that must remain secret for 20 years and you assess even a modest probability of a cryptographically relevant machine within that window, key exchange for data in transit needed fixing yesterday. Signatures are more forgiving — a forged signature only matters once the machine exists — which is why sensible migration plans do key establishment first and authentication second.
Crypto-agility matters more than any single algorithm
The uncomfortable lesson of post-quantum cryptography's own history is that algorithms fail in peacetime. SIKE, a fourth-round NIST candidate, was broken in 2022 by a classical attack running on a laptop; Rainbow, a signature finalist, fell the same year. ML-KEM's lattice foundations have survived years of concentrated cryptanalysis and are the best bet available, but the honest position is that any specific algorithm might need replacing, quantum threat or not. The durable investment is therefore not 'deploy Kyber' but 'build systems where swapping a primitive is a configuration change, not a two-year programme'.
Concretely, crypto-agility means: no hard-coded algorithm identifiers scattered through application code; cipher-suite and key-size decisions centralised in a small number of libraries or services; protocols and data formats that negotiate or version their cryptography; and key sizes and message formats that tolerate the larger keys and ciphertexts post-quantum schemes bring (an ML-KEM-768 public key is 1,184 bytes against X25519's 32 — protocols with tight packet budgets, such as DNSSEC or some embedded stacks, feel this immediately). If your last algorithm migration — SHA-1 deprecation, say — took five years of archaeology, that is the finding, and it is fixable independently of anything quantum.
Hybrid key exchange is the deployable step today
The pattern the industry has converged on is hybrid key exchange: run a classical exchange (X25519) and a post-quantum one (ML-KEM) in the same handshake and combine both shared secrets, so the session is safe unless both algorithms fail. This is a hedge against the newer algorithm harbouring an undiscovered flaw, and it is not theoretical — X25519MLKEM768 is enabled by default in Chrome and Firefox, Cloudflare and Google terminate it at the edge for a large fraction of their TLS traffic, and OpenSSH made a hybrid post-quantum exchange its default in version 9.x. Signal's PQXDH and Apple's iMessage PQ3 apply the same principle to messaging.
For most organisations the first move is therefore cheap: upgrade TLS termination points — load balancers, CDNs, reverse proxies — to versions supporting hybrid groups, and turn them on. Modern OpenSSL (3.5+), BoringSSL, and the major cloud load balancers all support this now. The caveats are real but manageable: handshakes carry roughly a kilobyte of extra data each way, which can push a ClientHello across a TCP packet boundary and has historically tripped up badly written middleboxes that assumed handshakes fit in one MTU. Test, measure handshake latency, and keep the classical-only path available as a fallback during rollout.
You cannot migrate crypto you cannot find
Every organisation that has attempted this discovers the same thing: nobody knows where their cryptography actually lives. It is in TLS terminators, yes, but also in JWT signing, database and disk encryption, code-signing pipelines, SSH and VPN configs, hardware security modules, firmware update mechanisms, vendored libraries pinned five years ago, and IoT devices in the field that will never be updated. A cryptographic bill of materials — an inventory of algorithm, key size, protocol, library, and data lifetime per system — is unglamorous work, but it is the prerequisite for every subsequent decision, and it is where regulators and frameworks (NSA's CNSA 2.0, the NCSC's migration guidance) tell you to start. Tooling helps at the edges — network scans find TLS endpoints, code scanning finds library imports — but the long tail is interviews and spreadsheets.
With the inventory in hand, the sequencing writes itself. Now: fix key exchange on external TLS and VPN (harvest-now-decrypt-later applies), demand PQC roadmaps in vendor contracts, and stop procuring long-lived systems without an upgrade path. Next: internal transport, then signatures — ML-DSA and SLH-DSA per FIPS 204 and 205 — where code-signing roots and firmware verification keys matter most because they are hardest to rotate once shipped. The anchor for all of it is NIST's finalised standards from August 2024: FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA). The era of 'wait and see which algorithm wins' ended then; what remains is inventory, prioritisation, and deployment — ordinary engineering, best started while it is still nobody's emergency.
Working on something like this? Talk to an engineer.