From classical crypto to PQC
Choosing ML-KEM and ML-DSA is the easy part. The work is finding every place you use RSA and ECC, deciding what to fix first, and rolling out replacements without breaking the systems that depend on them.
This is the six-step strategy Meta and others use in production, condensed — paired with the physical realities PQC forces on real systems.
Start with Mosca’s inequality
Before you touch any code, work out which data is already at risk. If the time your data must stay secret (X) plus your migration time (Y) is greater than the time until a quantum computer arrives (Z), you have already failed for that data class — so it goes to the front of the queue.
The six-step migration strategy
- Step 1
Prioritize by risk
Classify systems by exposure. Highest priority: anything carrying long-lived secrets that an adversary could harvest today and decrypt later. Medium: systems facing an online quantum attacker. Low: symmetric-only systems, which only need larger keys.
- Step 2
Build a cryptographic inventory
You cannot migrate what you cannot see. Map every place cryptography is used — protocols, libraries, certificates, hardcoded keys — with automated discovery tools backed by developer reporting. A Cryptographic Bill of Materials (CBOM) turns this into a living asset.
- Step 3
Address external dependencies
Identify the blockers you don't own: community standards (NIST, IETF, ISO), hardware support (HSMs, CPUs, TPMs), and production-grade PQC implementations such as liboqs. Migration moves at the speed of your slowest dependency.
- Step 4
Design the PQC components
Select algorithms per NIST guidance: ML-KEM for key exchange, ML-DSA for signatures, with SLH-DSA as a hash-based backup. Default to ML-KEM-768; drop to ML-KEM-512 only where performance is genuinely prohibitive.
- Step 5
Implement guardrails
Stop the bleeding while you migrate. Update internal cryptography guidelines, discourage the creation of new quantum-vulnerable keys, and block affected APIs in centrally managed build systems so new systems are born crypto-agile.
- Step 6
Integrate — hybrid first
Deploy via a hybrid approach (classical + PQC) before full replacement. Hybrid key exchange keeps a classical safety net while you gain confidence in the new primitives — the same path Cloudflare, Chrome, Apple, and Signal have already taken.
What to migrate to
Deploy these as hybrids (e.g. X25519 + ML-KEM-768) so a break in either layer alone is not catastrophic. Browse the full catalog in the PQC Toolkit.
What changes physically
PQC is not a drop-in replacement. Bigger keys and signatures ripple through storage, networks, and hardware — these are the surprises that derail migrations.
Database schemas
VARCHAR(255) columns sized for classical keys must grow to hold 1,000+ byte PQC public keys.
Network fragmentation
PQC keys and certificates can exceed the 1,500-byte MTU, forcing packet fragmentation and added latency.
TLS handshake inflation
ML-DSA certificate chains push handshakes from 2–3 KB to 10–15 KB — painful on weak mobile links.
The key-hierarchy trap
AES-256 at rest is quantum-safe, but the RSA/ECDH layers wrapping those keys are fully exposed. Break the wrapper and you break the data.
IoT & embedded constraints
Devices with 8–16 KB of RAM struggle with 1,200-byte keys and 2.4 KB signatures; baked-in silicon can't be patched at all.
The bottleneck shifts
Lattice math is fast on modern CPUs — often faster than RSA — so the constraint moves from compute to network bandwidth.
Build crypto-agility into everything new
This migration will not be the last. “Quantum-safe” is a present-tense judgment about today’s best evidence, not a permanent certificate — SIKE was a finalist until it was broken on a laptop in an hour. Design systems so a primitive can be swapped without rebuilding the system, and the next transition becomes a configuration change instead of a crisis.