Post-quantum HTTPS Migration Faces Enterprise Browser Challenges
Post-quantum HTTPS Migration Faces Enterprise Browser Challenges
Published on: July 10, 2026
Chromium’s Post-Quantum HTTPS Authentication Roadmap reads, on its surface, like a straightforward migration plan: add hybrid post-quantum key agreement, wait for the ecosystem to catch up, then require it. Underneath that plan sits an unresolved fight between two things browsers already handle well on their own and don’t yet handle well together: enforcing a security requirement at the origin level, and honoring the way cookies and session state have always scoped themselves across a domain. If you’re responsible for enterprise browser posture in 2026, that fight, not the cryptography, is the part that will actually bite you. 🚀
Chromium’s roadmap for post-quantum HTTPS authentication includes stages that add ML-KEM-based hybrids such as X25519MLKEM768, initially without removing classical options, allowing downgrade. Every stage after the first assumes the browser can reliably tell a client “this origin requires post-quantum security, and you should refuse anything less,” and remember that requirement the next time the client connects. This mechanism, HRPQ (HTTP Require-Post-Quantum header), is meant to provide this. However, cookies do not respect that boundary the same way. A domain-scoped cookie set by a post-quantum-secure origin is still readable by, and can still be overwritten by, a post-quantum-insecure sibling origin on the same registrable domain. Protecting a single origin with HRPQ is therefore insufficient on its own: a PQ-insecure origin can inject a domain-scoped cookie into a PQ-secure origin’s session state, and a PQ-secure origin’s cookies remain fully exposed to leakage toward any PQ-insecure sibling that has not yet adopted the requirement. This mismatch is exactly the gap a downgrade attacker would target. 🔒
The second failure mode is operational rather than cryptographic. Enterprise environments routinely terminate TLS at an inspection proxy and re-originate the connection to the actual destination, a pattern that predates post-quantum migration by well over a decade. TLS termination in these environments is distributed across an entire cryptographic perimeter, load balancers, API gateways, reverse proxies, and endpoint web servers, each an independent migration target that must support the same hybrid key agreement. If a proxy on that perimeter cannot complete a PQ handshake, and the destination origin has HRPQ set, the client cannot silently fall back the way it could with a soft security preference. The connection fails outright. Chrome, Firefox, and Safari have each shipped X25519MLKEM768 as the default hybrid key agreement in their current stable channels, which means the cryptographic half of this transition is close to solved. The architectural half is not. Security teams running TLS-inspecting proxies should inventory which proxy vendors and versions support PQ hybrid handshakes today, because Stage 3 of Chromium’s roadmap, requiring robust downgrade protection, will make silent classical fallback unavailable as an escape hatch. Teams evaluating HRPQ adoption for their own origins should treat cookie scoping as a first-order design constraint, not an implementation detail, and should assume that any subdomain not explicitly covered by the same PQ requirement is a viable pivot point for session hijacking regardless of how strong the covered origin’s cryptography is. HRPQ, as currently specified, is a reasonable stopgap. It is not, by the roadmap’s own framing, a long-term answer to downgrade protection, and technical teams building enterprise policy around it should plan for that ceiling now rather than discovering it during an incident. ⚠️