A quiet Windows update has moved post-quantum cryptography into a place many organizations already depend on: the encrypted connection between two machines.
Microsoft announced on July 14 that hybrid post-quantum key establishment is generally available in Schannel, the security component that handles TLS for Windows. Microsoft’s protocol documentation lists support for Windows 11 version 24H2 and later and Windows Server 2025 and later.
This is a real platform milestone. It is also easy to overread.
No cryptographically relevant quantum computer is known to exist. Current public-key encryption has not suddenly been broken. The work is preparation for a future capability and for the risk that encrypted information collected today could be decrypted later.
Capability has reached the connection
TLS creates an encrypted session through a handshake between endpoints. The new Windows support lets that handshake combine a classical method with ML-KEM, the post-quantum key-establishment algorithm standardized by NIST. The combined design is meant to preserve the shared secret as long as at least one component remains secure.
But the capability does not switch itself on. Microsoft says the hybrid groups are disabled by default and must be configured and prioritized by an administrator. Both sides of the connection also have to support and negotiate the same group. If they do not, the session may use a classical method instead.
That changes the useful unit of evidence.
A product page can show support. A configuration record can show intent. Neither proves that a live connection negotiated hybrid protection. The proof sits in the handshake itself: which TLS version ran, which key-establishment group the endpoints selected, and whether the session fell back.
Microsoft’s own worked example follows that logic. It inspects a connection and confirms TLS 1.3 with the X25519MLKEM768 group. The example also exposes an important boundary. Key establishment used the hybrid method, while server authentication still used a classical certificate.
Confidentiality and authentication are separate migration jobs. Hybrid key establishment helps protect the session secret. Post-quantum signatures and certificates protect identity, software signing, and other claims about who or what can be trusted. Calling a connection “quantum-safe” without naming that boundary can hide unfinished work.
The specification is still moving too. The IETF document defining the three hybrid groups is an Internet-Draft dated May 26. It is intended for the standards track, but it is explicitly a work in progress rather than a finalized RFC.
Policy meets the installed base
The timing matters because federal planning has acquired deadlines. OMB Memorandum M-26-15, which implements Executive Order 14412, gives civilian agencies 120 days from June 24 to submit post-quantum migration plans. Those plans must include milestones for TLS 1.3 testing and deployment, automated cryptographic inventory, crypto-agile architecture, third-party coordination, staffing and funding, risk management, and named governance roles.
The memo places prioritized key-establishment migration in the 2028 to 2030 phase and signature migration in 2031. CISA’s January product guidance already lists web browsers and web servers among categories where post-quantum-capable products are widely available. The same guidance says that most listed products have not widely implemented post-quantum authentication and should not be treated as fully quantum resistant.
That is the practical shift. The migration has moved from “Does the vendor support it?” to “Can the operator prove which protection a real session used?”
Verification bottleneck
Verification is becoming the scarce institutional function.
- Platform support moved faster than many organizations’ ability to confirm that hybrid protection is enabled, negotiated, and preserved across real connections.
- Security teams, network operators, application owners, vendors, assessors, and procurement staff now have to verify endpoint support, TLS version, selected group, fallback behavior, middlebox compatibility, and the separate state of certificate authentication.
- Watch next: default settings, fleet-level handshake telemetry, standardized deployment receipts, fallback rates, interoperability failures, and measurable progress from classical certificates toward post-quantum authentication.
Opportunities
Where value may appear: the receipt layer around post-quantum deployment.
A builder could create a TLS 1.3 and PQC readiness assessment, negotiated-handshake receipt, fallback detector, vendor questionnaire, controlled test harness, or dependency map for software and appliances that terminate encrypted connections. A small consulting service could help an organization compare what its vendors claim, what its systems are configured to offer, and what live sessions actually negotiate.
The useful product would keep key establishment and authentication in separate columns. It would record classical fallbacks instead of treating configured support as completed migration.
This is builder idea fodder and public-interest orientation, not cybersecurity, legal, compliance, procurement, financial, or investment advice. Specific implementation decisions belong with qualified security professionals and official vendor guidance.
The code has reached the handshake. Legitimacy arrives when the protection can be seen, tested, and carried forward as evidence.
Public sources
- Microsoft, “ASP.NET, Kestrel and Schannel GA with TLS 1.3 Post-Quantum Cryptography,” July 14, 2026: source
- Microsoft Learn, “[MS-TLSP]: Appendix A: Product Behavior”: source
- IETF, Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3, Internet-Draft, May 26, 2026: source
- White House, Executive Order 14412, June 22, 2026: source
- OMB, Memorandum M-26-15, June 24, 2026: source
- CISA, “Product Categories for Technologies That Use Post-Quantum Cryptography Standards,” January 23, 2026: source