The quantum threat to today's encryption is real, slow-moving, and unusually well signposted. A sober account of harvest-now-decrypt-later, the new NIST standards, and what actually to do this year.
Part 4 of 10 in Trust through mathematics
The short answer first: the quantum threat to public-key cryptography is real, it is not imminent, and almost everything needed to deal with it in an orderly fashion already exists. That combination is rare in security. One audience is told the sky is falling and sold “quantum-safe” products of uneven seriousness; another decides the whole business is decades away and files it under someone else’s problem. Both are wrong, and the material needed to see why is all in the public record.
What follows sets out the position as we see it: what is actually at risk, what the standards bodies have already done about it, and what a sensible organisation should be doing in 2026 – which is a good deal more than nothing and a good deal less than panic.
What is actually at risk
A sufficiently large, error-corrected quantum computer running Shor’s algorithm would break the public-key cryptography that nearly every current system rests on: RSA, Diffie–Hellman, and the elliptic-curve schemes. These are the algorithms that let strangers establish trust – the TLS handshake that secures this page, digital signatures, key exchange, code signing. Shor’s algorithm turns the hard mathematical problems these rely on into tractable ones, and that, in essence, is the crisis. It is specifically a public-key crisis.
Symmetric cryptography fares far better. Grover’s algorithm offers only a quadratic speed-up against ciphers such as AES, and a quadratic speed-up is answered simply by doubling the key length; AES-256 remains comfortable, and the same broadly holds for the hash functions. Consequently the problem is narrower than the headlines suggest. It is not that “encryption is broken”; it is that one specific family – the asymmetric algorithms that establish trust between parties who have never met – needs replacing.
No machine capable of any of this exists today. Credible estimates for when one might arrive vary from the early 2030s to considerably later, and anyone offering a firm date is either guessing or selling; this genuinely cannot be known from here. But the date of the machine is not the date the risk begins.
Harvest now, decrypt later
Encrypted traffic intercepted today can be stored cheaply and decrypted whenever the capability arrives. For data whose sensitivity expires in weeks or months, this is of no consequence. For data that must stay confidential for ten, twenty, or fifty years, it changes the question entirely.
For example: a submarine’s acoustic signature, a patient’s genome, the negotiating position behind a live contract, or the wiring of an industrial system expected to run for three decades. None of these stops being sensitive because a decade has passed, and none is safe merely because the quantum computer has not yet been built. If an adversary can afford to store the ciphertext now – and storage is cheap, and patient adversaries are real – then the only question that matters is whether the machine’s arrival date falls within that data’s confidentiality lifetime.
For a meaningful class of data, the honest answer is “possibly”, and “possibly” is enough to act on. The threat to long-lived secrets is therefore not in the future at all. It is operating now, in the unglamorous form of patient storage.
The standards have already landed
Here the story turns reassuring, because the cryptographic community saw this coming a decade ago and did the work. This is verified against the primary instruments rather than the commentary around them: in August 2024 NIST published its first finalised post-quantum standards – FIPS 203 (ML-KEM, derived from Kyber) for key establishment, FIPS 204 (ML-DSA, from Dilithium) for signatures, and FIPS 205 (SLH-DSA, from SPHINCS+) as a hash-based signature alternative resting on entirely different mathematics. In March 2025 NIST added HQC as a backup key-establishment mechanism, built on error-correcting codes rather than lattices, precisely so that a single mathematical surprise cannot undo everything at once. Its full standard is not expected to be final until 2027, so it is a hedge for later, not a tool for today.
These are not laboratory curiosities. Major browsers and cloud providers have been running hybrid post-quantum key exchange in production TLS for some time, and a substantial and growing fraction of global web traffic already uses it – something one can observe directly in a browser’s connection details. The UK’s National Cyber Security Centre has published a clear, three-phase migration timeline in plain dates: identify and plan by 2028, complete the high-priority migrations by 2031, and finish by 2035. The American and European guidance runs on much the same clock. When institutions as constitutionally cautious as these commit to a calendar, the sensible response is to take the calendar seriously.
What a sensible organisation does now
The work divides into four parts, and only the first is genuinely urgent.
First, build a cryptographic inventory. Most organisations cannot presently answer the question “where do we use RSA?” – and migration without an inventory is guesswork dressed as a project. Catalogue where public-key cryptography actually lives: TLS endpoints, VPNs, code signing, document signing, the internal PKI, embedded devices, and every supplier connection you depend on. Expect the embedded and supplier categories to be the unpleasant ones; it is invariably the forgotten appliance in a cupboard, or the third-party API nobody has looked at since it was integrated, that carries the hard-coded assumption. This work is dull, takes longer than anyone expects, and is nonetheless the single highest-value thing available today – not least because a cryptographic inventory earns its keep in incident response and supplier assurance regardless of whether a quantum computer ever arrives.
Second, classify data by confidentiality lifetime. Harvest-now-decrypt-later only bites on data that must outlive the threat horizon, and in the main most traffic does not. The fraction that does – identify it specifically – is where hybrid key exchange belongs early, ahead of the general schedule.
Third, demand crypto-agility in everything new. Every system procured or built from this point should be able to change algorithm without structural surgery. The organisations that suffered most in past migrations – the long retirements of MD5, of SHA-1, of the weaker TLS versions – were those whose cryptography had become load-bearing masonry rather than a replaceable fitting. One would expect the lesson to have been learned by now; it has not, quite, and post-quantum is simply its next examination. It is strongly recommended that crypto-agility be written into procurement as a requirement rather than an aspiration, because a requirement that lives only in good intentions is the one that fails at the worst moment.
Fourth, migrate in hybrid mode, in priority order. Current best practice pairs a classical algorithm with a post-quantum one, so that the connection holds unless both are broken – a sensible hedge against the relative youth of the new mathematics, and the pattern already deployed across the industry. Signatures are generally less urgent than key establishment, since a signature forged in 2035 does not retroactively compromise a document verified in 2026; long-lived code-signing roots and firmware are the exception and deserve earlier attention.
What to decline
Some things sold as necessary are not. Proprietary “quantum-safe” schemes that route around the standards process deserve suspicion rather than gratitude – the entire point of a decade of open standardisation is that nobody need take a vendor’s word for the mathematics. Urgency theatre tied to a procurement deadline can be declined on sight. And quantum key distribution, sold as a general-purpose answer, is not one; the NCSC’s guidance for most organisations remains, politely, that the standardised post-quantum algorithms are the answer and QKD is not.
The transition is, in one respect, a gift. A fundamental threat to the foundations of digital trust has been identified decades in advance, the replacement mathematics has been standardised, deployed, and made free to use, and the threat itself has not yet arrived. Security rarely offers terms this generous. The organisations that come off badly will not be the ones that moved too slowly on the mathematics; they will be the ones that treated a well-signposted engineering migration as either an emergency or an abstraction, and so managed neither the planning nor the calm.
None of this asks for heroics in 2026. An inventory, a data classification, and a crypto-agility clause in the next procurement would be a thoroughly respectable year’s work – and would put you comfortably ahead of most.