A post-quantum migration roadmap

Why the work starts now

A cryptographically relevant quantum computer would break RSA and elliptic-curve cryptography — the key exchange and signatures under almost every TLS connection, VPN, code-signing key and certificate in use today. No one can say when one will exist. What is known is that an attacker can record encrypted traffic today and decrypt it later (harvest now, decrypt later), so data that must stay secret for years is already exposed. And replacing cryptography across an enterprise takes years: the inventory alone is a project.

The standards

NIST published the first three post-quantum standards on 13 August 2024:

• FIPS 203, ML-KEM — key establishment, replacing RSA and ECDH key exchange.
• FIPS 204, ML-DSA — digital signatures, replacing RSA and ECDSA signatures.
• FIPS 205, SLH-DSA — hash-based signatures: larger, but resting on more conservative assumptions.

In practice, most systems will run them in hybrid mode first — a classical and a post-quantum algorithm together — so a connection or certificate stays secure if either one turns out to be weak, and keeps working with clients that only understand the classical one.

The deadlines

NIST IR 8547 is still an initial public draft, but OMB M-26-15 directs agencies to align their plans with it, so its 2030 and 2035 dates are the working baseline. See CNSA 2.0: the algorithms and the deadlines for the national-security dates by category.

The five steps

1. Inventory every use of cryptography

You cannot migrate what you cannot find. Cryptography lives in three places, and each needs its own way of looking: source code (the calls your developers write), dependencies (the libraries and their versions) and the network (what servers and devices actually negotiate, which depends on configuration no code scan can see). M-26-15 names exactly these — code analysis, software bills of materials and network scanners — feeding a central cryptographic bill of materials.

2. Rank it by risk

Start with what an attacker would harvest: data that must stay confidential for years, systems that hold it, and the identity infrastructure — PKI, VPN and authentication — that everything else trusts. M-26-15 puts high-value assets, high-impact systems and data that will still be sensitive in 2030 first.

3. Move key exchange first

Harvest-now-decrypt-later targets encrypted traffic, so key establishment is the urgent half. Hybrid ML-KEM key exchange in TLS 1.3 protects new sessions now while staying compatible. M-26-15 orders it the same way: key establishment for prioritised systems by 2030, signatures in 2031.

4. Then signatures and certificates

A signature can only be forged by an attacker who has a quantum computer at the time, so signatures can follow — but they are the larger job. Certificate authorities, chains, revocation, every client that verifies them, and long-lived keys such as roots and firmware signing all move to ML-DSA (or SLH-DSA), usually through hybrid certificates first. See ML-DSA vs ECDSA for certificates.

5. Keep it from sliding back

New code keeps arriving with RSA key generation and SHA-1 in it, and new devices ship with old defaults. Treat the migration as continuous: scan every change, monitor what the network negotiates, and keep the inventory live. The goal M-26-15 states for every phase is the same — systems that are cryptographically agile, so the next change of algorithm is a configuration change, not another project.