Windows 11, TLS 1.3 and Post Quantum Crypto FAQ

This blog post captures commonly asked questions and answers about deploying, using, and testing TLS 1.3 on Windows with hybrid post-quantum cryptography (PQC) support.

Q01: What is the real threat?​

A: The threat is that attackers can collect encrypted network data and then break the asymmetric cryptography (RSA/ECC/DH) used to protect bulk data encryption keys (AES) once cryptographically relevant quantum computers come online. This is known as Harvest Now, Decrypt Later (HNDL).

Q02: Do I need to use TLS 1.3 for PQ support?​

A: Yes. Earlier versions of TLS, including TLS 1.0, TLS 1.1, and TLS 1.2, do not and will not support post-quantum key establishment.

Q03: Does enabling TLS 1.3 give me hybrid PQ support?​

A: No. By default, you will get ‘classic’ crypto algorithms. You must enable the PQ algorithms; this is explained later.

Q04: What Windows OS version must I use to get TLS 1.3 and post-quantum support?​

A: TLS Hybrid Key Exchange using ML-KEM groups is available on Windows 11 starting with update KB5089573 for 24H2 and 25H2 and KB5095091 for 26H1.

For Windows Server 2025 use the patch from July 14, 2026-KB5099536 (OS Build 26100.33158)

Q05: What is hybrid crypto in TLS 1.3?​

A: Hybrid crypto establishes cryptographic keys by combining elliptic-curve cryptography with post-quantum cryptography, allowing the client and server to use both algorithms during the TLS 1.3 key establishment. It’s a hedge in case the PQ cryptography is broken.

Q06: What crypto is used in hybrid?​

A: Like all crypto in TLS, this is flexible; however, the most common hybrid crypto for web browser-based key establishment is X25519_MLKEM768 which combines the classic X25519 Elliptic Curve with post-quantum ML-KEM.

Q07: What is ML-KEM?​

A: ML‑KEM (Module-Lattice Key Encapsulation Mechanism) is the new quantum-resistant method for securely establishing cryptographic keys between hosts. It is defined in FIPS 203.

Q08: Is hybrid TLS 1.3 enabled in Windows today?​

A: No not by default; you must enable it. If you use Group Policy, you can set the policy there. If the machine does not have GP, then you can use the following from an elevated PowerShell prompt:

Enable-TlsEccCurve -Name "X25519_MLKEM768" -Position 0
Note that -Position 0 is important as it places the hybrid group X25519_MLKEM768 at the top of the preferred group list. If you do not do this, you might not negotiate to the hybrid PQC group.

IMPORTANT: Note that Group Policy will override this setting, so don’t mix-n-match! If you see your group ordering change after calling the PS cmdlet, it's probably GP coming in and overriding the setting.

Q09: In the prior answer, you used the word ‘group’ what is a group?​

A: In TLS 1.3, a "group" is simply the method (or algorithm) that the client and server agree to use to securely establish keys during the connection. Examples include X25519 (the most common Elliptic Curve TLS 1.3 group) or the newer hybrid X25519_MLKEM.

As a side note, the word "group" isn't arbitrary - it comes from the underlying algebra (elliptic-curve groups, finite-field multiplicative groups). It's mathematically precise; it's just opaque to anyone who isn't thinking about group theory! However, ML-KEM isn't built on a group at all - its hardness comes, in part, from lattices.

Q10: Is a group the same as a ciphersuite in TLS 1.3?​

A: No, a group is not the same as a ciphersuite in TLS 1.3. The group is how the client and server agree on secret keys. The ciphersuite is how they use secret keys to encrypt and protect the traffic. They work together in a TLS 1.3 handshake, but they are two separate parts

Q11: Are there other groups I should know about?​

A: Yes. There are three common hybrid groups; you have already met X25519_MLKEM768, but there is also SecP256r1_MLKEM768 and SecP384r1_MLKEM1024.

Q12: What group should I use?​

A: Follow your organization’s cryptographic policy and required assurance profile. For browser interoperability, prefer X25519_MLKEM768 where supported and place it ahead of other groups. For regulated environments, use a hybrid group and implementation permitted by the applicable policy and validated cryptographic module; this may require SecP256r1_MLKEM768 or SecP384r1_MLKEM1024 instead of X25519_MLKEM768.

Q13: If there is TLD 1.3 with hybrid crypto, is there a version that is NOT hybrid?​

A: Yes, it’s called ‘pure’, and that is where rather than using ECC+PQC, you use just PQC; for example instead of X25519+MLKEM768, you use only MLKEM768 or MLKEM1024 if CNSA 2.0 compliance is in scope. Some customers may eventually require this. You can read about the MLKEM-only Windows schannel update here August 27, 2026—KB5120998 (OS Builds 26200.9278 and 26100.9278) Preview | Microsoft Support.

Q14: What’s CNSA 2.0?​

A: CNSA 2.0, the Commercial National Security Algorithm Suite 2.0, is the NSA's set of quantum-resistant cryptographic algorithm requirements for U.S. National Security Systems. It updates CNSA 1.0 by introducing post-quantum algorithms intended to protect classified and other national-security-sensitive information against both classical and future quantum attacks. It is important because transitioning cryptographic infrastructure takes years, while adversaries can collect encrypted data now and attempt to decrypt it later. Although its formal scope is National Security Systems, CNSA 2.0 also provides vendors and other organizations with a concrete high-assurance target for planning, product development, and post-quantum migration.

The list of algorithms that affect TLS includes:

• Key establishment: ML-KEM-1024 only (not 512, not 768)
• Digital signatures: ML-DSA-87 only (not 44, not 65)
• Hashing: SHA-384 or SHA-512 only
• Symmetric encryption: AES-256 only

Q15: How do I test if my server supports TLS 1.3?​

A: See Appendix A.

Q16: How do I test if my server supports TLS 1.3 and PQC?​

A: See Appendix B.

Q17: How do I use Wireshark to determine if my server supports TLS 1.3 and PQC?​

A: See Appendix C.

Q18: Do both the client and server need to support hybrid PQC TLS?​

A: Yes.

Q19: What happens if one side does not support hybrid PQC TLS?​

A: If one side does not support hybrid PQC TLS, the connection may still succeed using another mutually supported TLS 1.3 key establishment group, for example X25519, but it will not use hybrid PQC protection. The exact behavior depends on the client, server, and TLS configuration.

Q20: How do I know if my client, such as a browser, supports PQC TLS?​

A: Point your application or browser at a tool like this https://pqc.ninja/api/browsertest/ it will output something like:


You can see that the browser and server negotiated to use the X25519_MLKEM768 hybrid group and the browser supports this along with two classic (ie; non-PQC) curves, prime256v1 and secp384r1.

Q21: Are PQC (ML-DSA) certificates required for TLS 1.3?​

A: No, not for hybrid PQC key establishment. PQC certificates are a separate part of the post quantum migration and relate to authentication and digital signatures. Hybrid key establishment protects the session key agreement; PQC certificates will protect the certificate signature and authentication path.

Q22: Following the previous question, why does the server still use a classic certificate if the key negotiation is post-quantum?​

A: This is by design. We need to secure data in transit first and foremost, since that represents the most immediate quantum threat. An adversary can perform a harvest-now, decrypt-later attack by storing encrypted communications today and waiting until quantum computers are available to decrypt them - any data being transmitted currently needs quantum-safe key exchange to be secure in the future. Authentication, however, does not have that same window of exposure: to perform a successful spoof via certificate misuse, an attacker would need a cryptographically meaningful quantum computer at the time of the session - they do not get to use it later. As we don't have that ability currently, by securing key exchange first we mitigate the most imminent threat while the ecosystem around it (CAs, trust anchors, relying parties, etc.) works towards supporting PQC signatures.

Q23: Is there a performance impact from hybrid PQC TLS?​

A: We will provide more stats as they become available, but current details look good; X25519 vs X25519-MLKEM768 is about a 3%-6% latency delta and less than 1% CPU hit using Azure Linux, nginx + OpenSSL + SymCrypt and similar stats using https.sys on Windows Server 2025.

Q24: Should I enable this on internet-facing services first or internal services first?​

A: Start with controlled pilots, then prioritize services that protect long-lived or high-value confidential data. Internet-facing services may provide broader coverage, but internal services can be easier to test and control. The right rollout order should balance risk, compatibility, visibility, and operational readiness.

Q25: What logging or telemetry should I capture during testing?​

A: Capture the client and server IP addresses, the negotiated key-establishment group, the negotiated cipher suite, and the TLS protocol version for every test connection. Also record whether the handshake succeeded or failed and correlate each result with a timestamp or connection identifier. This makes it possible to confirm that TLS 1.3 and the expected hybrid PQC group were negotiated.

Below is a screen shot from a tool I have on GitHub that shows most of this passively in Windows using schannel and pktmon. The code is here x509cert/schannel-cap.