# Post-Quantum TLS on BIG-IP: ML-KEM Hybrids From 17.5 to 21.1 > BIG-IP's post-quantum story is a lineage: X25519MLKEM768 hybrid key exchange arrived in the 17.5.0 era, and 21.1.0 completes the NIST curve family with SecP256r1MLKEM768 and SecP384r1MLKEM1024, on both client-side and server-side TLS, per FIPS 203. Around it, 21.1 makes the classical side faster and stricter: X25519 hardware acceleration via Intel QAT on by default, parent SSL profiles defaulting to TLS 1.3 and DTLS 1.2, an OCSP request nonce, and C3D enhancements. Here is what each piece means and how to roll it out without breaking a single legacy client. Source: https://ronutz.com/en/learn/bigip-post-quantum-tls Updated: 2026-07-08 Related tools: https://ronutz.com/en/tools/cipher, https://ronutz.com/en/tools/f5-cipher-string-expander, https://ronutz.com/en/tools/f5-ssl-profile-explainer --- The quantum threat to TLS is a harvest problem before it is a decryption problem: traffic recorded today can be decrypted the day a large enough quantum computer breaks the elliptic-curve key exchange that protected it. The defense NIST standardized in FIPS 203 is ML-KEM, a lattice-based key encapsulation mechanism, and the deployment pattern the industry converged on is the hybrid: run a classical elliptic-curve exchange and an ML-KEM encapsulation in the same handshake and mix both secrets, so the session is safe unless both are broken. BIG-IP has been walking this road for a while; 21.1.0 is where the road gets wide. ## The lineage: one hybrid becomes a family The first hybrid landed in the 17.5.0 era: X25519MLKEM768, the pairing of the X25519 curve with ML-KEM-768 that browsers deployed first. BIG-IP's cipher-rule syntax already speaks it, in the same dh-groups list as its classical siblings, and F5's own 21.0 release notes show classical and PQC group names coexisting in one rule. What 21.1.0 adds is the NIST-curve side of the family: SecP256r1MLKEM768 and SecP384r1MLKEM1024, hybrid key exchanges pairing the P-256 and P-384 curves with ML-KEM-768 and ML-KEM-1024 respectively, supported for both client-side and server-side TLS. That last clause matters more than it looks: BIG-IP can now negotiate post-quantum hybrids with browsers on the ClientSSL side and with backend servers on the ServerSSL side, so a full-proxy deployment does not become the one classical link in an otherwise quantum-resistant chain. Why three hybrids instead of one? Ecosystems. X25519MLKEM768 is what the browser world deployed; the SecP variants exist for environments whose compliance regimes are written around NIST curves, and P-384 with ML-KEM-1024 serves the higher-security tier. The practical guidance is unglamorous: offer the hybrids your clients actually send, keep classical groups in the list behind them, and let negotiation do its job. The [cipher decoder](https://ronutz.com/en/tools/cipher) and the [F5 cipher-string expander](https://ronutz.com/en/tools/f5-cipher-string-expander) both read the group and cipher names involved, and the [SSL profile explainer](https://ronutz.com/en/tools/f5-ssl-profile-explainer) shows where the configuration lives. ## The classical side gets faster: X25519 on QAT A hybrid handshake does more math than a classical one, which makes 21.1's other key-exchange feature well timed: hardware acceleration for X25519 via Intel QuickAssist Technology on QAT-equipped platforms. Per the release notes it is enabled by default, applies to both ClientSSL and ServerSSL profiles, requires no configuration, and falls back to software automatically when the hardware is absent. X25519 is the workhorse of TLS 1.3 forward secrecy, and it is also one half of the most-deployed hybrid, so offloading it buys back CPU exactly where PQC spends it. ## Stricter defaults and the supporting cast 21.1 also moves the baseline. New Client SSL and Server SSL parent profiles default to TLS 1.3 with DTLS 1.2, which changes what a freshly created profile negotiates before anyone tunes it; existing profiles keep their configured behavior, but every new one starts modern. Around the handshake, the release adds a configurable nonce on OCSP requests, a replay-resistance option for certificate status checking, and a set of C3D enhancements for the client-certificate constrained-delegation path: a notBefore override and caching for the forged certificates, SubjectDirectoryAttributes support, and new SSL::c3d iRules commands. And one adjacent, verified note from F5's launch material for readers running VPNs: BIG-IP Zero Trust Access, formerly APM, gains quantum-resistant TLS/SSL VPN tunneling with the X25519 plus ML-KEM-768 hybrid in 21.1, client-side and server-side, with quantum-secure IPsec signposted as coming later. The tunnel that outlives every web session deserves the harvest-now-decrypt-later analysis most of all. ## Rolling it out without breaking anyone The pleasant surprise of hybrid key exchange is that it is negotiated, not imposed. A client that has never heard of ML-KEM ignores the hybrid groups in your list and lands on classical ECDHE exactly as before; a browser that prefers X25519MLKEM768 gets it. The rollout discipline is therefore about order and observation rather than risk: enable the hybrids on ClientSSL first, where the browser population upgrades itself, watch the negotiated-group distribution, then extend to ServerSSL as your backend fleet gains support. Two things to verify before declaring victory. Handshake size: ML-KEM key shares are kilobytes where curve points were bytes, so a ClientHello that always offered a fat PQC share can trip ancient middleboxes and tight MTU paths; test the odd corners of your estate. And hardware reality: QAT acceleration covers the X25519 half, so measure handshake CPU on your actual platform before and after enabling hybrids at scale rather than assuming the offload absorbs everything. The [flagship 21.x overview](https://ronutz.com/en/learn/bigip-21x-whats-new) holds the release-wide context, and the [NIST PQC standards article](https://ronutz.com/en/learn/nist-pqc-standards) covers what ML-KEM actually is under the hood.