PQC Migration Checklist for Engineers

List every place public-key crypto runs: public and internal TLS/mTLS, SSH, JWT/JOSE and OIDC tokens, code and artifact signing, KMS/HSM keys, VPN/IPsec, database and at-rest key wrapping, S/MIME/PGP, and the third-party SDKs that do crypto on your behalf. CycloneDX 1.6 has a CBOM format for this.

Combine passive handshake capture (TLS and SSH groups, signature algorithms), your CA and Certificate Transparency records, and source/dependency scans for crypto API calls. Questionnaires miss hard-coded RSA in a forgotten service.

For each data flow, write down how many years it must stay confidential (x in Mosca’s inequality). Health, identity, financial and state data often need 10–25 years, which puts traffic recorded today in harvest-now-decrypt-later range.

Root CAs, firmware-signing keys and devices that stay in the field for 10–15 years are the slow part: a device that cannot be updated must ship with a quantum-safe root of trust before it leaves the factory.

Recorded key exchanges can be decrypted later, so confidentiality is at risk today. A forged signature needs a quantum computer at the moment of the attack. The exception is long-lived trust anchors with long lead times. Post-quantum security →

Map each system to the deadline that applies to you (EU 2030 for high-risk, CNSA 2.0, NIST 2030/2035) so the plan survives reorgs and budget cycles.

Route crypto through one internal library or a small set of vetted wrappers so switching an algorithm is a deploy, not a rewrite across 40 services.

Versioned ciphertext headers, key IDs, JWS alg values and certificate OIDs let you read old data and write new data at the same time. Formats that assume “always RSA” block migration.

OpenSSL 3.5+ ships ML-KEM, ML-DSA and SLH-DSA; Go 1.24+ has crypto/mlkem; JDK 24 added ML-KEM and ML-DSA; BoringSSL, AWS-LC and Bouncy Castle support them too. Old runtimes are the most common blocker.

Fixed-width DB columns, HTTP header and cookie limits, UDP datagrams, HSM object sizes and QR codes all have to hold ML-KEM-768 keys (1,184 B), ciphertexts (1,088 B) and ML-DSA-65 signatures (3,309 B). Parameter selection →

Ask CDN, cloud KMS, HSM, IdP, VPN and payment providers which FIPS 203/204/205 algorithms they support, whether they negotiate hybrid TLS, their FIPS 140-3 validation status, and the dates they commit to.

liboqs (Open Quantum Safe) is excellent for prototyping and interop tests but is not meant for production. In production use your platform’s maintained library, and FIPS 140-3 validated modules where compliance requires them, as validations become available.

The hybrid group combines X25519 with ML-KEM-768 and stays secure if either one holds. OpenSSL 3.5+, Go 1.24+ crypto/tls (on by default), BoringSSL and Chrome 131+ support it, and CDNs such as Cloudflare already negotiate it with browsers. Start at the edge. Hybrid TLS guide →

The hybrid key share adds about 1.2 KB, so the ClientHello no longer fits in one ~1,500-byte packet. Some firewalls, load balancers and IDS devices that expect a single-segment ClientHello drop or reset the connection. Test through your real network path. Hybrid TLS guide →

Go services get the hybrid by default only if Config.CurvePreferences is unset; an explicit list must add X25519MLKEM768. Check sidecars, ingress controllers and database drivers separately.

Recent OpenSSH releases offer mlkem768x25519-sha256 (and the older sntrup761x25519-sha512) and prefer them by default. Update bastions, CI runners and the SSH libraries embedded in deploy tools.

ML-KEM-768 targets NIST category 3 and is the common default. Use ML-KEM-1024 where CNSA 2.0 applies; keep ML-KEM-512 for constrained cases after a deliberate review. Parameter selection →

IKEv2 can add ML-KEM through RFC 9370 multiple key exchanges. For data at rest, AES-256 is fine; the exposure is RSA/ECDH used to wrap or transport data keys, so re-wrap those under ML-KEM or a symmetric KEK.

ML-DSA (FIPS 204) is fast with moderate sizes. SLH-DSA (FIPS 205) relies only on hash functions but has large, slow signatures, which suits rarely used roots of trust. For firmware, CNSA 2.0 specifies stateful LMS/XMSS. Dilithium / ML-DSA →

ML-DSA-44 already means a 2,420 B signature and a 1,312 B public key, against 64 B and 32 B for Ed25519. A certificate chain carries several of each, and JWTs, cookies and log lines grow with them. Lattice signatures →

Code and artifact signing, internal PKI and service-to-service tokens can move now. Public WebPKI certificates depend on CA/Browser Forum and browser support that is still being settled.

During migration, sign with both a classical and a PQ algorithm (separately or as an IETF composite signature) so verifiers can upgrade at their own pace. Decide which verifier requires what, and when the classical half is dropped.

CNSA 2.0 expects quantum-resistant software and firmware signing exclusively by 2030. Boot ROMs and hardware roots of trust have multi-year lead times, so these go into hardware roadmaps now.

Run known-answer tests and NIST ACVP vectors for FIPS 203/204/205 in CI, plus interop tests against a second implementation. Encoding bugs are the most common failure.

KyberSlash showed that secret-dependent division leaked keys through timing in several ML-KEM/Kyber implementations. Prefer implementations with constant-time audits, and don’t modify their internals. Kyber / ML-KEM →

ML-KEM is fast, often cheaper per operation than X25519; the real cost is bytes on the wire and in storage. Measure handshake p50/p99, egress, and signature verification cost at peak.

Canary by region or client population, track handshake failures by client and network, and keep a single switch that reverts to classical groups without a code deploy.

Log the negotiated TLS group and signature algorithm, chart the share of hybrid connections, and alert on regressions. Feed new findings back into the CBOM so the inventory stays current.