[{"data":1,"prerenderedAt":145},["ShallowReactive",2],{"blog-\u002Fblog\u002Fdoes-chrome-support-post-quantum-cryptography":3},{"id":4,"title":5,"author":6,"authorTitle":7,"authorUrl":7,"body":8,"canonical":7,"category":81,"date":82,"description":83,"draft":84,"extension":85,"faqs":86,"findingsSource":7,"geo":99,"howto":7,"howtoTitle":7,"image":7,"industries":101,"keyFindings":7,"meta":104,"modified":7,"navigation":105,"path":106,"pullquote":7,"recommendations":7,"references":107,"related":117,"seo":130,"seoTitle":131,"signposts":7,"slug":132,"stats":133,"stem":136,"tags":137,"tldr":143,"__hash__":144},"blog\u002Fblog\u002Fdoes-chrome-support-post-quantum-cryptography.md","Does Google Chrome Support Post-Quantum Cryptography?","ArcQubit Team",null,{"type":9,"value":10,"toc":73},"minimark",[11,16,29,35,39,47,50,54,60,66,70],[12,13,15],"h2",{"id":14},"the-answer-up-front","The answer, up front",[17,18,19,20,24,25,28],"p",{},"Yes, Google Chrome supports post-quantum cryptography. It negotiates the hybrid key exchange X25519MLKEM768 by default for TLS 1.3 and QUIC connections, which combines the classical X25519 algorithm with the NIST standard ML-KEM. When a server also supports it, the connection is already protected against the harvest-now-decrypt-later threat for key establishment, with no setting to enable ",[21,22,23],"span",{},"1",", ",[21,26,27],{},"2",".",[17,30,31],{},[32,33,34],"em",{},"Last verified: Oct. 2, 2026.",[12,36,38],{"id":37},"what-chrome-protects-today","What Chrome protects today",[17,40,41,42,44,45,28],{},"Chrome began shipping a hybrid post-quantum key exchange in 2023 (as X25519Kyber768) and switched to the finalized X25519MLKEM768 group, enabled by default on desktop, from version 124 in April 2024 ",[21,43,23],{},". The design is deliberately hybrid: the browser and server derive shared secret material from both X25519 and ML-KEM and combine them, so the connection stays secure as long as either component holds. That keeps the well-studied classical exchange while adding lattice-based protection against a future quantum attacker ",[21,46,27],{},[17,48,49],{},"The practical effect is large. By early 2026, a substantial and rising share of browser-initiated TLS 1.3 handshakes carried an X25519MLKEM768 key share, because both Chrome and the major content delivery networks prefer it when both ends support it.",[12,51,53],{"id":52},"what-chrome-does-not-do-yet","What Chrome does not do yet",[17,55,56,57,28],{},"Supporting a post-quantum key exchange protects confidentiality, not authentication. The certificates that prove a server's identity still use classical signatures such as RSA and ECDSA. Post-quantum signatures are much larger, so dropping them into traditional X.509 certificates would bloat every handshake ",[21,58,59],{},"3",[17,61,62,63,65],{},"Google's answer is not to put post-quantum signatures into the current certificate format. Chrome has no immediate plan to add post-quantum X.509 certificates to its root store, and is instead helping develop Merkle Tree Certificates (MTCs) through the IETF to keep the authentication side efficient as it migrates ",[21,64,59],{},". So the key-exchange half of the browser migration is well underway, and the signature half is still being designed.",[12,67,69],{"id":68},"what-this-means-for-your-organization","What this means for your organization",[17,71,72],{},"Browser support is only one surface. Chrome protecting a user's connection does nothing for the quantum-vulnerable cryptography inside your own applications, APIs, VPNs, internal services, firmware, and stored data. The browser result is a useful signal that the transition is real and already shipping, not a reason to treat your own estate as covered. The work that matters for you is the same as ever: find where quantum-vulnerable cryptography lives, prioritize it, and migrate key establishment first.",{"title":74,"searchDepth":75,"depth":75,"links":76},"",2,[77,78,79,80],{"id":14,"depth":75,"text":15},{"id":37,"depth":75,"text":38},{"id":52,"depth":75,"text":53},{"id":68,"depth":75,"text":69},"Engineering","2026-10-02","Chrome supports post-quantum cryptography through the hybrid X25519MLKEM768 key exchange, on by default. What that covers, what it does not, and why signatures lag.",false,"md",[87,90,93,96],{"q":88,"a":89},"Does Chrome support post-quantum cryptography?","Yes. Chrome negotiates the hybrid key exchange X25519MLKEM768 by default for TLS 1.3 and QUIC, so most HTTPS connections to servers that also support it are already quantum-resistant for key establishment [1], [2].",{"q":91,"a":92},"Do I need to turn it on?","No. For most desktop connections it is on by default and negotiated automatically when the server supports it. You do not need to change a setting [1].",{"q":94,"a":95},"Does Chrome use post-quantum certificates?","Not yet. Chrome has no immediate plan to add post-quantum X.509 certificates to its root store, and is instead developing Merkle Tree Certificates (MTCs) in the IETF to keep handshakes efficient [3].",{"q":97,"a":98},"What is still unprotected?","The hybrid key exchange protects confidentiality (key establishment). Authentication still relies on classical signatures in certificates, so the signature side of the migration is not finished [3].",[100],"global",[102,103],"Cross-Sector","Information Technology",{},true,"\u002Fblog\u002Fdoes-chrome-support-post-quantum-cryptography",[108,111,114],{"label":109,"url":110},"The Chromium Projects, \"Protecting Chrome Traffic with Hybrid Kyber KEM,\" Chromium Blog, Aug. 2023","https:\u002F\u002Fblog.chromium.org\u002F2023\u002F08\u002Fprotecting-chrome-traffic-with-hybrid.html",{"label":112,"url":113},"D. O'Brien et al., \"Advancing Our Amazing Bet on Asymmetric Cryptography,\" Google Online Security Blog, 2024","https:\u002F\u002Fsecurity.googleblog.com\u002F2024\u002F05\u002Fadvancing-our-amazing-bet-on-asymmetric.html",{"label":115,"url":116},"Google Online Security Blog, \"Cultivating a Robust and Efficient Quantum-Safe HTTPS,\" Feb. 2026","https:\u002F\u002Fsecurity.googleblog.com\u002F2026\u002F02\u002Fcultivating-robust-and-efficient.html",[118,121,124,127],{"label":119,"url":120},"Hybrid vs. Pure Post-Quantum Key Exchange","\u002Fblog\u002Fhybrid-vs-pure-post-quantum",{"label":122,"url":123},"NIST Post-Quantum Standards Guide","\u002Fblog\u002Fnist-pqc-standards-guide",{"label":125,"url":126},"Harvest Now, Decrypt Later","\u002Fblog\u002Fharvest-now-decrypt-later",{"label":128,"url":129},"Post-Quantum Cryptography Explained","\u002Fblog\u002Fpost-quantum-cryptography-explained",{"title":5,"description":83},"Does Chrome Support Post-Quantum Cryptography?","does-chrome-support-post-quantum-cryptography",[134,135],"Chrome enabled X25519MLKEM768 by default for desktop starting with version 124 in April 2024 (Chromium, 2024).","By early 2026, X25519MLKEM768 key shares appeared in a large and growing share of browser TLS 1.3 handshakes, on the order of 30 to 57 percent depending on the measurement (Cloudflare Radar; independent telemetry, 2026).","blog\u002Fdoes-chrome-support-post-quantum-cryptography",[138,139,140,141,142],"post-quantum cryptography","hybrid key exchange","ML-KEM","quantum-safe algorithms","primer","Yes. Chrome negotiates the hybrid post-quantum key exchange X25519MLKEM768 by default for TLS 1.3 and QUIC, protecting key establishment against harvest-now-decrypt-later attacks.","279WzVEBtOIcTCruYU5cYqeBwjfkw9mOBybEXpTZ4PU",1792182883669]