Post-Quantum Migration Self-Check: From Algorithm Inventory to Hybrid TLS — 12 Things to Do in 2026

Why now, specifically

The most common misconception about post-quantum migration is that it waits for a quantum computer to exist. Three public timetables pin the start line to right now:

Windows brought hybrid ML-KEM into the Schannel TLS stack in July 2026. In other words, when your users hit a hybrid-capable server today, the link may already be running post-quantum key exchange — the bottleneck is that most servers haven't caught up.

The other driver is harvest now, decrypt later (covered in the companion post): RSA/ECC traffic recorded today can be retroactively decrypted once quantum hardware matures. If your data outlives that wait, you don't have time to spare.

The self-check framework: four steps, twelve items

Step 1: Algorithm inventory (CBOM)

The first move is not swapping algorithms — it's knowing what you run. A cryptographic bill of materials covers more surface than most teams expect:

• TLS certificates and handshake algorithms (RSA / ECDSA / ECDHE curves)
• JWT / OAuth signing algorithms (RS256? ES256?)
• SSH host and user keys
• Code and package signing (npm, maven, internal release pipelines)
• Database and backup encryption at rest
• VPN / IPsec / internal service mesh
• Algorithm calls hardcoded inside third-party dependencies

The output is a table of "algorithm × location × lifetime". Most teams discover an order of magnitude more RSA keys than they assumed.

Step 2: Rank by exposure

Not everything migrates at once. Two axes decide the order:

• Data lifetime: how long must this link's payload stay secret? (Medical records and genomic data > ordinary sessions)
• Signature lifetime: how long is the verification window? (10-20 year root certificates > short-lived JWTs)

Longer life, higher HNDL risk, earlier migration.

Step 3: Hybrid TLS (the best value move)

The consensus is not a rip-and-replace but hybrid mode: classical and post-quantum algorithms run together, and the session stays safe as long as either survives.

Server-side reality (October 2026):

• OpenSSL 3.5+ ships the X25519MLKEM768 key exchange group
• Major CDNs and load balancers are rolling out toggles
• Browsers (Chrome/Firefox) already speak it by default — flip the server side and it negotiates

One practical caveat: ML-KEM public keys and ciphertexts are an order of magnitude larger than X25519, and the bigger ClientHello can push past the TCP initial congestion window — watch TTFB on high-latency paths during rollout.

Step 4: Crypto-agility (make the next migration cheaper)

• Is algorithm selection configuration-driven (not hardcoded RS256 scattered through the code)?
• Can certificate rotation reissue the full fleet within a week, automatically?
• Do your libraries support pluggable providers (OpenSSL 3.x providers, JDK providers)?
• Do you have algorithm-deprecation monitoring (how many RSA-1024 handshakes still appear in logs)?

The 12-item checklist

• CBOM complete: every public-key crypto usage mapped
• Data lifetime and signature lifetime labeled per link
• HNDL-critical links identified (secrets with >7 year lifetime)
• TLS termination layer (CDN / LB / nginx) confirmed hybrid-capable
• Hybrid TLS rolled out in canary with handshake success and TTFB monitored
• All new certificates at RSA-3072+ or ECDSA P-256 minimum
• Ed25519 host keys distributed for internal SSH
• JWT signing evaluated for RS256 → ES256/EdDSA
• Dependency PQC support confirmed (OpenSSL 3.5+, liboqs, Bouncy Castle)
• Algorithm-deprecation dashboard exists
• One automated certificate rotation drill completed
• PQC timeline written into the security policy document

Implementer's note

Building this site's crypto tools gave me a close view of the browser side: WebCrypto (crypto.subtle) still ships only classical algorithms — RSA, ECDH, AES — with no native ML-KEM interface. Running PQC in a browser today means wasm (the liboqs family), and the payload size hasn't reached "casual online tool" territory yet. That's exactly why the RSA tool still teaches the classical system: once you understand it, PQC's differences (key sizes, encapsulation semantics) have something to be different from. Side note: decode one of your own certificates with the certificate decoder — the signature algorithm will almost certainly read RSA/ECDSA today. The day you see a composite PQC OID in there, migration has reached your doorstep.

Related reading

• Harvest now, decrypt later: whose data moves first
• Hashing vs. encryption, clearly separated
• RSA encryption, explained properly