Post-Quantum Cryptography Migration: A 2026 Guide

Post-quantum cryptography (PQC) has moved from research topic to compliance requirement faster than most teams expected. The standards are final, the regulatory deadlines are on the calendar, and the migration is no longer optional for anyone handling long-lived sensitive data. This guide explains what PQC is, why the clock is already running, and how to migrate your systems in a sane, prioritised order.

What post-quantum cryptography actually is

Almost all encryption on the internet today relies on two hard math problems: factoring large numbers (RSA) and the elliptic-curve discrete logarithm (ECDH, ECDSA). A sufficiently powerful quantum computer running Shor's algorithm would solve both efficiently — breaking the key exchange that protects your TLS connections and the signatures that prove your domain's identity.

Post-quantum cryptography replaces those vulnerable algorithms with new ones based on math problems that quantum computers are not known to solve efficiently — primarily lattice-based schemes. The headline algorithms are ML-KEM (key exchange) and ML-DSA (signatures), which replace ECDH and RSA/ECDSA respectively.

Crucially, symmetric cryptography (AES) and hashing (SHA-2/SHA-3) are not broken by quantum computers in the same way — they only need larger parameters. The urgent problem is public-key cryptography: key exchange and signatures.

The standards are final

This is no longer speculative. On August 13, 2024, NIST published three final standards:

• FIPS 203 (ML-KEM) — the key-encapsulation mechanism, formerly known as CRYSTALS-Kyber.
• FIPS 204 (ML-DSA) — the primary digital signature standard, formerly CRYSTALS-Dilithium.
• FIPS 205 (SLH-DSA) — a hash-based signature standard (SPHINCS+) for conservative use cases.

In March 2025, NIST also selected HQC as a backup key-encapsulation algorithm built on a different mathematical foundation than ML-KEM — a deliberate hedge in case a future weakness is found in the lattice approach. A fourth signature standard (FN-DSA / Falcon, expected as FIPS 206) is still in draft.

The takeaway: the algorithms you need to migrate to exist, are standardised, and are shipping in real software today.

Why the deadlines are already here

The most common mistake is treating PQC as a problem for 2030. It isn't, for two reasons.

First, "harvest now, decrypt later." An adversary doesn't need a quantum computer today to harm you today. They can record your encrypted traffic now and decrypt it once the hardware exists. Anything that must stay confidential for years — health records, financial data, trade secrets, state communications — is effectively exposed the moment it's transmitted with classical cryptography. (We cover this threat in detail in Harvest Now, Decrypt Later.)

Second, the regulatory calendar. Several major frameworks now set explicit migration dates:

• NIST IR 8547 proposes that RSA and elliptic-curve cryptography at the common security levels be deprecated after 2030 and disallowed after 2035. These dates have become the de-facto industry north star.
• NSA CNSA 2.0 mandates ML-KEM-1024 and ML-DSA-87 for US national security systems, with category-specific milestones running from 2025 through 2033 and new acquisitions required to support CNSA 2.0 by January 1, 2027.
• The EU Coordinated PQC Roadmap asks member states to define national roadmaps by end-2026, migrate high-risk critical infrastructure by end-2030, and complete the transition by 2035.
• UK NCSC sets 2028 for completing cryptographic discovery, 2031 for highest-priority migrations, and 2035 for full migration.

Even where regulations don't name PQC algorithms explicitly — as with the EU's NIS2 and DORA — they require "state-of-the-art" cryptography and risk-based controls, which increasingly implies a PQC plan. (More on that in NIS2 and DORA cryptography requirements.)

When is Q-Day?

Nobody knows. Estimates for when a cryptographically relevant quantum computer arrives range from 2028 to beyond 2040, depending on who you ask. Some major operators now plan against 2029 as a conservative scenario. The honest answer is that Q-Day is a risk to manage, not a date to predict — and the right framing is Mosca's inequality: if the time your data must stay secret, plus the time it takes you to migrate, is greater than the time until Q-Day, you are already too late. For long-lived data, that condition is met today.

A practical migration path

Migration is a multi-year program, but it follows a predictable order. Here is the sane sequence.

1. Inventory your cryptography

You cannot migrate what you cannot see. Build an inventory of every place you use cryptography: TLS endpoints, certificates, SSH, VPNs, email, code signing, stored keys, and the libraries underneath them. This "cryptographic bill of materials" is the single most-requested artifact across every framework — PCI DSS, the US federal inventory mandates, NCSC's 2028 milestone, and the EU roadmap all start here.

2. Classify by data lifetime and exposure

Not everything is equally urgent. Rank assets by how long their data must stay confidential (a 25-year health record is far more exposed than a session token) and how easily an adversary can intercept them (an internet-facing TLS endpoint versus an internal disk volume). Long-lived data on exposed channels is your priority-one list.

3. Deploy hybrid key exchange first

The fastest, lowest-risk win is hybrid key exchange in TLS — combining a classical algorithm with a post-quantum one so the connection is safe even if one is later broken. The standard today is X25519MLKEM768, which pairs X25519 with ML-KEM-768. It's available in OpenSSL 3.5+ (released April 2025 as a long-term-support version), recent Nginx, and most major CDNs and browsers. Because it's hybrid, it falls back gracefully and breaks nothing. (See our step-by-step guide: Enable X25519MLKEM768 in Nginx and OpenSSL 3.5.)

4. Plan the signature and PKI migration

Signatures are harder than key exchange because they involve your certificate authority chain. Moving leaf and intermediate certificates to ML-DSA depends on your CA's support and is the part NCSC explicitly flags as the most challenging. Start the conversation with your CA early and treat PKI as a separate, longer track.

5. Address code signing and firmware

CNSA 2.0 requires stateful hash-based signatures (LMS/XMSS) for code and firmware signing from 2025. If you ship software or devices, this is its own workstream with its own timeline.

6. Monitor continuously

Crypto-agility means treating this as an ongoing posture, not a one-time project. Configurations regress, libraries change, and new endpoints appear. Continuous monitoring catches a server that quietly lost its post-quantum support after an upgrade.

Where to start today

The first concrete step costs nothing: find out where you actually stand. PQScore scans any domain and shows your post-quantum readiness across TLS, certificates, DNS and email — in under a minute, with no signup.

Scan your domain free with PQScore →

From there, work the list above in order: inventory, classify, hybrid key exchange, then PKI. The teams that start now will be done comfortably before the 2030 deprecation window. The ones that wait will be doing it under deadline pressure — and their long-lived data will have been exposed the whole time.