The 3 mistakes most teams make migrating to hybrid TLS.
We have done this enough times to know the failure patterns. They are remarkably consistent and remarkably preventable.
Hybrid TLS is not a config flag. We have lost count of the engineering teams that have walked into a quarter assuming “we will just enable X25519+ML-KEM in nginx and move on” and walked out three quarters later with an unfinished migration, a scarred runbook, and a customer-facing latency regression. The 1216-byte hybrid key share fundamentally changes assumptions you did not know you were making. Here are the three patterns we see derail most migrations, in roughly the order they fire.
Mistake 1 — Treating it as a TLS-only project.
Hybrid TLS is the most visible piece, but it is not the longest pole. Your code-signing pipeline still issues binaries signed by ECDSA or RSA-PSS. Your KMS still produces keys you cannot wrap with ML-KEM. Your S3 backups are encrypted with AES-256, fine, but the key-wrapping is RSA-OAEP. Your customer-facing JWTs are signed with ES256. None of those move when you flip your nginx config. A real migration sequences all four — TLS, KMS, signing, on-chain — with a ratchet that says “we never break the older clients while the newer clients adopt the new primitives.”
Mistake 2 — Underestimating the bandwidth blast.
X25519 alone is 32 bytes. X25519+ML-KEM-768 hybrid is 1216 bytes. Your ClientHello, which used to fit cleanly in a single packet, now spans multiple packets on networks with a small MTU — and any middlebox that does not pad properly will silently drop the second packet. We have seen production rollouts where 0.4% of customers experienced TLS handshake timeouts, sourced entirely to a regional ISP with a buggy carrier-grade NAT. The fix is a proper rollout sequence: telemetry first, then a 1% canary, then 10%, then full. Skipping the canary is the most common cause of a Friday-night rollback we get called in to clean up.
Mistake 3 — Naming a junior PM as the migration lead.
This sounds petty, but it is the single most predictive failure mode. Hybrid TLS migration is a senior engineering project disguised as a configuration change, and a junior PM will take the configuration-change estimate at face value. By the time the project is two-thirds through and someone realises the load balancer fronting the staging environment terminates TLS in a separate appliance that has no oqs-provider support, the team is six weeks behind on a deadline that already shipped to the board.
What works.
Senior engineers who have shipped this in production on at least three different stacks. A real telemetry surface — not just "was the handshake hybrid?" but the full distribution of negotiated groups, the handshake-latency p99 delta, the first-byte-time, and the abort rate, sliced by ISP. A pre-written runbook for the 4 things that go wrong (CDN backend incompatibility, middlebox MTU drop, KMS provider metadata mismatch, oqs-provider symbol clash). And a rollback that you have actually tested, not assumed.
Every QorTrace Labs PQC Migration engagement ships against this checklist. See the full service →