Quantum-safe encryption means moving your systems onto maths that a future quantum computer cannot unpick. The encryption protecting your website traffic, your VPN tunnels and your software updates today rests on problems that ordinary computers find hard. A large, error-corrected quantum computer would make several of those problems easy.
No such machine exists in 2026. So why is this a budget line this year? Because attackers can copy encrypted traffic now and store it until they can decrypt it. The industry calls this “harvest now, decrypt later”. Anything you send today that still has to stay secret in 2035 is already exposed.
The waiting, at least, is over. The US National Institute of Standards and Technology (NIST) published its first finished post-quantum standards in August 2024, and the US, the UK and the EU have since set dates by which the old algorithms have to go. This guide covers what changed, what you have to do, and in what order.
Key Takeaways
- The risk starts with data you send today, because encrypted traffic can be stored now and decrypted years later.
- NIST finished the core standards in August 2024, so there is nothing left to wait for.
- Draft US federal guidance deprecates RSA and elliptic curve cryptography after 2030 and disallows them after 2035.
- Start with an inventory. You cannot migrate cryptography you cannot find.
- Hybrid key exchange adds post-quantum protection without breaking compatibility with older systems.
- More than half of human web traffic on Cloudflare’s network already used post-quantum key agreement by late 2025.
Why this is a 2026 problem, not a 2035 one
Nothing can break RSA today, so why not wait? Three things answer that.
First, the harvest. Encrypted traffic is easy to record and cheap to store. An attacker who copies your VPN sessions or archived email today needs no quantum computer right now. They only need one later. Long-lived material is the target: legal records, patient files, engineering drawings, merger documents, signing keys.
Second, migrations take years. Replacing cryptography touches certificates, firmware, embedded devices, third-party software and every supplier contract that names an algorithm. Most organisations discover during the inventory that they do not know where all their keys are.
Third, the expert view has moved. The Global Risk Institute’s Quantum Threat Timeline Report 2025, published in March 2026, surveyed 26 specialists. Their averaged optimistic estimate that a quantum computer could break RSA-2048 within ten years rose from 34% in the previous survey to 49%.
There is a simple test, credited to the cryptographer Michele Mosca. Add the years your data must stay secret to the years your migration will take. If that total exceeds the time until a capable quantum computer exists, you are already late.
How quantum computers break today’s encryption
Two algorithms do the damage, and they do very different amounts of it. Knowing which is which tells you where to spend.
Shor’s algorithm breaks public-key cryptography
Public-key cryptography, also called asymmetric cryptography, lets two strangers agree on a secret over an open network. RSA, Diffie-Hellman and elliptic curve cryptography (ECC) all rely on maths that is easy in one direction and impractical to reverse: factoring very large numbers, or solving discrete logarithms.
Shor’s algorithm, published in 1994, reverses both efficiently on a large enough quantum computer. That is not a speed-up at the margins: it moves the problem from impossible in practice to routine, so the key exchange and digital signatures your systems depend on stop working as security.
Grover’s algorithm dents symmetric encryption
Symmetric encryption uses one shared key for both locking and unlocking. AES, which protects the bulk of your stored and transmitted data, is symmetric. Grover’s algorithm speeds up brute-force search against it, roughly halving the key strength.
That is a much smaller problem, and the fix is boring: use AES-256 rather than AES-128 for anything with a long retention window, and increase hash sizes to match. No new algorithm is needed.
What “harvest now, decrypt later” looks like
Traffic hoarding is a low-cost, patient strategy: capture at an internet exchange or a cable landing point, store cheaply, wait. Your exposure is set by how long the captured content stays sensitive, not by today’s threat level.
A worked example. A law firm sends a client file over a VPN in 2026, in a case running until 2038. If that tunnel used only classical key exchange, a copy taken today can be opened once a capable machine exists. Nothing the firm does in 2033 undoes that.
Which of your systems are actually exposed
Before buying anything, sort your estate into those two categories. The exposure is uneven, and treating everything as equally urgent is how these projects stall.
Asymmetric cryptography handles key exchange and identity. You will find it in TLS handshakes, SSH logins, IPsec VPN tunnels, S/MIME email signing, code signing certificates and the public key infrastructure (PKI) behind them. This is the exposed layer.
Symmetric cryptography protects bulk data: disk and database encryption, backup archives, the payload of a TLS session once the handshake is done. This layer needs larger keys, not a rebuild.
The practical output is a list of every place asymmetric cryptography establishes trust, plus a diagram of your PKI chains including certificates issued by suppliers. The discipline behind a working data governance strategy applies here too: one authoritative view of where sensitive material lives and how it is protected.
The post-quantum standards you can plan around
NIST ran an open, multi-year competition and finished the core of it on 13 August 2024. Three standards were published that day, and they are final rather than draft.
- FIPS 203, ML-KEM (formerly CRYSTALS-Kyber), for key encapsulation. This replaces RSA and elliptic curve key exchange in TLS and VPNs.
- FIPS 204, ML-DSA (formerly CRYSTALS-Dilithium), the primary digital signature standard.
- FIPS 205, SLH-DSA (formerly SPHINCS+), a hash-based signature scheme kept as a backup built on very different mathematics.
ML-KEM and ML-DSA are both lattice-based, a different family of hard problems from factoring. SLH-DSA exists so a future break in lattice maths does not leave you with nothing.
What is still coming
In March 2025 NIST selected HQC as a second key encapsulation algorithm, built on error-correcting codes, again as insurance against a single mathematical failure; the final standard is expected in 2027. FIPS 206, the FALCON-based signature standard renamed FN-DSA, was delayed by the difficulty of implementing its floating-point sampling safely and remained unpublished in spring 2026. Neither gap is a reason to wait, because ML-KEM and ML-DSA cover what almost every business needs.
Interoperability and performance
Post-quantum keys and signatures are larger than the ones they replace, so handshakes carry more bytes. In most web and VPN workloads the effect is small, but measure rather than assume. Sequence rollouts by exposure: external endpoints first, then internal services.
The deadlines that now apply to you
This is what changed most since the standards were published. Migration has moved from advice to dated obligation, and procurement questionnaires have followed.
- United States, NIST IR 8547. This draft transition report deprecates RSA, ECDSA, EdDSA, ECDH and finite-field Diffie-Hellman after 2030 and disallows them after 2035. It is still a draft and directional rather than binding, but it is the reference US vendors plan against.
- United States, NSA CNSA 2.0. For national security systems the dates are firmer: quantum-resistant support in new acquisitions by 2027, networking equipment on exclusive use by 2030, operating systems and cloud services by 2033, full coverage by 2035.
- United Kingdom, NCSC. Identify the cryptographic services needing upgrades and build a migration plan by 2028; complete high-priority upgrades by 2031; finish the migration by 2035.
- European Union. The Coordinated Implementation Roadmap of 23 June 2025 asks member states for national strategies and pilots by the end of 2026, completed high-risk migration by the end of 2030, and medium-risk systems by 2035.
If you already track obligations under evolving data privacy rules or the EU AI Act, fold the cryptographic transition into the same risk management framework rather than running it separately.
Adoption is already ahead of the deadlines in one place: the public web. Cloudflare reported that the share of human web traffic on its network using post-quantum key agreement rose from 29% at the start of 2025 to 52% by early December, driven largely by browser and mobile defaults. Almost none of that needed action by site owners, which is a reminder that the hard part is your own infrastructure.
Quantum-safe encryption in practice
A working programme mixes three things: new algorithms where trust is established, larger keys where data is stored, and the ability to change both later.
Post-quantum cryptography in TLS, VPNs, code signing and email
ML-KEM replaces the vulnerable key exchange in TLS handshakes and site-to-site VPNs. ML-DSA replaces the signatures in code signing and S/MIME. Vendors have been shipping support for a while: Fortinet added Kyber-based key exchange in FortiOS 7.6, and mainstream browsers and servers have supported hybrid key agreement since 2024.
Hybrid mode is the sensible default during transition. It runs a classical key exchange and a post-quantum one together and combines the results, so the connection breaks only if both are broken. Compatibility with systems that have not moved yet is preserved.
Quantum key distribution and where it fits
Quantum key distribution (QKD) takes a different route. Instead of harder maths, it uses the physics of light to deliver keys over dedicated fibre in a way that reveals eavesdropping. JPMorgan Chase demonstrated a 100 Gbps QKD-secured IPsec link over 46 km, so it works at production speeds.
It is also expensive, distance-limited and dependent on special hardware, and both the NSA and the UK NCSC have advised against relying on it instead of post-quantum algorithms. Treat QKD as an option for a handful of ultra-sensitive links. The wider quantum internet remains a research programme, not a procurement decision.
Symmetric hardening and crypto-agility
Move long-lived archives and backups to AES-256 and raise hash sizes to match. That is cheap and can start immediately.
Crypto-agility is the harder and more valuable habit: swapping an algorithm or parameter without rewriting applications. That means cryptography behind a shared service rather than hard-coded per app, automated certificate lifecycle management, and central policy. Teams running a hybrid cloud strategy usually find this is where the real work sits, because the same key material spans platforms with different controls.
What the vendors offer
You do not have to implement any of this yourself. The question is whether a vendor’s post-quantum support reaches the systems you actually run.
IBM
IBM contributed to the ML-KEM and ML-DSA designs and builds quantum-safe cryptography into its mainframes. The z16 shipped with post-quantum support in 2022; its successor, the z17, arrived in June 2025. IBM also sells Quantum Safe services for cryptographic discovery and migration planning, which is often the real constraint.
Fortinet
Fortinet added NIST-selected Kyber key exchange to FortiOS 7.6, so PQC-ready VPN tunnels can be switched on in a normal maintenance window. For distributed teams that is one of the fastest ways to cut harvesting exposure, alongside the practices in our guide to cybersecurity for remote work.
Nokia
Nokia works layer by layer across optical transport, Ethernet, MPLS and IP, combining AES-256 in the transport layer with automated key orchestration through its 1830 Security Management Server. That matters when you manage keys across thousands of links rather than dozens.
Whichever you evaluate, ask for hybrid mode support, interoperability test evidence, and a dated list of which products get post-quantum support.
Assess your risk: what to inventory and monitor
Start by mapping what you have: keys, certificates and the places sensitive files actually live. Teams that begin this work usually find cryptography in systems nobody had listed, such as a legacy payment integration or a supplier’s embedded device.
Classify data by how long it must stay secret
Give every data class a “time to sensitivity”: the year after which disclosure would no longer matter. Legal records, health files, intellectual property and long contracts sit at the top; marketing analytics at the bottom. That single number drives the sequence, and it is a question for the business, not the security team alone.
Find every place cryptography is used
Automated discovery tools scan endpoints, servers, applications and network devices for RSA, ECC and outdated protocols. Combine them with your configuration database and manual checks, because scanners routinely miss embedded and third-party systems.
- Map where encrypted data is stored and transmitted, including backups and links between data centres.
- Baseline the paths worth harvesting: undersea and long-haul links, WAN circuits, site-to-site VPNs.
- Record certificate inventories, lifetimes, code signing dependencies and S/MIME usage, so rotations can be planned.
- Monitor cipher suites, handshake failures and deprecated algorithms to catch configuration drift early.
The inventory also underpins a credible privacy compliance framework, so it usually pays for itself twice.
Your migration roadmap
Begin with the channels an attacker would most want to record today. That points the effort at the risk already running.
Start with the traffic most worth harvesting
Undersea fibre, backbone links between data centres, site-to-site VPNs and long-lived certificates carry the most sensitive material over the longest lifetimes. Inventory those endpoints and tag each asset by time to sensitivity, so the sequence follows risk rather than convenience.
Pilot, then scale
Run hybrid key exchange pilots so compatibility is preserved while you measure real performance. Keep any QKD trial to a couple of links and prove out operations and key management first.
Align each wave with work you were doing anyway: certificate renewals, firmware patches, hardware refresh cycles. That keeps the budget defensible. Teams already modernising through cloud platform changes or edge computing rollouts have a natural place to fold this in.
Governance and KPIs
Set measurable targets before go-live: latency, handshake success rate, CPU overhead, interoperability pass rate. Define what counts as failure and write the rollback plan first.
Form a cross-functional group covering security, networking, applications, legal and procurement, and update supplier contracts to require post-quantum support or demonstrable crypto-agility, the same lever compliance automation tools use elsewhere.
Conclusion
Quantum-safe encryption is a migration project with published standards and published deadlines, which makes it manageable.
The sequence is not complicated. Find your cryptography. Sort your data by how long it must stay secret. Turn on hybrid key exchange, move long-lived storage to AES-256, and build the ability to change algorithms again without another multi-year programme.
What makes it urgent is not the machine that does not exist yet. It is the traffic leaving your network today. For context, see our guides to preparing your business for quantum computing, how quantum computing will affect future workflows and quantum computing and the future of work. On the security side, cybersecurity mesh architecture, zero-trust adoption, workplace data privacy rules, the 2026 cybersecurity trends and digital trust all touch the same programme.
Found this useful?
Make SmartKeys a preferred source on Google, and our articles will surface more often in your Top Stories, AI Overviews, and AI Mode.
Add as Preferred Source
