COMMENTARY: 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.
Four stages, one structural assumption
The roadmap divides the transition into four stages.
Stage one adds post-quantum key exchange options, currently ML-KEM-based hybrids such as X25519MLKEM768, without removing classical elliptic-curve options, so a downgrade to classical crypto remains possible and silent.
Chrome's rollout of this stage, now progressing past initial Stable channel deployment as documented in the project's
quarterly security updates, has already required resolving server incompatibilities discovered during beta testing.
Related reading:
Later stages require a post-quantum-capable PKI from sites seeking robust downgrade protection, and the final stage requires full migration, at which point classical-only handshakes stop being accepted at all.
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. That is precisely the mechanism HRPQ, a proposed HTTP Require-Post-Quantum header modeled on HSTS preload lists, is meant to provide.
Where cookie scoping breaks the model
HSTS works because it operates at the level Chromium's security model already treats as authoritative: the origin, and by extension, the registrable domain when `includeSubDomains` is set.
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, because cookie jars are shared across the domain regardless of which specific origin negotiated which cipher suite.
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.
The roadmap's own authors acknowledge that a site may be ready for HSTS's `includeSubDomains` semantics well before it is ready for the equivalent HRPQ guarantee, or the reverse, and that mismatch is exactly the gap a downgrade attacker would target.
Enterprise TLS proxies are the downgrade vector nobody priced in
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.
Recent analysis of
operationalizing post-quantum TLS in regulated financial infrastructure documents that 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 before the deployment can be called complete. 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. Clients that roam between a proxied enterprise network and an unproxied network, the ordinary behavior of any laptop moving between office and home, will see that failure appear and disappear as they change networks, with no obvious explanation visible to the end user or, often, to the help desk.
What this means for technical teams now
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.
To make that check something a team can run rather than merely reason about, I built and published
hrpq-gap-scan, an open-source scanner that probes a domain and its subdomains for this exact combination of gaps.
