As of May 15, 2026, PQC for TLS is deployed through TLS 1.3 hybrid ML-KEM groups, not TLS 1.4. Learn the OpenSSL 3.5 rollout path. Read now.
What “post-quantum TLS” actually means in production
Post-quantum cryptography (PQC) for TLS is not a new protocol revision. As of May 15, 2026, the practical path is TLS 1.3 with hybrid ML-KEM groups: classical key exchange and a post-quantum key encapsulation mechanism run together so the session key depends on both. If either side is broken later, the other still protects the handshake. That design is why you will not see a “TLS 1.4 switch” on the roadmap for PQC—you enable stronger groups inside the TLS 1.3 stack you already operate.
For developers, the mental model is simple. Certificates, ALPN, session tickets, and application framing stay familiar. What changes is which named groups your client and server offer, prefer, and accept during the handshake, and whether both ends share a compatible hybrid ML-KEM option.
Hybrid ML-KEM groups: what to configure and verify
Hybrid ML-KEM groups combine a classical elliptic-curve share with an ML-KEM encapsulation. Clients advertise support; servers pick an intersection. If no hybrid group is shared, the connection falls back to classical groups—or fails, if you have disabled classical options. That fallback behavior is the main operational risk: a misconfigured “PQC-only” policy can lock out older clients, while leaving hybrids disabled means you never get the quantum-resistant half of the bargain.
When you roll this out, treat it like any other cipher-suite change. Stage in pre-production with a known-good client that supports hybrid ML-KEM. Confirm the negotiated group in logs or a handshake dump. Check that resumption, mutual TLS, and intermediate proxies still complete. Only then expand the set of servers that prefer hybrid groups over classical-only defaults.
OpenSSL 3.5 rollout path
OpenSSL 3.5 is the practical vehicle many stacks use to expose hybrid ML-KEM for TLS 1.3. The rollout path is library first, then the applications that link it. Upgrade the OpenSSL build (or the platform package that ships it), rebuild or restart services that statically link or pin an older provider, and verify that your TLS configuration surface can name the hybrid groups your deployment requires. Language runtimes, reverse proxies, and service meshes only gain PQC TLS when the underlying OpenSSL (or equivalent) they use is new enough and actually loaded at runtime—not merely installed side-by-side.
- Inventory processes that open TLS listeners or make outbound HTTPS; note which OpenSSL they load.
- Upgrade to OpenSSL 3.5 where those processes allow it; restart so the new library is in use.
- Enable hybrid ML-KEM groups in server and client config; keep a classical group available until peers are verified.
- Watch handshake failures and negotiated-group metrics before making hybrid the preferred path fleet-wide.
Developer checklist before you call it done
Document which services terminate TLS themselves versus terminate at a load balancer. PQC only helps on the hops that actually negotiate hybrid ML-KEM; an upgraded edge with a classical backend hop is only half a story if that backend is in scope. Align client SDKs, CI health checks, and synthetic probes so they speak the same groups as production. After cutover, keep a short rollback: re-prefer classical groups without a full library downgrade if a peer class misbehaves.
Post-quantum TLS in 2026 is an engineering change to key agreement inside TLS 1.3, delivered through hybrid ML-KEM and libraries such as OpenSSL 3.5—not a leap to TLS 1.4. Configure the groups, prove negotiation end to end, and expand preference only when your clients and middleboxes keep pace.