Post-quantum cryptography has moved from a research topic into an infrastructure planning decision. Microsoft’s September 14, 2026 Windows, TLS 1.3 and Post Quantum Crypto FAQ gives administrators a clear starting point: move network services to TLS 1.3, enable a hybrid key-establishment group, and prove what was actually negotiated.
The threat is harvest now, decrypt later. An attacker can record encrypted traffic today and attempt to break the RSA, ECC, or DH key-establishment protecting its AES session keys when a cryptographically relevant quantum computer becomes available. Hybrid TLS combines a classical algorithm with post-quantum ML-KEM so the connection remains protected if one side of that hedge is later weakened.
What Microsoft’s FAQ changes for administrators
| Question | Operational answer |
|---|---|
| Is TLS 1.3 required? | Yes. TLS 1.0, 1.1, and 1.2 do not and will not support post-quantum key establishment. |
| Does TLS 1.3 alone provide PQ protection? | No. Windows uses classic groups by default until an administrator enables a hybrid group. |
| What is the common browser-compatible group? | X25519_MLKEM768, which combines the X25519 elliptic-curve group with post-quantum ML-KEM. |
| Do both endpoints need support? | Yes. If one side cannot use hybrid TLS, the connection may fall back to another mutually supported TLS 1.3 group without PQ protection. |
| Are PQ certificates required for the pilot? | No. Hybrid key establishment protects session confidentiality; post-quantum certificates are a separate authentication and signature migration. |
Check the Windows baseline first
Microsoft lists the following update baselines for TLS hybrid key exchange using ML-KEM groups:
- Windows 11 24H2 and 25H2: KB5089573.
- Windows 11 26H1: KB5095091.
- Windows Server 2025: July 14, 2026 KB5099536 (OS Build 26100.33158).
Confirm the actual OS build and cumulative-update state on the endpoints in scope. A device that lacks the platform support will produce misleading compatibility failures, while an updated device still needs the hybrid group explicitly enabled.
Enable one control plane, not two
Microsoft’s FAQ says hybrid TLS is not enabled by default. You can use Group Policy or an elevated PowerShell prompt; choose the control plane that matches how the endpoint is managed and document the owner.
Enable-TlsEccCurve -Name "X25519_MLKEM768" -Position 0-Position 0 puts the hybrid group at the top of the preferred list. Microsoft warns that Group Policy overrides the PowerShell setting, so do not mix both methods and then treat a changed group order as a mystery. For regulated or high-assurance environments, select the hybrid group permitted by the organization’s cryptographic policy; Microsoft also documents SecP256r1_MLKEM768 and SecP384r1_MLKEM1024 as common alternatives.
A safe pilot sequence
1. Inventory the real TLS surface
- List internet-facing and internal services, reverse proxies, load balancers, VPNs, APIs, mail gateways, and management tools that terminate TLS.
- Record OS versions, TLS libraries, certificate dependencies, middleware, vendor support, and the data-retention period of each service.
- Classify services by sensitivity and by how difficult a failed handshake would be to recover.
Do not hard-code cryptographic choices into application code as a shortcut. Microsoft’s guidance emphasizes keeping protocol and group selection in the platform or service configuration so the organization can change algorithms without rebuilding every application.
2. Start with a controlled, representative slice
Select one Windows Server 2025 service and one Windows 11 client path that represent the production dependencies you care about. Keep a known-good classic TLS 1.3 fallback during the pilot, and define an owner for every client or appliance that cannot negotiate hybrid TLS.
3. Verify the negotiated result
A successful TLS 1.3 handshake is not enough. Verify that the expected hybrid group was actually selected:
openssl s_client -connect 192.168.1.1:443 -tls1_3 -briefFor a successful hybrid connection, the output should include Protocol version: TLSv1.3 and a line such as Negotiated TLS1.3 group: X25519MLKEM768. Current Edge and Chrome versions can also show the protocol and group in Developer Tools’ Security panel.
4. Capture evidence and compatibility
For each test connection, retain the client and server addresses, negotiated group, cipher suite, TLS version, timestamp or connection identifier, and whether the handshake succeeded. Test the application behavior behind the handshake, not just the command-line probe.
| Test | Pass condition | Evidence |
|---|---|---|
| Modern client to modern server | TLS 1.3 and the intended hybrid group are negotiated. | OpenSSL or browser output, server logs, group and cipher. |
| Legacy client to modern server | The connection either uses an approved classic TLS 1.3 fallback or fails in a controlled, documented way. | Handshake result, affected owner, remediation or exception. |
| Load balancer or proxy in path | The device that terminates TLS, not just the backend, negotiates the expected group. | Front-door telemetry and backend trace correlation. |
| Performance and capacity | Latency, CPU, connection rates, and error budgets remain within the service target. | Before/after baseline and rollback threshold. |
Set expectations about performance and certificates
Microsoft’s current FAQ reports roughly a 3–6% latency delta and less than 1% CPU impact for X25519 versus X25519-MLKEM768 in its Azure Linux and Windows Server 2025 test scenarios. Treat those figures as a useful planning signal, not a guarantee for your application, appliance, or network path.
Hybrid TLS does not require a post-quantum certificate. Microsoft explains that the immediate risk is confidentiality: recorded traffic can be decrypted later. The certificate and its signature authenticate the live endpoint, while the hybrid key exchange protects the session keys. Plan certificate and CA modernization as a separate workstream, especially if your organization is also updating AD CS.
What to do this quarter
- Assign an owner: make one security or platform lead accountable for the crypto-agility inventory and exception register.
- Prioritize durable secrets: start with regulated records, intellectual property, credentials, and data that must remain confidential for years.
- Upgrade and verify: bring pilot endpoints to the listed Windows baselines and validate cumulative updates before troubleshooting handshakes.
- Stage the rollout: use a lab, then internal services, then carefully selected internet-facing services with monitoring and a rollback plan.
- Keep the fallback visible: a successful classic TLS 1.3 fallback is a compatibility result, not proof of PQ protection.
Frequently asked questions
Does enabling TLS 1.3 automatically enable post-quantum protection? No. TLS 1.3 is the required foundation, but Windows uses classic key exchange until a supported hybrid group is enabled.
Which Windows versions support hybrid post-quantum TLS? Microsoft lists Windows 11 24H2 and 25H2 with KB5089573, Windows 11 26H1 with KB5095091, and Windows Server 2025 with KB5099536.
Do we need post-quantum certificates before piloting hybrid TLS? No. Hybrid key establishment and post-quantum certificates address different parts of the TLS threat model.
What is the first test to run? Use a representative client and server, verify the TLS 1.3 version and negotiated hybrid group, and keep the output with the service’s compatibility record.
Need a defensible crypto-agility plan?
Accred Consulting can inventory Microsoft TLS dependencies, design a staged Windows and server pilot, and document the evidence and exceptions your security team needs.
Plan a Security Architecture Review