Quantum computing has a credibility problem in security conversations. It has been five years away for about fifteen years, and the vendor messaging around it has not helped.
Which is unfortunate, because there are now firm dates attached to it, and they are closer than the technology.
The dates that actually matter
Nobody can tell you when a quantum computer capable of breaking current cryptography will exist. Anyone offering a firm date is guessing. But the regulatory timeline is published and is not contingent on that arrival:
- 2024 — NIST published the first post-quantum standards: ML-KEM for key exchange, ML-DSA and SLH-DSA for digital signatures.
- 2028 — the NCSC expects UK organisations to have completed discovery and produced a migration plan.
- 2030 — NIST deprecates RSA and elliptic curve cryptography.
- 2031 — the NCSC expects highest-priority migration to be complete.
- 2035 — NIST intends to disallow RSA and ECC entirely. The G7 Cyber Expert Group has set the same date for financial services.
2028 is the operative one. Discovery across a large estate takes months, and a credible plan depends on having finished it.
What is actually at risk
This is the part most coverage gets wrong, and the answer is more reassuring than the headlines suggest.
The threat is not uniform. Shor's algorithm breaks RSA and elliptic curve cryptography outright — and increasing key length does not help, because the problem is mathematical rather than one of scale. That affects key exchange, digital signatures, certificates and identity.
Symmetric encryption is a different matter. Grover's algorithm halves the effective strength of a symmetric key, which takes AES-256 to 128 bits of post-quantum security. That remains computationally infeasible to attack. NIST has not proposed a replacement for AES because none is needed.
So the bulk encryption protecting your data is broadly fine. The exposure is in the mechanism that establishes the keys and proves identity — which makes this a public key infrastructure problem before it is an encryption problem.
Why it is urgent despite the uncertainty
Encrypted traffic can be captured and stored today, then decrypted once the capability exists. This is known as harvest now, decrypt later, and it requires no future technology on the attacker's part — interception and cheap storage are both available now.
The practical test is straightforward: does any of your data still need to be confidential in ten, twenty or thirty years? For most organisations the answer is yes for a small subset — health records, legal matters, intellectual property, anything with a long regulatory retention period. That subset is already exposed.
What to do now, without spending anything
Four things, none of which require procurement.
- Classify by how long data stays sensitive. Your existing classification tells you how sensitive data is now. This needs a different dimension. Most organisations find the genuinely long-lived category is much smaller than expected, which makes the rest tractable.
- Build a cryptographic inventory. Which algorithms, key lengths and protocols are in use, and which systems depend on them. You cannot migrate cryptography you have not identified, and this is the step organisations most often skip in favour of buying something.
- Identify what cannot be changed. Operational technology, embedded devices, appliances with fixed firmware. These determine the real shape of the programme, and finding them late is what turns a plan into a crisis.
- Add crypto-agility to procurement. Every system you buy or renew from now should support algorithm and key length changes without redesign. Requiring it today costs nothing. Retrofitting it is the most expensive category of remediation there is.
The capability it all depends on
One point is worth drawing out, because it determines how expensive this becomes.
Migrating to post-quantum algorithms means reissuing certificates — potentially every certificate in the estate. An organisation that can already discover, renew and deploy certificates automatically is running an operation. An organisation renewing by ticket and spreadsheet is running a programme, and a long one.
The same capability is already being demanded by the reduction in public TLS certificate lifetimes, which drops to 47 days by 2029 and multiplies renewal frequency roughly eightfold. Two separate pressures, one underlying requirement.
Which is why certificate lifecycle automation tends to be the first genuine investment in a post-quantum programme rather than the last. If you are evaluating platforms, post-quantum algorithm support and cryptographic discovery are worth treating as selection criteria now rather than revisiting later — we have set out how to evaluate CLM vendors and licensing models, including the licensing structures that behave very differently once renewal volumes multiply.
The thing to avoid
There are two failure modes, and they are opposites.
The first is dismissing it because quantum computers do not exist yet, which misses that the collection is happening now. The second is urgency-driven procurement — buying quantum-safe products before understanding where sensitive data sits and how it moves. That repeats the pattern of previous technology cycles, where procurement preceded strategy and the strategy never arrived.
The sensible position is in between: a proportionate assessment of where the risk is real, and a phased plan that sits alongside existing security priorities rather than displacing them. We have written more on what post-quantum cryptography actually involves and on what crypto agility means in practice, which is the capability the whole transition depends on.
Unsung is a UK consultancy specialising exclusively in public key infrastructure and cryptographic systems. More at unsungltd.com
