Post-Quantum Cryptography: Why the Migration Starts in 2026, Not 2030

Since August 2024, the first three post-quantum standards have been final. NIST published FIPS 203 (ML-KEM, derived from Kyber), FIPS 204 (ML-DSA, from Dilithium) and FIPS 205 (SLH-DSA, from SPHINCS+), concluding an eight-year selection process. Many read the headline, see the frequently cited year 2030 and put the topic back on the shelf. That is a misunderstanding: 2030 is a deadline, not a starting gun.

“Harvest now, decrypt later” makes it urgent

The threat does not wait for the first capable quantum computer. Attackers intercept encrypted traffic today and store it to decrypt later. Anything that must stay protected for a long time is therefore already exposed: contracts, health and HR data, long-lived keys, intellectual property, state and trade secrets. For this data, what matters is not when a quantum computer becomes practical, but how long the data must remain secret.

With CNSA 2.0, the NSA sets 2030 as a mandatory deadline for national security systems. Germany’s BSI has urged early migration and crypto-agility for years. Both describe a target, not a comfortable delay.

Why the migration takes years

Anyone who has tried to inventory their own cryptographic estate knows the problem: nobody knows exactly where which algorithms, keys and certificates are in use. On top of that come dependencies on libraries, hardware, protocols and partners that do not migrate to your schedule. A PQC migration is therefore not a switch but a multi-year programme.

The path is clear in its order:

• Inventory: make visible where which cryptography sits, including embedded and forgotten usage.
• Prioritise: the long-lived data first, the data already exposed to the harvest-now risk today.
• Establish crypto-agility: encapsulate algorithms so they can be swapped without changing the calling system.
• Pilot hybrid: classical and post-quantum methods in parallel, to test interoperability and performance.
• Automate and demand: automate renewal and bind suppliers to demonstrable PQC capability.

Crypto-agility is the real lever

The most common mistake is to see PQC as a one-time swap. The algorithms will keep evolving, parameters will be tightened, individual schemes could fall. What remains is the requirement to change algorithms without touching every calling system. Whoever builds in that agility today survives not only the first PQC wave, but the next one too.

In our NextPKI module, exactly this is built in: crypto-agile from the start, RSA, ECDSA and Ed25519 today, post-quantum methods prepared, with policy per tenant. The point itself, though, is independent of any tool, namely to build agility as a property and not as a later migration.

2026 is the year in which inventory and pilot should be in place. Then 2030 is merely the finish line, not a date to fear.