Windows and Post-Quantum Cryptography: What’s Available in 2026

• ML-KEM (FIPS 203) and ML-DSA (FIPS 204) are generally available through CNG on Windows 11 and Windows Server 2025, giving developers production access to post-quantum key encapsulation and digital signatures.
• AD CS can issue ML-DSA certificates in production as of May 2026, covering TLS, code signing, user/computer templates, and OCSP response signing, but only through CNG key storage providers, never legacy CSPs.
• Schannel’s TLS 1.3 hybrid key exchange reached general availability on Windows 11 (24H2 and 25H2) in a July 2026 update, supporting X25519 with ML-KEM-768, NIST P-256 with ML-KEM-768, and NIST P-384 with ML-KEM-1024.
• ML-KEM certificate issuance in AD CS and composite algorithm support (classical ECDSA combined with ML-DSA, classical ECDHE combined with ML-KEM) are still planned, not shipped, so treat those as roadmap items, not available controls.
• None of this replaces a migration plan. The prerequisite work, cryptographic inventory, legacy CSP remediation, and TLS 1.3 coverage, still sits with your organization before any Windows PQC feature does anything useful.

Published: June 2026. Updated: August 2026. Reviewed by Encryption Consulting’s PQC and PKI advisory team.

Most headlines say post-quantum cryptography (PQC) is still years away. For Microsoft customers, parts of it already shipped. Over the past two years, Microsoft has rolled PQC support into Windows, Windows Server, and Azure in stages, moving from cryptographic primitives to developer APIs to production PKI and TLS features. Several of those stages are now generally available.

This post covers exactly what Windows platform-level PQC support looks like today: the Cryptography API: Next Generation (CNG) algorithm support, the Schannel TLS hybrid key exchange, AD CS certificate issuance, what still isn’t there yet, and how a Windows-heavy enterprise should sequence its own migration around it. If you’re looking for a general PQC primer, start with Introduction to Post-Quantum Cryptography; if you need the step-by-step AD CS build, see How to Build an ML-DSA CA Hierarchy in Microsoft AD CS. This post stays one level up: what Microsoft’s platform actually gives you, and what it still leaves on your plate.

What Post-Quantum Cryptography Capabilities Does Windows Support in 2026?

Windows supports post-quantum key encapsulation and digital signatures through CNG, post-quantum certificate issuance through AD CS, and post-quantum hybrid key exchange in the Schannel TLS stack. All three are now generally available on Windows 11 and Windows Server 2025. Composite algorithm support and ML-KEM certificate issuance in AD CS remain in preview or planned status.

All of it runs through SymCrypt, the core cryptographic library underneath Windows, Azure, and Microsoft 365. SymCrypt performs the actual encryption, decryption, signing, and key exchange operations across the Microsoft estate and has been through multiple FIPS 140 validations as part of the Windows Cryptographic Primitives Libraries. The rollout moved in clear, sequential stages:

• September 2024: SymCrypt added support for ML-KEM (FIPS 203, formerly Kyber) and XMSS, the first PQC algorithms to land in the library.
• December 2024: Microsoft added ML-DSA (FIPS 204, formerly Dilithium) and LMS to SymCrypt, rounding out the core signature algorithms alongside the key-encapsulation work already in place.
• May 2025: PQC capabilities reached Windows Insiders (Canary Channel) and SymCrypt-OpenSSL 1.9.0 on Linux, letting customers experiment with ML-KEM and ML-DSA through CNG on Windows and the SymCrypt provider for OpenSSL (SCOSSL) on Linux.
• November 2025: ML-KEM and ML-DSA reached general availability on Windows Server 2025 and Windows 11 through CNG, giving developers production access to key encapsulation and digital signature operations.
• May 2026: AD CS on Windows Server 2025 reached general availability for issuing ML-DSA certificates, bringing PQC into enterprise PKI directly instead of only low-level crypto APIs.
• July 2026: Schannel’s TLS 1.3 hybrid key exchange reached general availability on Windows 11 (24H2 and 25H2), moving out of Windows Insider preview.

That is not a single feature drop. It is the next step in a deliberate, multi-year sequence that started with cryptographic primitives, moved through developer-facing APIs, and has now reached the PKI and TLS layers most enterprises depend on every day. Two areas sit fully in production use today: certificate issuance through AD CS, and direct algorithm access for developers through CNG.

ML-DSA Certificate Issuance Through AD CS

As of May 2026, AD CS on Windows Server 2025 can stand up an ML-DSA certificate authority hierarchy and issue ML-DSA certificates for code signing, TLS, web server, user and computer templates, and OCSP response signing. AD CS supports all three NIST-defined parameter sets, ML-DSA-44, ML-DSA-65, and ML-DSA-87, letting administrators trade signature and key size against security strength depending on the use case.

There is one operational constraint that shapes the entire migration project: AD CS does not support legacy Cryptographic Service Providers (CSPs) for any PQC algorithm. Any certificate template or Hardware Security Module (HSM) integration still tied to a legacy CSP has to move to a CNG key storage provider first, before PQC enters the picture at all. Microsoft’s own guidance also notes that AD CS-adjacent enrollment services, CEP, CES, NDES, and the Online Responder, are not yet part of this PQC support and are expected to follow as additional algorithms ship.

ML-KEM and ML-DSA Through CNG

Since the November 2025 update, developers have had production access to ML-KEM for key encapsulation and key exchange scenarios, and to ML-DSA for digital signature, identity verification, and integrity-check scenarios, through the same CNG libraries Windows developers already use for classical algorithms. On the .NET side, this surfaces as native MLKem and MLDsa classes in System.Security.Cryptography, so application teams are not stuck writing raw CNG calls to get post-quantum support into a .NET service.

Note that Microsoft’s own AD CS documentation lists ML-DSA as the only PQC algorithm available in AD CS today. ML-KEM support inside AD CS, along with composite ML-DSA and composite ML-KEM, is documented as a later phase rather than something already shipped.

What Changed With TLS Hybrid Key Exchange and Composite Algorithms?

Schannel’s TLS 1.3 hybrid key exchange moved from Windows Insider preview to general availability in July 2026. Composite algorithm support, which combines a classical algorithm and a post-quantum algorithm into a single certificate or key-exchange operation, is still planned and has not shipped.

TLS Hybrid Key Exchange

Windows’ TLS stack, Schannel, now supports hybrid key exchange that pairs a classical algorithm with ML-KEM, generally available on Windows 11 (24H2 and 25H2) through a July 2026 update, with Windows Server 2025 support following. The supported combinations are X25519 with ML-KEM-768, NIST P-256 with ML-KEM-768, and NIST P-384 with ML-KEM-1024 for organizations that need to meet NSA CNSA 2.0 requirements. IT administrators configure these the same way they already configure existing TLS curves: through Group Policy for domain-joined environments, Mobile Device Management (MDM) platforms like Intune, or TLS PowerShell cmdlets for scripted setups. The feature ships disabled by default and only applies to TLS 1.3 connections; TLS 1.2 traffic gets no benefit from it regardless of whether the update is installed.

The reasoning behind hybrid, rather than jumping straight to ML-KEM alone, is the same reasoning every major standards body has converged on: pairing a classical algorithm with a post-quantum one means an attacker has to break both halves of the connection, not just the newer, less battle-tested half. This directly targets harvest now, decrypt later (HNDL) risk, where an adversary captures encrypted traffic today with the intent of decrypting it once a sufficiently powerful quantum computer exists. This matters most for data that has to stay confidential for years: health records, government archives, long-lived legal and financial documents.

Composite Algorithm Support

Microsoft has flagged broader composite algorithm support, combining classical ECDSA with ML-DSA, and classical ECDHE key exchange with ML-KEM, as planned. This follows the IETF’s draft work on composite ML-DSA and composite ML-KEM for TLS 1.3. Composite approaches matter because they let a single cryptographic operation incorporate both a classical and a post-quantum component natively, instead of leaving every application developer to implement that combination logic themselves. When this ships, it extends PQC support beyond signing scenarios into broader certificate interoperability.

What Standards and Deadlines Does This Windows Support Map To?

Windows’ PQC support maps to three finalized NIST standards, ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), and to the deprecation timeline NIST set for classical public-key algorithms. Windows currently implements ML-KEM and ML-DSA; it does not yet expose SLH-DSA.

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST Internal Report 8547 lays out the deprecation schedule for the classical algorithms these replace: RSA and elliptic-curve algorithms are slated to be deprecated starting around 2030 and disallowed by 2035 for systems that need to stay compliant with federal guidance. For organizations covered by CNSA 2.0, the National Security Agency’s own transition guidance, the internal deadlines run tighter, which is part of why the P-384 with ML-KEM-1024 hybrid group exists as a Windows configuration option in the first place.

Those dates matter for sequencing, not just compliance paperwork. A Windows-heavy enterprise that waits until 2029 to start touching AD CS or Schannel configuration is not leaving itself room for the pilot, interoperability testing, and phased rollout that a PKI change of this size actually needs.

What Cryptographic Inventory Work Has to Happen Before You Touch Windows PQC Settings?

You need a current inventory of where public-key cryptography is used across your Windows and Azure estate before enabling any PQC feature, because you cannot phase a migration you cannot see. Microsoft’s own guidance, echoed across each of its PQC announcements, is consistent on this point: start with cryptographic inventory, then prioritize by exposure.

For a Windows-centric environment, that inventory needs to answer four questions:

• Which certificate templates and CAs are still tied to legacy CSPs? These cannot receive PQC support until they move to CNG key storage providers, full stop.
• Which endpoints and services still negotiate TLS 1.2 only? Hybrid key exchange only applies to TLS 1.3, so a TLS 1.2 dependency is a blocking issue, not a nice-to-have fix.
• Where does data need to stay confidential for years, not months? Document repositories like SharePoint, email archives, database backups, and long-term archival storage carry the highest HNDL exposure and should be prioritized first.
• Which relying parties, clients, load balancers, and network appliances actually terminate or inspect TLS traffic? Every one of them is a potential interoperability failure point once hybrid groups or ML-DSA certificates enter the chain.

Running this inventory by hand across a large Windows estate is exactly the kind of work that turns into a spreadsheet nobody trusts. A dedicated crypto discovery and inventory platform, like CBOM Secure, automates the discovery and keeps the inventory current as certificates, keys, and TLS configurations change, instead of going stale the week after the audit ends.

What Algorithm and Interoperability Caveats Should You Plan Around?

The biggest caveats are legacy CSP incompatibility, a hard TLS 1.3 requirement, and client-side support gaps, not the PQC algorithms themselves. Each one can quietly block a rollout if it isn’t caught during inventory.

• No legacy CSP support. AD CS will not issue PQC certificates through a legacy Cryptographic Service Provider under any configuration. If an HSM integration or certificate template is still tied to a legacy CSP, that migration to CNG has to happen first, on its own timeline, before PQC work can start.
• TLS 1.3 is not optional. Hybrid key exchange only negotiates over TLS 1.3. If parts of your estate are still pinned to TLS 1.2, for compatibility with older clients, load balancers, or middleboxes, that upgrade needs to happen before hybrid key exchange becomes relevant at all.
• Not every client can negotiate a hybrid group yet. Older Windows builds, non-Windows clients, and some third-party TLS stacks and network appliances will not recognize the new hybrid groups. Test relying-party compatibility explicitly rather than assuming a hybrid-enabled server degrades gracefully for every client.
• Larger handshakes and certificates. ML-KEM and ML-DSA public keys and signatures are meaningfully larger than their classical equivalents. That changes TLS handshake size and certificate size in ways that can matter for constrained links, older network appliances with fixed buffer assumptions, and any system doing deep packet inspection on TLS metadata.
• ML-KEM certificates and composite algorithms are not available yet. Do not build a rollout plan that assumes ML-KEM certificate issuance or composite ECDSA/ML-DSA and ECDHE/ML-KEM support exists in AD CS today. Both remain on Microsoft’s roadmap.

What Are the Phased Migration Steps for a Windows-Heavy Enterprise?

Microsoft’s own guidance, echoed across each of its PQC announcements, is consistent: the most effective migrations are phased, not single-event cutovers. In practice, that phasing breaks down into seven steps for a Windows and Azure estate:

1. Inventory public-key cryptography usage across Windows, Windows Server, and Azure, including certificates, CSPs versus CNG key storage providers, TLS configurations, and code-signing keys.
2. Prioritize by confidentiality lifetime and HNDL exposure. Document repositories, email archives, backups, and long-retention databases move first; short-lived, low-sensitivity traffic can wait.
3. Remediate legacy CSP dependencies. Move any certificate template or HSM integration still on a legacy CSP to a CNG key storage provider, since this is a hard prerequisite, not a parallel task.
4. Close out any remaining TLS 1.2-only endpoints. Confirm every system that needs hybrid key exchange actually negotiates TLS 1.3 first.
5. Pilot hybrid TLS and ML-DSA certificates in a non-production environment. Validate handshake negotiation, certificate chain building, and CA hierarchy behavior before anything touches customer-facing traffic.
6. Test relying-party and client compatibility against the actual mix of clients, load balancers, and network appliances in your environment, not just Microsoft’s reference configuration.
7. Roll out in phases with monitoring and a rollback plan, starting with the highest-priority systems identified in step 2, expanding scope only after each phase’s evidence checks out.

This is consistent with the broader hybrid-first approach that NIST, NSA, and effectively every standards body now recommends: treat hybrid as the default working state for the transition period, not as an optional extra layered on top of “real” PQC adoption.

What Testing Evidence Should You Collect Before Production Rollout?

You need documented evidence that hybrid handshakes negotiate correctly, that certificate chains validate end to end, and that every relying party in scope actually connects, before any PQC configuration change reaches production. Treat this the same way you would treat evidence for any other PKI change, because auditors and incident responders will ask for it later.

• Handshake logs confirming which hybrid group (X25519+ML-KEM-768, P-256+ML-KEM-768, or P-384+ML-KEM-1024) was actually negotiated on each tested connection, not just that the feature is enabled.
• Certificate chain validation results for ML-DSA certificates across every client and OS version in your relying-party matrix, including any that fail and why.
• An interoperability matrix mapping client type, OS version, and TLS stack against pass/fail for hybrid negotiation, so gaps are visible before rollout rather than discovered as production incidents.
• Performance benchmarks covering handshake latency and payload size with hybrid key exchange enabled versus classical-only, particularly for high-volume or latency-sensitive services.
• A documented rollback procedure with the specific Group Policy, MDM, or PowerShell settings to revert, tested at least once before it’s needed for real.

Windows PQC Feature Availability at a Glance

Feature	Status	Windows Versions	What It Covers
ML-KEM + ML-DSA via CNG	Generally available (Nov 2025)	Windows 11, Windows Server 2025	Developer access to post-quantum key encapsulation and digital signatures
ML-DSA certificate issuance via AD CS	Generally available (May 2026)	Windows Server 2025	CA hierarchy setup and certificate issuance for TLS, code signing, and OCSP
Schannel TLS 1.3 hybrid key exchange	Generally available (Jul 2026)	Windows 11 24H2, 25H2	X25519+ML-KEM-768, P-256+ML-KEM-768, P-384+ML-KEM-1024
SCOSSL PQC support (Azure Linux)	Generally available (mid-2025)	Azure Linux, non-Windows Azure workloads	ML-KEM and ML-DSA for the non-Windows side of a Microsoft estate
ML-KEM certificate issuance via AD CS	Planned	Windows Server 2025 (future update)	Key-encapsulation-based certificates
Composite ML-DSA / composite ML-KEM	Planned	Not yet announced	Classical and post-quantum combined in one certificate or handshake
PQC support in CEP, CES, NDES, Online Responder	Planned	Not yet announced	Extends AD CS PQC support to auxiliary enrollment and OCSP services

Windows PQC Implementation Checklist

• Cryptographic inventory covers every CA, certificate template, and TLS endpoint in the Windows and Azure estate
• Every certificate template and HSM integration confirmed on CNG, not a legacy CSP
• Every system targeted for hybrid key exchange confirmed on TLS 1.3
• Non-production pilot completed for both hybrid TLS and ML-DSA certificate issuance
• Interoperability matrix built and tested against real client, load balancer, and appliance mix
• Handshake and certificate chain validation evidence documented and retained
• Rollback procedure documented and tested at least once
• Rollout phased by confidentiality lifetime and HNDL exposure, not by convenience
• Roadmap items (ML-KEM certificates, composite algorithms) excluded from current-phase planning and tracked separately

What Are the Limitations of Windows’ Current PQC Support?

Windows’ PQC support is real and production-usable in specific areas, but it is not a complete post-quantum platform yet, and treating it as one will create gaps. Be direct about what’s still missing:

• ML-KEM certificate issuance inside AD CS has not shipped; only ML-DSA certificates are available today.
• Composite algorithm support, combining classical and post-quantum cryptography in a single certificate or operation, remains a roadmap item with no committed date.
• Auxiliary enrollment and validation services, CEP, CES, NDES, and the Online Responder, are not yet part of Microsoft’s AD CS PQC support.
• Hybrid key exchange requires TLS 1.3 and ships disabled by default, so it does nothing until an administrator explicitly configures it.
• Not every relying party, older OS versions, some non-Windows clients, and some network appliances, can negotiate the new hybrid groups yet, which means a hybrid-enabled server can still fail connections from parts of your own environment.
• SLH-DSA (FIPS 205) is not currently exposed through Windows CNG, even though it is a finalized NIST standard.

None of this is a reason to wait. It’s a reason to scope the rollout to what’s actually shipped, pilot it properly, and keep the roadmap items on a separate tracked list instead of assuming they’ll land on your migration’s timeline.

What Would Encryption Consulting Recommend?

Start with visibility, not configuration. Before anyone touches Schannel Group Policy or an AD CS template, we recommend running a full cryptographic inventory across the Windows and Azure estate with CBOM Secure, so the CSP-to-CNG gaps, TLS 1.2 holdouts, and long-confidentiality-lifetime systems are documented facts instead of guesses.

From there, sequence the migration against Encryption Consulting’s PQC Advisory nine-phase roadmap rather than an ad hoc pilot. It maps directly onto the phases above, inventory, risk prioritization, hybrid piloting, interoperability testing, and staged rollout, with milestones you can report against instead of an open-ended “we’re working on PQC.”

For the AD CS side specifically, our CertSecure Manager team helps design the CA hierarchy, certificate template governance, and automated lifecycle management that a Windows ML-DSA rollout needs to run cleanly at scale, and our HSM-as-a-Service offering gives you a FIPS 140-3-validated key store for the CNG migration if legacy CSP-tied HSM integrations are part of your gap list.

Frequently Asked Questions

Does Windows support post-quantum cryptography today? Yes. ML-KEM and ML-DSA are generally available through CNG on Windows 11 and Windows Server 2025, AD CS can issue ML-DSA certificates in production, and Schannel supports TLS 1.3 hybrid key exchange as of a July 2026 update. Composite algorithms and ML-KEM certificate issuance in AD CS are still planned, not available.

What’s the difference between ML-KEM and ML-DSA in Windows? ML-KEM (FIPS 203) handles key encapsulation and key exchange, the post-quantum replacement for algorithms like ECDH. ML-DSA (FIPS 204) handles digital signatures, the post-quantum replacement for algorithms like ECDSA and RSA signing. Windows exposes both through CNG, but only ML-DSA is currently available for AD CS certificate issuance.

Do I need to upgrade to TLS 1.3 before I can use Windows PQC features? For hybrid key exchange, yes. Schannel’s hybrid groups only negotiate over TLS 1.3; a TLS 1.2 connection gets no post-quantum protection regardless of whether the feature is enabled. AD CS certificate issuance itself does not require TLS 1.3, but most of the systems that will actually use those certificates for TLS connections will.

Can I issue ML-KEM certificates from AD CS yet? No. As of mid-2026, AD CS only issues ML-DSA certificates. ML-KEM certificate issuance, along with composite ML-DSA and composite ML-KEM, is documented by Microsoft as a planned future phase.

Is hybrid key exchange safe to enable in production right now? It’s safe from a cryptographic standpoint, since hybrid means an attacker has to break both the classical and post-quantum components. The real risk is operational: legacy CSP dependencies, TLS 1.2 holdouts, and clients that can’t yet negotiate the new hybrid groups. Pilot it in non-production first, build an interoperability matrix, and roll out in phases rather than flipping it on across the whole estate at once.

Conclusion

Microsoft’s post-quantum rollout is one of the clearest signals that PQC migration has moved out of the planning stage and into production infrastructure enterprises already depend on every day. ML-DSA certificate issuance is generally available. ML-KEM and ML-DSA are generally available through CNG. TLS hybrid key exchange reached general availability in July 2026. Composite algorithm support and ML-KEM certificate issuance remain on the roadmap.

None of this removes the need for your own migration plan. It does mean that, if you run on Windows or Azure, a meaningful piece of the underlying infrastructure is no longer something you have to build yourself. The work left is inventory, sequencing, and testing, which is exactly where a structured PQC readiness review earns its place.

References

• Microsoft Learn, Post-Quantum Cryptography in AD CS overview
• Microsoft Security Blog, New Windows Features to Secure Today’s Data in a Post-Quantum World
• Microsoft Community Hub, Post-Quantum Cryptography APIs Now Generally Available on Microsoft Platforms
• NIST, FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST, FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST, FIPS 205: Stateless Hash-Based Digital Signature Standard
• NIST, NIST IR 8547: Transition to Post-Quantum Cryptography Standards