Post-quantum encryption: what to do now

The problem in short

Most encryption on the internet depends on public-key algorithms such as RSA and elliptic curves. They protect the moment when two sides agree on a key, and they prove who signed something.

A large enough quantum computer could break these algorithms. This has been known since 1994, when Peter Shor published the algorithm that does it. No such computer exists today, and nobody can say with certainty when one will.

The encryption of the data itself is in a better position. Algorithms such as AES-256 are affected far less and are expected to stay safe.

Why it matters before the computers exist

There are two reasons to act early.

Data recorded today can be decrypted later. Someone who records encrypted traffic now can keep it until a quantum computer exists. This is known as “harvest now, decrypt later”. It matters for anything that has to stay secret for many years: health records, contracts, designs, personal data.

Migration takes years. Encryption sits in places nobody remembers: old services, devices, libraries, certificates and products from suppliers. Finding it all is slow work, and replacing it is slower.

The standards are ready

The replacement algorithms exist. In August 2024 the US standards body NIST published its first three post-quantum standards:

• FIPS 203 (ML-KEM) for agreeing on a key.
• FIPS 204 (ML-DSA) for digital signatures.
• FIPS 205 (SLH-DSA) for digital signatures, built on a different mathematical basis as a second option.

They are already in use. Major browsers and content delivery networks now offer a hybrid key exchange for web traffic, which combines a classical algorithm with ML-KEM. OpenSSH has used a hybrid post-quantum key exchange by default since version 9.0.

NIST has also published a draft plan for the transition. It proposes to stop the use of today’s public-key algorithms by 2035, and to phase out the weaker key sizes from 2030.

Five steps to take now

1. Make an inventory. List where you use public-key encryption: web traffic, VPNs, SSH, certificates, signed software, encrypted backups and the products of your suppliers.
2. Rank by how long the data must stay secret. Traffic that is worthless in a week can wait. Records that must stay private for ten years come first.
3. Ask your suppliers. Cloud providers, device makers and software vendors all have a plan, or should have one. Ask for it, with dates.
4. Turn on what is already there. Hybrid key exchange is often one setting away, in your web server, your content delivery network or your SSH configuration. Keep your software current, because new versions bring it by default.
5. Make encryption replaceable. Do not hard-code an algorithm in your own software. Put the choice in configuration, so the next change is a setting and not a rewrite.

What you do not need to do

You do not need to buy a quantum product, and you do not need to replace everything this year. Be careful with any vendor who says otherwise.

What you need is a list, an order of priority and a plan that follows the standards. It is ordinary engineering work with a long deadline.

Our quantum page describes how we help with a post-quantum security review.