A realistic roadmap to post-quantum cryptography
Crypto inventory, crypto-agility and "harvest now, decrypt later": where to start today.
A large enough quantum computer would break the public-key cryptography that protects almost everything we do online: RSA and elliptic-curve algorithms used in TLS, VPNs, code signing, certificates and digital identities. Nobody knows exactly when such a machine will exist. That uncertainty is exactly why the work has to start now.
Why now, if the quantum computer isn't here yet?
Two reasons:
- Harvest now, decrypt later. An attacker can record encrypted traffic today and decrypt it when the technology becomes available. Health records, state secrets and long-term business plans must stay confidential for decades.
- Migrations take years. Changing cryptography touches applications, devices, hardware security modules, certificates, partners and contracts. Previous migrations, such as SHA-1 to SHA-2, took the better part of a decade.
The new standards
In August 2024 NIST published the first post-quantum standards:
| Standard | Algorithm | Purpose |
|---|---|---|
| FIPS 203 | ML-KEM (formerly Kyber) | Key establishment |
| FIPS 204 | ML-DSA (formerly Dilithium) | Digital signatures |
| FIPS 205 | SLH-DSA (SPHINCS+) | Hash-based digital signatures |
Hybrid key exchange, which combines a classical algorithm with ML-KEM, is already used by major browsers and content delivery networks. In Europe, the EU's coordinated roadmap asks member states and critical sectors to start the transition now and to protect high-risk systems first, around 2030.
A realistic roadmap
1. Build a cryptographic inventory
You can't migrate what you can't see. Find where cryptography is used: protocols, libraries, certificates, keys, HSMs, smart cards, VPNs, firmware, and the crypto hidden inside third-party products. Record the algorithm, key size, owner and how long the protected data must stay secret.
2. Prioritise by data lifetime and exposure
Start with systems that protect long-lived confidential data and traffic crossing untrusted networks. Systems whose data is worthless in a year can wait.
3. Design for crypto-agility
The real goal is not "switch to ML-KEM". It is being able to change algorithms without rewriting applications. Centralise cryptography in well-maintained libraries and services, avoid hard-coded algorithms and key sizes, and make certificates and keys easy to rotate.
4. Ask your suppliers
Much of your cryptography lives in products you buy. Add post-quantum readiness and crypto-agility to procurement requirements and ask vendors for their roadmaps.
5. Pilot hybrid modes
Test hybrid TLS and VPN configurations in non-critical environments. Watch performance, message sizes and compatibility with middleboxes: post-quantum keys and signatures are larger.
6. Don't forget identities
PKI, smart cards, code signing and electronic identification have long life cycles. They are often the slowest part of the migration, so they need early planning.
Start today: name an owner, start the inventory and add crypto-agility to your architecture principles. None of that needs a quantum computer.