Post-quantum cryptography tends to get one of two reactions in a boardroom. Some people panic, because they've seen a headline about quantum computers breaking the internet. Others shrug, because nobody can say when that will happen, so it feels like a problem for a future budget.
Neither reaction helps much. "When will a quantum computer break RSA?" is the wrong question. Ask how long your data needs to stay secret, and how long it'll take you to change your cryptography. If those two add up to more than the time you have left, you're already late.
Why the timeline matters more than the physics
The threat has a name: harvest now, decrypt later. An attacker who records encrypted traffic today can store it cheaply and wait. If a capable quantum computer shows up in ten or fifteen years, everything they collected becomes readable. For lots of data that's irrelevant, since a session cookie from last Tuesday is worthless in 2040. For health records, legal files, government data, long-lived intellectual property and anything under decades-long retention rules, it matters a great deal.
The other half of the sum is how long migration takes. Cryptography hides in places nobody has looked at for years: TLS termination on a load balancer, a signing key in a CI pipeline, a vendor SDK with a hard-coded algorithm, a mobile app that pins a certificate, a file format with RSA written into the spec. Anyone who lived through the SHA-1 deprecation at a large organisation remembers how long that dragged on. This change is bigger.
You can't wait for the standards any more
For years the sensible advice was to wait for the standards. They're here. In August 2024 NIST published its first finished post-quantum standards: ML-KEM for key exchange, plus ML-DSA and SLH-DSA for digital signatures. NIST has also proposed a transition timeline that deprecates today's public-key algorithms around 2030 and disallows them by 2035. Government procurement and regulated industries tend to follow NIST's lead, so those dates will reach your suppliers and auditors whether or not the quantum hardware keeps up.
Parts of the internet have already moved. Major browsers and CDNs now negotiate a hybrid key exchange by default, pairing a classical algorithm with ML-KEM so the connection stays secure unless an attacker can break both. If your public website sits behind a modern CDN, some of your traffic is probably protected already, without anyone having decided it should be.
A practical programme
1. Build a cryptographic inventory
You can't migrate what you can't find. Make a list of every place your systems use public-key cryptography, with the algorithm, the key size, the owner and how hard it would be to change. TLS endpoints are easy to scan. The harder finds are internal service-to-service calls, code and document signing, VPNs, hardware security modules and anything a vendor runs on your behalf.
The inventory pays for itself even if quantum never arrives. Most organisations that do it turn up expired certificates, deprecated algorithms and keys nobody can explain.
2. Prioritise by how long the data lives
The systems to fix first aren't necessarily your most critical ones. They're the ones carrying data that has to stay confidential for a long time. A payments API matters enormously today, but its traffic goes stale quickly. An archive of patient records or a document exchange with a law firm might need protecting for decades, so those channels go to the front of the queue.
3. Ask your vendors now
Much of your cryptography is someone else's code: your cloud provider, identity platform, VPN, HSM, managed database. Add a question to your next vendor review: "What's your post-quantum roadmap, and which of our integrations will change?" The answers are telling. Some vendors will send a detailed plan. Others will make it obvious they haven't started.
4. Build for crypto-agility
Every cryptographic migration teaches the same lesson. The algorithm was never the hard part. The hard part was that someone had hard-coded it. Systems that pick algorithms through configuration, keep keys behind a clean abstraction and version their message formats can switch within a release cycle. Systems that don't are in for an archaeology project.
Every new system we build treats the algorithm as configuration rather than code. It adds next to nothing to the build and turns the next migration from a rewrite into a settings change.
5. Turn on hybrid where it's cheap
If your platform already supports hybrid key exchange for TLS, switch it on. It's the cheapest protection against harvest-now-decrypt-later you can get today, and it's designed so a flaw in the new algorithm doesn't leave you worse off than before. Signatures are harder, since post-quantum signatures are much larger and some protocols and devices can't handle the size yet. That's OK. Key exchange protects confidentiality, which is what harvesting attacks go after, so it's the right place to begin.
What not to do
Be wary of anything sold as "quantum-proof" that wants you to rip out working infrastructure. Don't write your own implementation of a new algorithm, because the libraries from the major platforms and well-reviewed open-source projects exist for good reason. And don't treat this as a one-off project with an end date. Cryptography will keep changing. What you're really building is an organisation that knows where its cryptography lives and can change it without fuss.
Nobody knows whether the quantum deadline is ten years off or twenty. The compliance deadline is closer, and the inventory is worth doing either way. If you'd like help scoping one, or checking a system for crypto-agility, get in touch.
