Quick answer: Microsoft’s Windows post-quantum rollout has landed in four distinct stages over less than a year, and treating it as a single “Windows supports PQC now” event misses the sequencing that actually matters for planning. November 2025 brought ML-KEM and ML-DSA into CNG and SymCrypt as raw cryptographic primitives. May 2026 brought ML-DSA certificate issuance to Active Directory Certificate Services on Windows Server 2025. July 14, 2026 brought hybrid ML-KEM key exchange directly into the Schannel TLS stack, alongside composite PQC algorithm support in Windows cryptography APIs and certificate functions. Each stage unlocks a different layer, primitives, then certificates, then live TLS negotiation, and the most consequential single constraint across all of it is that AD CS cannot upgrade an existing certification authority in place; PQC support requires standing up a new CA hierarchy in parallel.
Our ML-DSA support for your Microsoft PKI guide covers the AD CS piece of this rollout in depth. This guide takes the wider view: the complete Windows platform sequencing across CNG, SymCrypt, TLS, and certificate services, and what that sequencing means for rollout planning.
Key Takeaways
- ML-KEM and ML-DSA reached general availability as CNG and SymCrypt primitives in the November 2025 Windows update, for both Windows 11 and Windows Server 2025.
- AD CS ML-DSA certificate issuance reached general availability with the May 2026 security update (KB5087539) on Windows Server 2025.
- Hybrid ML-KEM TLS 1.3 key exchange in the Schannel stack, plus composite PQC algorithm support in Windows cryptography APIs and certificate functions, reached general availability with the July 14, 2026 security updates.
- AD CS cannot upgrade an existing certification authority to PQC in place; deploying ML-DSA support requires standing up a new, parallel CA hierarchy and migrating to it deliberately.
- Post-quantum TLS groups are disabled by default, work only with TLS 1.3, and require both endpoints to support a compatible negotiated group.
The Rollout in Four Stages
| Date | Milestone | What it unlocks |
|---|---|---|
| November 2025 | ML-KEM and ML-DSA general availability in CNG and SymCrypt | Raw cryptographic primitives available to developers via Windows cryptography APIs; .NET 10 also incorporates the algorithms |
| May 2026 | AD CS ML-DSA support (KB5087539) | Certificate authorities can issue ML-DSA certificates for code signing, TLS, Web Server, User and Computer templates, and OCSP response signing |
| July 14, 2026 | Hybrid ML-KEM TLS 1.3 key exchange in Schannel; composite PQC algorithms in CNG and certificate functions | Schannel negotiates ML-KEM hybrid key exchange directly during real TLS handshakes without application developers wiring it in; composite algorithms extend hybrid cryptographic object support to signing and key-encapsulation scenarios beyond TLS |
The sequencing is deliberate, not incidental: primitives first, so developers and platform teams could start experimenting; certificate issuance second, extending PQC into the identity and trust layer; live protocol negotiation last, since that is the piece with the widest blast radius if something breaks in production traffic.
CNG and SymCrypt: Where the Algorithms Actually Live
SymCrypt is Microsoft’s core cryptographic library underneath Windows, and Cryptography API: Next Generation (CNG) is the interface applications and platform components use to reach it. Post-quantum algorithms are only exposed through CNG providers, not the older legacy CryptoAPI, which is a hard compatibility boundary: any application, certificate template, or platform feature still relying on legacy CSPs cannot use ML-KEM or ML-DSA regardless of OS version, and needs to move to a CNG Key Storage Provider first. This is a common, easy-to-miss blocker in AD CS certificate template configuration specifically, since templates need explicit reconfiguration to a non-legacy provider before ML-DSA becomes selectable at all.
Hybrid TLS and Composite Algorithms
The July 2026 Schannel update added configurable ML-KEM hybrid groups to Windows TLS, including combinations like SecP384r1_MLKEM1024, pairing a classical NIST curve with a higher-security ML-KEM parameter set. These groups are disabled by default, work only with TLS 1.3, and require both sides of a connection to support a mutually compatible group, the same negotiation logic covered in our X25519MLKEM768 deployment guide. Enabling the capability at the OS level does not mean every application automatically uses it: software that ships its own TLS stack rather than relying on Schannel makes its own, independent choice about supported groups, so a Windows-level configuration change does not universally propagate.
Composite PQC algorithm support, added to Windows cryptography APIs and certificate functions in the same July update, extends hybrid cryptographic object support beyond TLS into signing and key-encapsulation scenarios more broadly, letting organizations begin prototyping composite certificate profiles and evaluating trust chain impacts ahead of broader ecosystem adoption of composite formats.
AD CS: The Parallel Hierarchy Constraint
This is the single most important operational fact for anyone planning an AD CS rollout: there is no in-place upgrade path. An existing certification authority cannot be flipped to ML-DSA through a configuration change or update; PQC support requires deploying a newly created certification authority, standing it up in parallel to production, validating it, and migrating deliberately, rather than modifying the current root or issuing CA directly. That constraint shapes the entire project timeline, since a parallel-hierarchy deployment and validated cutover takes materially longer than a configuration change would, and it needs to be budgeted as such from the start rather than discovered mid-project.
What We’d Actually Recommend
Confirm which specific Windows and Windows Server builds and KB updates are actually deployed across your fleet before assuming platform-wide PQC readiness; the four stages above landed on different dates and different minimum builds, and a partially patched fleet will show inconsistent capability. Plan the AD CS parallel-hierarchy deployment as its own project with its own timeline, not a rollout appended to existing CA maintenance, given the no-in-place-upgrade constraint. Audit which applications rely on Schannel versus a bundled TLS stack before assuming an OS-level hybrid TLS configuration change reaches every workload, and reconfigure legacy CSP-based certificate templates to CNG Key Storage Providers as a prerequisite step, not an afterthought.
How Encryption Consulting Can Help
Knowing which builds, KB updates, and CNG versus legacy CSP configurations are actually deployed across your Windows fleet is exactly the inventory gap CBOM Secure is built to close, mapping platform patch level and cryptographic provider configuration alongside your broader certificate and key inventory.
Our PQC Advisory Services sequence the CNG, TLS, and AD CS rollout stages covered in this guide against your actual fleet patch level and application dependencies, building the parallel CA hierarchy migration into a realistic project timeline rather than an assumed configuration change. Where certificate issuance itself is the focus, CertSecure Manager manages the transition across the parallel hierarchy and production CA, including hybrid and composite formats as they mature.
Four Stages, Not One Event
Microsoft has moved quickly, primitives to certificates to live TLS negotiation in under a year, but the platform’s PQC readiness is not a single switch that flips once. Each stage carries its own minimum build requirements, its own compatibility boundaries, and, for AD CS specifically, a parallel-deployment constraint that has real project-timeline consequences. Treating the rollout as four distinct, sequenced capabilities to plan against, rather than one Windows PQC milestone to check off, is what actually produces a realistic migration timeline.
Frequently Asked Questions
Can an existing AD CS certification authority be upgraded to support ML-DSA?
No. There is no in-place upgrade path. PQC support requires deploying a new certification authority in parallel to production, validating it, and migrating to it deliberately, rather than modifying an existing root or issuing CA.
Does enabling hybrid TLS at the Windows OS level automatically apply to every application?
No. Applications relying on the Windows Schannel TLS provider inherit the capability, but software that ships its own independent TLS stack makes its own choice about supported groups and is not affected by the OS-level configuration.
Why can’t legacy Cryptographic Service Providers use ML-KEM or ML-DSA?
Post-quantum algorithms are exposed only through CNG (Cryptography API: Next Generation) providers, not the older legacy CryptoAPI. Any certificate template or application still configured for a legacy CSP needs to move to a CNG Key Storage Provider before post-quantum algorithms become available.
Is hybrid ML-KEM TLS key exchange enabled by default in Windows?
No. The post-quantum TLS groups are disabled by default, work only with TLS 1.3, and require both sides of a connection to support a mutually compatible group before negotiation succeeds.
What are composite PQC algorithms in Windows used for?
They extend hybrid cryptographic object support, pairing a classical and a post-quantum algorithm, beyond TLS into signing and key-encapsulation scenarios, letting organizations prototype composite certificate profiles and evaluate trust chain impacts ahead of broader industry adoption of composite formats.
