PQC Migration Playbook

Why Migrate Now

The dominant motivation is the Harvest Now, Decrypt Later threat model. Adversaries with resources can capture encrypted traffic today, store it indefinitely, and decrypt it once a sufficiently capable quantum computer is available. Anything you encrypt with RSA, classical ECDH, or ECDSA today is at risk if it is intercepted and your data needs to remain confidential past roughly 2030 - 2035. The migration target is the NIST-standardized PQC suite published in 2024 - 2025: ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+). These are significantly larger than their classical counterparts in key and signature size, which means migration is not a drop-in replacement - protocols, on- the-wire formats, and storage all need attention.

The Migration Window

Major standards bodies have published end-of-life targets for quantum-vulnerable algorithms. Korthex's Baseline Registry tracks all of these and surfaces the applicable deadline in every finding. "2030" sounds far away but isn't. A real-world migration of an established product touches build systems, key-management infrastructure, on- disk formats, network protocols, third-party integrations, and the test suite. Teams that started in 2024 routinely report 18 - 30 month migration timelines for non-trivial systems.

Hybrid Cryptography

During the transition, most teams adopt a hybrid approach: the new PQC primitive is combined with a classical primitive (e.g. ML-KEM + X25519) so the system is secure as long as at least one of the two remains unbroken. This protects against both the quantum threat (classical primitive breaks) and any unforeseen weakness in the new PQC primitive (classical primitive holds the line). Korthex recognizes the standardized hybrid constructions (e.g. Kyber + X25519 for TLS, Dilithium + Ed25519 for signatures) and treats them as fully PQC-ready. A finding tagged "hybrid" is not raised as a PQC-migration item.

Recipe: RSA Encryption / KEM → ML-KEM

The most common migration. Wherever you use RSA-OAEP to encrypt a session key or to wrap a symmetric secret, you can swap in ML-KEM. This applies to TLS session establishment, JWE-style payload encryption, and most "encrypt with public key, decrypt with private key" workflows. Steps Scan and locate. korthex scan . flags every RSA-OAEP call site. Inventory. Open the Inventory screen in the Dashboard and search the Census view for RSA . You get every RSA variant in use with its occurrence count, NIST status and PQC flag; the Files view maps each variant to the files it lives in. Plan. korthex plan create produces a sequenced migration plan; korthex impact cost adds the engineer-hour estimate. Replace key-pair generation. Generate ML-KEM key pairs alongside the existing RSA pair. The two coexist during the migration. Update the wire format. Add a versioning field if your protocol doesn't have one. New deployments speak hybrid (RSA + ML-KEM); old deployments speak RSA only. Migrate consumers. Update consuming services one at a time to read the hybrid format. Sunset RSA. Once all consumers handle hybrid, generate new keys as ML-KEM only and rotate. Use korthex dataflow query --from "key-gen:RSA" --to "encrypt" to map every consumer that depends on a particular RSA key before you start.

Recipe: ECDSA / RSA Signatures → ML-DSA

Signature migration is generally easier than encryption migration because signatures are verifier-side: as long as the verifier supports the new scheme, new signers can adopt it without breaking old verifiers (provided you don't remove the old scheme until all verifiers are updated). Identify all signers and verifiers. Filter the Census view to the Signature family and note every ECDSA and RSA entry, then use the Files view to resolve each to its call sites. The inventory records the algorithm, not the intent - it does not separate signing from encryption use of the same key type, so confirm the direction in the Dataflow graph before you migrate a call site. Upgrade verifiers first. Roll out ML-DSA verification support across all consuming services. Until this is complete, no signer can switch. Switch new signing operations to hybrid. A hybrid signature pair (Ed25519 + ML-DSA) is the lowest-risk path. Re-sign long-lived artifacts. If you sign documents or release artifacts that need to remain verifiable for years, re-sign them under ML-DSA before retiring the legacy chain. Decommission the legacy scheme only after all verifiers and all in-flight signed artifacts have been transitioned.

Recipe: Long-Lived Signatures → SLH-DSA

For signatures whose validity needs to extend many decades (firmware, root certificates, archival), SLH-DSA (SPHINCS+) is the most conservative choice. It is a hash-based scheme that relies only on the security of its underlying hash function - no novel mathematical assumptions. Significantly larger signatures than ML-DSA (KB-scale, not bytes). Slower signing operations - not suited to high-throughput paths. Excellent fit for boot-chain signatures, archive signatures, or any document that needs to be verifiable far into the future. Korthex flags long-lived signature use sites in the Planner output with a "long-lived" tag, recommending SLH-DSA over ML-DSA for those specific items.

How Korthex Helps End-to-End