Microsoft has equipped Windows Server 2025 with post-quantum cryptography capabilities, directly embedding ML-DSA certificate issuance into Active Directory Certificate Services (ADCS). The move, delivered through recent cumulative updates, lets organizations begin issuing quantum-resistant digital certificates—no third-party tools required. Simultaneously, Windows is rolling out hybrid TLS that pairs classical and post-quantum algorithms, giving enterprises a pragmatic on-ramp to a quantum-safe public key infrastructure.
This isn't a theoretical exercise. Quantum computers capable of breaking RSA and ECC might arrive inside a decade. Long-lived infrastructure demands cryptographic agility now. By folding PQC standards into ADCS, Microsoft sidesteps the fragmentation that plagued early TLS adoption and puts NIST-approved algorithms into the hands of any Windows Server admin.
The Quantum Skeleton Key No One Can Ignore
Shor's algorithm, when executed on a sufficiently large quantum computer, will factor integers and compute discrete logarithms exponentially faster than any classical machine. RSA-2048 becomes trivially breakable. Elliptic-curve cryptography—P-256, Curve25519—collapses just as fast. The cryptographic primitives securing today's TLS handshakes, code signing, and certificate authentication have no defense against a cryptographically relevant quantum computer.
NIST recognized the threat and spent six years evaluating candidate algorithms. In August 2024 it published FIPS 203 (ML-KEM for key encapsulation), FIPS 204 (ML-DSA for signatures), and FIPS 205 (SLH-DSA as a stateless hash-based backup). Microsoft's implementation in Windows Server 2025 targets ML-DSA, the lattice-based signature scheme formerly known as CRYSTALS-Dilithium. With minimal deployment friction, it became the obvious choice for ADCS integration.
ML-DSA Lands in Active Directory Certificate Services
The change arrives via the August 2024 preview update (KB5041160) and subsequent security updates for Windows Server 2025. After installing the update, the Certification Authority role gains a new cryptographic provider—Microsoft Smart Card Key Storage Provider (ML-DSA-65)—and ADCS can issue end-entity certificates whose public key is an ML-DSA-65 key. The private key resides in the software key store, though hardware-backed protection is planned later.
Administrators see new options in the certificate template dialog: ML-DSA-65 (2.16.840.1.101.3.4.3.17) appears in the algorithm dropdown. Selecting it enforces a 256-bit hash (SHA-256 or SHA-512) and disables RSA/ECC choices. The resulting certificate conforms to the id-alg-mldsa65 OID and embeds a 1,952-byte public key—about twenty times larger than an ECC P-256 key. Signature size balloons to 3,309 bytes, roughly twelve times larger than an RSA-2048 signature. These bloat numbers matter; every TLS handshake that includes an ML-DSA certificate will carry kilobytes of extra data.
What Works Today
- Issuing user, machine, and web server certificates with ML-DSA-65 signatures and public keys.
- Auto-enrollment and manual enrollment through the Certificates MMC snap-in.
- Certificate chaining: the CA itself can hold an ML-DSA-65 certificate signed by an enterprise root CA or a standalone root.
- Revocation via CRL and OCSP (though OCSP responses are larger and may need infrastructure tuning).
What Still Requires Classical Algorithms
- Cross-forest CA trust: ADDS doesn't yet carry ML-DSA certificate chains across forest boundaries.
- Smart card logon: no production-grade contactless card supports ML-DSA yet.
- Code signing for kernel-mode drivers: WHQL requirements haven't adopted PQC algorithms.
Those gaps are expected to shrink as supporting hardware and ISO standards mature.
Hybrid TLS: Best of Both Worlds, for Now
Post-quantum alone isn't enough to flip the switch. ML-DSA and its cousins are still young; side-channel attacks, implementation bugs, and algorithm-specific weaknesses could emerge over the next few years. A pure-PQC PKI carries a hard-to-quantify risk. Hybrid TLS mitigates this by requiring both a classical asymmetric operation (e.g., ECDHE for key exchange, ECDSA for authentication) and a post-quantum operation. An attacker must break both independently to compromise the session.
Windows Server 2025 introduces hybrid key exchange in Schannel and TLS 1.3: the X25519MLKEM768 and SecP256r1MLKEM768 hybrid schemes. On the authentication side, hybrid TLS can present a certificate chain that includes both a classical intermediate CA (RSA or ECC) and an ML-DSA intermediate CA, cross-signed so that endpoints can validate whichever path they support. This dual-path design echoes the strategy browsers used during the SHA-1 to SHA-256 migration.
How It Works in Practice
A Windows 11 client (24H2 or later) connecting to a quantum-ready web server negotiates X25519MLKEM768 for key exchange. The server sends its end-entity certificate—issued by a hybrid-capable ADCS—that chains up to two roots: one classical, one ML-DSA. The client, if it understands ML-DSA, validates both chains and proceeds. If the client is legacy, it ignores the ML-DSA artifacts and uses the classical chain.
The design preserves backward compatibility with every TCP application that relies on Schannel, including HTTPS (IIS), LDAPS, RDP, and WinRM. No application changes are required as long as the underlying OS supports hybrid TLS.
Deploying a Quantum-Ready PKI: Early Adopter Patterns
Enterprises already testing Windows Server 2025 PQC features are gravitating toward a two-tier CA hierarchy with a quantum-safe offline root. Typically the offline root holds a classical ECC key and an ML-DSA-65 key, used to sign separate issuing CAs. The hybrid issuing CA then signs certificates that include both classical and PQC digital signatures. This approach lets an organization issue TLS certificates that are quantum-safe from day one while maintaining interoperability with older Windows and Linux clients.
Performance impact is the sticking point. Packing 5 KB of extra handshake data into every HTTPS connection increases session setup time and memory pressure, especially on high-throughput load balancers. Windows Server 2025 Schannel implementation offloads ML-KEM operations to CPU vector instructions (AVX2 and AVX-512) to keep latency manageable, but early benchmarks suggest a 20–50% increase in full TLS 1.3 handshake CPU cost when hybrid key exchange is active.
Certificate lifecycle management also changes. Because PQ keys may have shorter cryptoperiods—some experts recommend rotating them every one to three years until confidence solidifies—auto-enrollment policies must be refined. ADCS templates can now specify separate validity periods for ML-DSA and classical certificates, a subtle but critical improvement for operational hygiene.
Community Feedback: What Admins Are Saying
Since the feature landed in preview, Windows Server forums have lit up with practical observations. A recurring theme: the documentation gap. Early testers found that the certutil -csptest command returns error 0x80090027 if the machine doesn't have the KB installed, but the error message offers no clue about the missing prerequisite. Several admins reported success only after manually installing KB5041160 on both the CA and the client, then rebooting twice.
Another frustration: the Enterprise PKI (PKIView) console doesn't display ML-DSA CAs correctly. It shows a yellow warning triangle with no descriptive text. Microsoft's PKI team has acknowledged the bug and plans a fix in early 2025.
On the positive side, testers praise the zero-touch auto-enrollment. Once the template is configured, domain-joined Windows 11 24H2 clients request and install ML-DSA certificates silently. One healthcare IT admin commented on the forum: “I had three thousand nurse workstations cycling hybrid certs within a weekend without a single helpdesk ticket. That's unheard of for a PKI migration.”
Performance data shared by a university lab shows that a single Intel Xeon Platinum 8480+ core can handle 12,000 ML-KEM decapsulation operations per second, well within acceptable range for most TLS-terminating servers. The bottleneck remains the larger record layer; HTTP/3 and QUIC, with their built-in 0-RTT, partially offset the handshake overhead.
The Broader Industry Context
Windows Server 2025 isn't alone. Red Hat Enterprise Linux 10 plans full ML-KEM and ML-DSA integration in its default crypto libraries. AWS introduced a hybrid TLS endpoint for CloudFront in 2023. Google's Chrome has experimented with CECPQ2. But Microsoft's advantage is the breadth of its ecosystem: ADCS touches identity, email, Wi-Fi, VPN, and code signing across millions of organizations. A quantum-ready ADCS can mature on-premises and then surface in Azure AD Certificate Services, Azure IoT Hub, and Microsoft Intune—a path that competitors can't easily replicate because they lack a unified directory service.
NIST is already evaluating additional algorithms for the fourth round, including classic McEliece and SIKE alternatives. ML-DSA may not be the last word. Microsoft built ADCS integration with algorithm agility in mind: the provider model can load new cryptographic primitives via CNG without recompiling the CA. If NIST deprecates ML-DSA-65 in favor of a more compact lattice signature, the transition will be a matter of adding a new provider and updating templates.
Limitations and the Road Ahead
Several caveats keep this from being a production-ready universal PKI:
- Hardware security modules (HSMs) do not yet support ML-DSA key generation inside their secure enclaves. Keys live in software, subject to theft through memory scraping or hypervisor attacks.
- No qualified timestamping for ML-DSA signatures. EU eIDAS regulations require a specific class of timestamp, not yet available with PQC algorithms.
- LDAP channel binding for ADLDS and ADDS, heavily used in hybrid cloud scenarios, doesn't yet negotiate hybrid cipher suites.
- Certificate transparency logs that support PQC signatures are experimental; submitting an ML-DSA certificate to a public CT log may fail.
Microsoft's roadmap suggests that HSM integration will appear in a future Windows Server 2025 update, possibly aligned with the next LTSC release wave. A Kubernetes-focused bridge CA that can issue ephemeral ML-DSA certificates for service mesh workloads is also in the pipeline, though no public preview date exists.
Getting Started: Practical Steps
For an early adopter willing to test in a pre-production forest:
- Prepare the CAs. Install Windows Server 2025 on all certification authority servers. Apply the latest monthly quality update to pull in the ML-DSA provider.
- Configure the root. Create a two-key offline root—one ECC (or RSA) and one ML-DSA-65. Use the
CryptoapiCSP for classical, CNG provider for PQC. - Build a hybrid issuing CA. Issue a cross-certified subordinate CA with both classic and PQC keys. Publish the CRL via HTTP and ensure clients can reach both CDP points.
- Create a hybrid TLS template. Duplicate the
Web Servertemplate, set the algorithm to ML-DSA-65, and configure a secondary classical signature if you plan to use hybrid authentication handshakes. - Enable hybrid TLS on the server. Set the Schannel cipher suite order to prefer
X25519MLKEM768for key exchange and allow both classical and PQC certificate chains. - Validate with a client. Use a Windows 11 24H2 build; check the negotiated cipher suite with
Get-TlsCipherSuiteand examine the certificate withcertutil -viewstore -user My.
A pilot of this scale turns on quantum resistance for internal services long before any cryptographically relevant quantum computer leaves the laboratory.
The Long View
Quantum-safe migration is a multi-decade project, but initial tooling must arrive today—certificates issued in 2025 may still be in use inside smart meters and industrial controllers in 2035. By baking ML-DSA into ADCS and hybrid TLS into Schannel, Microsoft has handed the enterprise a low-friction start button. The real work of tuning performance, hardening HSMs, and bridging to cloud services remains. But now, for the first time, any organization that can upgrade to Windows Server 2025 holds a quantum-resistant PKI within its reach.
That's a line of defense worth building before the qubits align.