Modernize transport key establishment and certificate authentication as related but separate workstreams.

Content reviewed: October 25, 2026
Hybrid TLS key establishment
RFC 10024, published in August 2026, specifies three TLS 1.3 groups combining ML-KEM with ephemeral elliptic-curve Diffie–Hellman. One is X25519MLKEM768. Select profiles supported by the actual endpoints and approved for your environment.
Library support is not proof of negotiated use. Verify the handshake on every relevant path, including traffic terminated by a CDN, load balancer, proxy, or service mesh. Each termination point creates a separate connection.
Certificates are a separate dependency
A hybrid key exchange does not by itself replace certificate signatures or change the trust store. PKI migration includes certificate authorities, enrollment, revocation, hardware key storage, path validation, code signing, and relying-party compatibility. Check the current supported certificate profiles before a rollout.
An interoperability test plan
- Test representative browsers, SDKs, operating systems, and constrained clients.
- Measure handshake size, fragmentation, latency, memory, and connection success.
- Exercise inspection devices, mutual TLS, session resumption, and failover paths.
- Record the negotiated group and the certificate-chain signature algorithms separately.
- Make fallback policy explicit and alert on unexpected loss of the intended protection.
Avoid a misleading completion claim
“The edge supports PQC” describes one capability. It does not establish quantum resistance for every internal hop, archived dataset, signature, or device. Report exactly which connection and cryptographic function were tested, with version and configuration evidence.