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

Most headlines say post-quantum cryptography (PQC) is coming. But for Microsoft users, it’s already here. Over the past two years, Microsoft has gradually introduced PQC support across Windows, Windows Server, and Azure, with several features now generally available as of mid-2026.

This blog walks through what Microsoft actually announced in its latest Windows post-quantum update, how that fits into the rollout that started back in 2024, and what it means for the way your organization plans its own PQC migration.

How Microsoft Got Here

Microsoft’s PQC work runs through SymCrypt, the core cryptographic library underneath Windows, Azure, and Microsoft 365. SymCrypt is what actually performs encryption, decryption, signing, and key exchange across the Microsoft estate, and it has been through multiple FIPS 140 validations as part of the Windows Cryptographic Primitives Libraries.

The rollout has moved in clear, sequential stages:

• September 2024: SymCrypt added support for ML-KEM (FIPS 203, formerly known as 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 start experimenting with ML-KEM and ML-DSA in their own environments through Cryptography API: Next Generation (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 and certificate functions, giving developers production access to key encapsulation and digital signature operations.
• May 2026: Active Directory Certificate Services (AD CS) on Windows Server 2025 reached general availability for issuing ML-DSA certificates, bringing PQC into enterprise public key infrastructure (PKI) directly, not just into low-level crypto APIs.

That is the context behind the latest announcement. It is not a single feature drop. It is the next step in a deliberate, multi-year sequence that started with the cryptographic primitives, moved through developer-facing APIs, and has now reached the PKI and TLS layers that most enterprises actually depend on day to day.

With that sequence in mind, here is exactly what has crossed the line into general availability today.

What’s Generally Available Right Now

Two areas have crossed fully into production use: certificate issuance through AD CS, and direct algorithm access for developers through Cryptography Next Generation API (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 important operational constraint here, and it shapes the entire migration project: Microsoft’s own AD CS documentation walks through configuring a CA’s algorithm at the point you create it, using Install-AdcsCertificationAuthority with an ML-DSA cryptographic provider specified up front, for both the root and subordinate CA.

AD CS does not support legacy Cryptographic Service Providers (CSPs) for any PQC algorithm, so any certificate template or Hardware Security Module (HSM) integration still tied to a legacy CSP needs to move to CNG first, before PQC enters the picture at all.

ML-KEM and ML-DSA Through CNG

Since the November 2025 update, developers have had production access to ML-KEM for scenarios that need key encapsulation or key exchange, and to ML-DSA for digital signature, identity verification, and integrity-check scenarios, all through the same Cryptography API: Next Generation libraries Windows developers already use for classical algorithms.

Note: Microsoft’s 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 planned for a later phase rather than shipped yet.

That last point is worth sitting with, because it leads directly into what is not yet finished.

What’s Still in Preview

Two more pieces are still working their way toward general availability: hybrid key exchange in the TLS stack, and composite algorithm support for combining classical and post-quantum cryptography in a single operation.

TLS Hybrid Key Exchange

Windows’ TLS stack, Schannel, now supports hybrid key exchange that pairs a classical algorithm with ML-KEM. This is live now through the Windows Insider Program, with general availability for Windows 11 and Windows Server 2025 expected in a future Windows release. 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 a higher security level. IT administrators can 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 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 to compromise it, 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, which matters most for data that has to stay confidential for years.

Composite Algorithm Support

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

Everything covered so far has been Windows-centric, but Microsoft’s PQC work extends well past Windows itself.

The Linux and Azure Side

Microsoft’s PQC work has never been Windows-only. SymCrypt also runs as a backend provider for OpenSSL on Linux through SCOSSL (the SymCrypt provider for OpenSSL), which Microsoft uses to bring FIPS 140-3-compliant cryptography to Azure Linux and Azure’s government cloud services. SCOSSL 1.9.0 brought the same ML-KEM and ML-DSA support to Linux that Windows Insiders received around the same time in mid-2025, and Microsoft’s own Go runtime build has been updated to take advantage of SCOSSL’s FIPS 140-3-compliant PQC implementation when running on Azure Linux.

This matters for a simple reason: most enterprise Microsoft estates are not pure Windows. If your Azure workloads run on Linux, or your build pipeline depends on Microsoft’s Go toolchain, the same underlying SymCrypt PQC work applies there too, which means your migration planning needs to account for both sides of the estate rather than treating Windows and Azure Linux as separate problems.

Knowing what is available is only useful if you also know how Microsoft expects you to roll it out.

What Microsoft Is Asking Customers to Do Now

Microsoft’s own guidance, echoed across each of these announcements, is consistent: the most effective migrations are phased, not single-event cutovers. The recommended starting point is the same one every other PQC migration framework converges on. Inventory where public-key cryptography is actually used across your environment, starting with the systems most exposed to long-term confidentiality risk: document repositories like SharePoint, email archives, database systems, and backup or archival storage, including both on-device and cloud backups.

From there, Microsoft’s guidance is to prioritize systems that protect sensitive data with long confidentiality lifetimes, and to test hybrid and composite configurations in non-production environments before rolling them into anything customer-facing. 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.

One practical detail worth calling out: Microsoft’s hybrid post-quantum TLS implementation is built on TLS 1.3. If parts of your estate are still running on older TLS versions, that upgrade needs to happen before any of this PQC work becomes relevant, which is a useful forcing function if your organization has been putting off a TLS 1.3 migration.

Stepping back from Microsoft specifically, this rollout is also a useful preview of what is coming industry-wide.

Why This Matters Beyond Windows Specifically

Windows and Azure sit underneath an enormous share of enterprise infrastructure, identity systems, and PKI deployments. When Microsoft moves ML-DSA certificate issuance from preview to general availability inside AD CS, that is not a niche developer feature. It is the foundation that most enterprise certificate authorities, code-signing pipelines, and internal TLS deployments are built on top of, reaching production readiness for post-quantum algorithms.

That also means the constraints Microsoft has built into this rollout- no in-place CA upgrades, CNG-only support, hybrid as the default TLS posture- are a reasonable preview of the constraints most organizations will run into regardless of which vendor’s PKI they use. The pattern is the same one showing up across the industry: parallel infrastructure during transition, hybrid cryptography as the safer default, and a staged rollout that starts with cryptographic primitives and ends with full PKI and TLS support.

That broader pattern is exactly where outside help tends to matter most, regardless of which platform your estate runs on.

How Encryption Consulting Can Help

Encryption Consulting specializes in PKI strategy, ADCS architecture, and certificate lifecycle management for enterprise and government organizations. Whether you are deploying ADCS for the first time, modernizing a legacy PKI, assessing your certificate infrastructure for ESC vulnerabilities, or integrating ADCS with modern DevOps tooling, our team brings deep protocol-level expertise to every engagement.

• PKI Health Assessments: Protocol-level audits of your ADCS environment against Microsoft Open Specifications and security hardening benchmarks
• ADCS Architecture Design: Enrollment stack design (MS-WCCE, MS-XCEP/MS-WSTEP, NDES/SCEP), CA hierarchy planning, and certificate template governance
• Certificate Lifecycle Management: Automated discovery, monitoring, and renewal of certificates across your enterprise
• Security Hardening: Remediation of ESC misconfigurations, CA role hardening, and CRL/OCSP infrastructure optimization

Conclusion

Microsoft’s post-quantum rollout is one of the clearest signals available right now that PQC migration has moved out of the planning stage and into production infrastructure that 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 is in preview with general availability expected soon, and composite algorithm support is on the way later this year.

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 you will need 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.