Post-quantum cryptography migration — an engineering guide

Why this matters before quantum computers exist

A large, fault-tolerant quantum computer running Shor's algorithm would break RSA and elliptic-curve cryptography. Nobody can say exactly when that arrives, but attackers can record encrypted traffic today and decrypt it later — the 'harvest now, decrypt later' threat.

So the question is not 'when will quantum computers arrive?' It is 'how long must this data stay secret, and how long will our migration take?' If the sum of those two numbers is longer than the time until a capable quantum computer exists, you are already late.

The standards you are migrating to

A five-step migration plan

• 1. Inventory — Build a cryptographic bill of materials: libraries, protocols, certificates, hardware security modules, and vendor services. Most teams find cryptography in places nobody documented.
• 2. Prioritize — Rank systems by data lifetime and exposure. Long-lived sensitive data sent over public networks goes first.
• 3. Crypto-agility — Wrap cryptographic calls behind interfaces so an algorithm change is a configuration change, not a rewrite.
• 4. Hybrid pilot — Run classical and post-quantum key exchange together (e.g. X25519 + ML-KEM) in one service. Measure handshake size, latency and compatibility.
• 5. Roll out and monitor — Expand service by service, update certificates and signing, and add PQC requirements to vendor contracts.

Common mistakes

• Treating it as a certificate swap. Key exchange, signatures, firmware signing and stored data all need separate plans.
• Ignoring larger key and signature sizes. Post-quantum artifacts are bigger and can break packet limits, databases and embedded devices.
• Skipping vendors. Your exposure includes every SaaS and API that handles your data.
• Waiting for a deadline. Government timelines (such as NSA's CNSA 2.0) already point to the early 2030s for full transition.