If your scraper started getting blocked for no obvious reason in 2026, look at your TLS handshake. Browsers quietly switched on post-quantum key exchange — and tooling that didn't follow now sticks out on the very first packet.
Modern Chrome and Firefox now offer post-quantum key exchange (the hybrid X25519MLKEM768 group) by default, and major CDNs negotiate it. A real browser's TLS Client Hello therefore advertises specific PQ key-shares. Scraper stacks on older TLS libraries don't — so a request claiming to be Chrome but missing the PQ key-share is internally inconsistent, and anti-bot systems flag it. The fix: use a client whose TLS actually matches a current browser, on a real mobile IP.
Quantum-resistant cryptography stopped being theoretical. To protect against "harvest now, decrypt later" attacks, browsers began shipping hybrid post-quantum key exchange in TLS 1.3 — pairing classical X25519 with the ML-KEM (Kyber) lattice scheme. Through 2025 it rolled out behind flags; by 2026 it's on by default in current Chrome and Firefox, and CDNs negotiate it widely.
The security win is real. The side effect is what matters for scrapers: the TLS Client Hello changed shape. The list of supported groups and the key-shares a real browser sends now include a post-quantum entry. That entry is large and specific, and it shows up in fingerprints like JA4. Anything that negotiates TLS the old way is now, by definition, not a current browser.
Your User-Agent says "Chrome 13x", but your handshake omits the post-quantum key-share that every real Chrome 13x sends. The claim and the evidence disagree.
It's set deep in the TLS library, hard to fake piecemeal, and real users essentially never get it "wrong." That means high confidence and very few false positives — ideal for a blocker.
This is exactly the kind of cross-layer contradiction described in our pillar on the 2026 fingerprinting stack: the IP can be perfect, but if the transport layer betrays you, you're done. It also stacks directly on top of JA4 fingerprinting.
Post-quantum TLS adds quantum-resistant key exchange (commonly the hybrid X25519MLKEM768 group) to the TLS 1.3 handshake. Modern Chrome and Firefox offer it by default, and major CDNs negotiate it. That means a real browser’s Client Hello now advertises specific post-quantum key-share groups. Scraper stacks built on older TLS libraries don’t — so their handshake no longer looks like the browser they claim to be, and anti-bot systems flag the mismatch.
They compare the key-share and supported-group lists in your Client Hello against the expected profile for your claimed browser and version. A request that says "Chrome 13x" in its User-Agent but omits the post-quantum key-share a real Chrome 13x would send is internally inconsistent. Combined with JA4, this is a high-confidence, low-false-positive signal — which is why classifiers built on it report very high accuracy.
Use a client whose TLS stack actually matches a current browser — ideally drive a real, up-to-date browser engine rather than a raw HTTP client, or use a TLS-impersonation library that ships current post-quantum key-shares. Then route it through a real mobile IP so the network layer agrees too. Matching one layer while breaking another just moves the tell.
A real browser handshake on a real 4G/5G mobile IP is the consistent combination. 17+ countries, $4/GB, free endpoints and rotation.