Post quantum TLS: why we started migrating our APIs in 2026

Post quantum cryptography used to be a research lab topic. After NIST finalised the Module Lattice KEM standard and both major browsers shipped ML KEM 768 hybrid key exchange by default in late 2025, it stopped being optional for anyone running long lived TLS endpoints that carry regulated data.

Why 2026, not 2030

The threat is not a quantum computer tomorrow. It is the "harvest now, decrypt later" pattern: traffic recorded today can sit in storage until a capable machine exists, at which point classical ECDHE keys are retroactively readable. For a fuel retail or fiscal data integration with a twenty year retention requirement, this is already a compliance question, not a speculative one.

What we changed first

We switched public API edges to hybrid X25519+ML KEM 768 key exchange, keeping classical signatures for now. Our reverse proxies (nginx 1.27 with the OpenSSL 3.5 provider) negotiate the hybrid group when the client supports it and fall back cleanly. We measured a 1.8 ms median handshake overhead and a 1.1 KB increase in ClientHello size small enough that we did not need to change any client tuning.

What broke

Not much, but the failures were noisy. Three older B2B clients on pinned CA bundles rejected the larger ServerHello. Two embedded devices at customer sites a payment terminal firmware from 2019 and an ATG gateway from 2021 did not support the new groups and had to stay on a legacy listener during a grace period. Document these in the plan; do not discover them in production.

What comes next

Hybrid KEM is the easy step. Post quantum signatures are the harder one: ML DSA certificates are significantly larger and will force some honest conversations about OCSP stapling and chain depth. We expect to pilot PQ signatures on internal only endpoints in Q3 and make a customer facing decision at the end of the year.