Post-Quantum Cryptography Comes to AD CS: What ML-DSA Support Really Means for Your Microsoft PKI

On May 12, 2026, Microsoft shipped one of the most consequential changes in the twenty-plus-year history of Active Directory Certificate Services. The 2026-05 security update for Windows Server 2025 (KB5087539) enables AD CS to build certification authorities, issue certificates, and sign OCSP responses using ML-DSA, the Module-Lattice-Based Digital Signature Algorithm standardized by NIST in FIPS 204. It is the first post-quantum algorithm to reach general availability inside Microsoft’s in-box CA.

That matters beyond the cryptography. AD CS quietly anchors certificate issuance in a very large share of the world’s enterprise Windows estates: domain authentication, smart cards, device enrollment, internal TLS, code signing. For years the conventional wisdom was that AD CS sat in maintenance mode and that any serious cryptographic modernization would have to happen elsewhere. The 2025-2026 release cycle reverses that narrative. In this article we unpack what was delivered, the cryptography behind it, what works today and what does not, the regulatory deadlines driving all of this, and a pragmatic phased timeline your PKI team can plan against.

Quick Answer: What Is ML-DSA Support in AD CS?

ML-DSA (FIPS 204) is the NIST post-quantum digital signature algorithm now available in AD CS on Windows Server 2025 via KB5087539 (May 2026). It is signature-only, requires a new parallel CA hierarchy (no in-place migration), and covers code signing, OCSP, and internal certificate issuance. TLS session confidentiality requires ML-KEM (planned Phase 2). NIST IR 8547 disallows all quantum-vulnerable algorithms after 2035.

Key Takeaways

• The May 2026 security update (KB5087539) brings ML-DSA (the NIST FIPS 204 post-quantum signature algorithm) to AD CS on Windows Server 2025. CAs, certificate templates, and Online Responders can now sign with quantum-resistant keys.
• ML-DSA is signature-only. It protects against future forgery of certificates and code signatures; it does not make TLS sessions or encrypted data quantum-safe. That requires ML-KEM, which Microsoft has slated for a later phase along with composite certificates.
• There is no in-place migration. Existing CAs cannot be converted to ML-DSA: you stand up a new, parallel hierarchy. That makes early lab work cheap and procrastination expensive.
• The regulatory clock is fixed even if the quantum one is not: NIST plans to deprecate RSA-2048 and ECDSA P-256 after 2030 and disallow all quantum-vulnerable public-key algorithms after 2035. Trust anchors issued today already overlap those dates.
• The practical first move is not an algorithm swap: it is a cryptographic inventory and an automation layer that makes the eventual swap a configuration change instead of a multi-year project.
• Enterprises are running behind the calendar industry-wide: DigiCert’s July 2026 Quantum Readiness Outlook found 87% of organizations planning, testing, or implementing PQC, but only 7% have deployed quantum-safe or hybrid cryptography across most of their certificates. AD CS’s Phase 1 release gives Windows-centric enterprises a concrete, Microsoft-native way to start closing that gap.

Who Should Care About ML-DSA in AD CS

ML-DSA support in AD CS is not a single team’s decision. PKI engineers own the technical implementation, but security architects, compliance teams, DevSecOps engineers, and CISOs each have distinct accountabilities in ensuring the organization’s CA hierarchy, certificate estate, and code signing pipelines are positioned correctly ahead of the 2030 and 2035 NIST IR 8547 deadlines.

Role	Why It Matters	Action Item
PKI Engineers and Certificate Teams	Own the technical implementation of the parallel ML-DSA CA hierarchy: CA installation, template configuration, OCSP setup, enrollment testing, and the NoHash trap in scripted installs; the five template settings that gate ML-DSA (CNG KSP, Signature purpose, no Key Encipherment, no EFS/S/MIME EKUs, Compatibility level) must all be correct or ML-DSA silently disappears from the Cryptography tab; CyberArk’s 2025 State of Machine Identity Security Report found 34% of organizations still manage certificate lifecycles manually, and a parallel ML-DSA hierarchy operated without CLM automation will not scale to the bulk migration phase	Apply KB5087539 to a Windows Server 2025 lab CA and KB5067036 to test clients before any production work; stand up a two-tier ML-DSA lab hierarchy (root CA + issuing CA) and validate template, enrollment, OCSP, and Authenticode end to end; add the parallel hierarchy to CertSecure Manager for unified inventory and renewal tracking alongside the classical estate; build the cryptographic inventory of the existing classical estate using CBOM Secure before touching production; engage PKI as a Service if internal PKI engineering capacity is insufficient to operate two concurrent hierarchies
Security Architects	Own the governance model for the PQC transition: defining which workloads move to pure ML-DSA now (closed-loop code signing, OCSP, internal attestation), which wait for composite certificates (mixed-trust paths), and which wait for Phase 2 (public TLS, smart card logon, NDES device certificates); the harvest-now-decrypt-later threat means the transition timeline is not driven by when quantum computers arrive but by the validity periods of trust anchors issued today; a 20-year root issued in 2026 is still live in 2046, eleven years past the 2035 disallow date	Define the workload classification policy using the 8-row decision matrix in this article; specify HSM requirements for production ML-DSA CAs (verify ML-DSA CNG KSP support and FIPS 140-3 validation status with HSM vendors before committing); design the parallel hierarchy architecture (offline root CA, issuing CA, CDP/AIA, OCSP) for the PQ estate; plan the composite certificate adoption path for Phase 2 so mixed-trust relying-party migrations are designed before Phase 2 ships; track algorithm migration planning through the PQC Center of Excellence
DevSecOps and Code Signing Teams	Own internal code signing and firmware signing pipelines, which are the most credible first production workloads for a PQ hierarchy under Phase 1: Authenticode (Set-AuthenticodeSignature/Get-AuthenticodeSignature) and .NET 10 MLDsa/MLDsaCng APIs work end to end in a closed loop the organization controls entirely; code signing is also one of the most long-lived signature applications (a signed binary verified years from now must chain to a trust anchor that is still unforgeable at verification time), making it one of the highest-priority workloads to move to ML-DSA	Pilot ML-DSA Authenticode code signing in the lab hierarchy and validate the full sign-verify cycle using Set-AuthenticodeSignature and Get-AuthenticodeSignature on patched Windows 11 24H2/25H2 clients; build a relying-party compatibility matrix (Windows versions, OpenSSL 3.5+, Java, macOS, network appliances, CI/CD runners) before promoting ML-DSA code signing to production; integrate ML-DSA signing certificate lifecycle management into the CI/CD pipeline automation; evaluate CodeSign Secure for policy-driven, HSM-backed ML-DSA signing workflows across Windows, Linux, macOS, and CI/CD pipelines
Compliance and GRC Teams	Must confirm the organization has a documented post-quantum migration program before NIST IR 8547 deprecation pressure begins materializing in audits; ISACA’s April 2025 Quantum Computing Pulse Poll found only 5% of organizations have a defined quantum computing strategy; regulated industries including federal agencies (CNSA 2.0, 2027 procurement requirement), healthcare, financial services, and defense may face framework-specific PQC readiness requirements before the 2030 NIST deadline; the DigiCert July 2026 Quantum Readiness Outlook found only 7% of organizations have deployed quantum-safe or hybrid cryptography across most of their certificates	Confirm the organization has a documented PQC migration roadmap aligned to NIST IR 8547 and applicable framework requirements (CNSA 2.0 for federal, DORA for financial, CMMC for defense); include PQC migration progress in the quarterly compliance evidence package: cryptographic inventory completeness, parallel hierarchy lab status, workload classification coverage, and HSM validation plan; map NIST IR 8547 deadlines (deprecation 2030, disallow 2035) to internal compliance milestones; evaluate PQC Readiness services for a structured assessment and roadmap
CISOs	The PQC transition is a board-level risk because the compliance calendar is fixed regardless of when quantum computers arrive: long-lived trust anchors issued in classical cryptography today will still be in operation when 2030 and 2035 deadlines arrive; DigiCert’s July 2026 Quantum Readiness Outlook found 87% of organizations are planning or piloting PQC but only 7% have deployed at scale; KB5087539 removes the “Microsoft hasn’t shipped anything yet” blocker for Windows-centric organizations, making a PQC program’s absence now a deliberate risk acceptance rather than a technology gap	Fund the PQC program as a strategic investment: cryptographic inventory (Phase 0), lab hierarchy validation (Phase 1), and CLM automation build-out (Phases 2-4) require dedicated headcount and budget that should be on the roadmap now, not in 2029; require that PQC migration progress (cryptographic inventory coverage, parallel hierarchy status, workload migration percentage) is reported as a board-level KPI quarterly; evaluate PKI as a Service for organizations that need a fully managed ML-DSA hierarchy on FIPS 140-3 Level 3 HSMs without building and operating the infrastructure internally; mandate that the post-quantum migration plan is reviewed at the annual PKI program review against the NIST IR 8547 timeline

A Quiet Update With Loud Implications

That matters beyond the cryptography. AD CS quietly anchors certificate issuance in a very large share of the world’s enterprise Windows estates: domain authentication, smart cards, device enrollment, internal TLS, code signing. For years the conventional wisdom was that AD CS sat in maintenance mode and that any serious cryptographic modernization would have to happen elsewhere. The 2025-2026 release cycle (CRL partitioning, audit improvements, and now PQC) reverses that narrative. Microsoft’s message is unambiguous: the in-box CA is a participant in the post-quantum transition, not a casualty of it.

In this blog we unpack what was delivered, the cryptography behind it, what works today and what does not, the regulatory deadlines driving all of this, and a pragmatic phased timeline your PKI team can plan against.

Why Post-Quantum Cryptography Is Needed, and Why PKI Is First in Line

Every certificate your CA issues today rests on RSA or elliptic-curve mathematics. Both derive their security from problems (integer factorization and discrete logarithms) that a sufficiently large, fault-tolerant quantum computer running Shor’s algorithm would solve efficiently. Symmetric cryptography fares far better: Grover’s algorithm only halves effective key strength, so AES-256 and SHA-2 remain comfortably safe. The existential problem is concentrated precisely where PKI lives: asymmetric keys and digital signatures.

Nobody can name the year a cryptographically relevant quantum computer arrives. But the risk is already operational today, for two distinct reasons:

• Harvest now, decrypt later. Adversaries are recording encrypted traffic and stolen ciphertext today with the intent of decrypting it once quantum capability matures. Any data whose confidentiality must outlive the quantum horizon (health records, intellectual property, state secrets) is effectively exposed the moment it crosses a quantum-vulnerable key exchange.
• Long-lived trust. This is the PKI-specific problem, and it is about signatures rather than secrecy. A root CA certificate issued in 2026 with a fifteen- or twenty-year validity period must remain unforgeable through 2041 or beyond. A code-signing or firmware signature applied today will be verified by relying parties years from now. If the underlying algorithm falls within that window, an attacker can mint fraudulent certificates and forged updates that chain perfectly to your trust anchors: retroactively poisoning everything built on them.

Run the arithmetic and the urgency stops being theoretical. Trust anchors are the longest-lived cryptographic artifacts in any enterprise. A classical root created today is making a bet that quantum computing fails to mature for two more decades, a bet that NIST, the NSA, and Microsoft have all publicly declined to take.

The Standards Behind the Shift

In August 2024, after an eight-year global competition, NIST finalized its first three post-quantum standards. All are built on mathematical problems (chiefly structured lattices) for which no efficient quantum algorithm is known:

Standard	Algorithm (lineage)	Purpose	Status in Windows
FIPS 204	ML-DSA (CRYSTALS-Dilithium)	Digital signatures	GA, and now live in AD CS
FIPS 203	ML-KEM (CRYSTALS-Kyber)	Key encapsulation / key exchange	GA in CNG APIs; AD CS support planned (Phase 2)
FIPS 205	SLH-DSA (SPHINCS+)	Stateless hash-based signatures	Available in Microsoft’s crypto libraries; not an AD CS algorithm today

A fourth signature standard, FN-DSA (based on Falcon), is still in draft. For enterprise PKI planning, the pairing that matters is simple: ML-DSA replaces RSA/ECDSA for signing; ML-KEM replaces RSA encryption and (EC)DH for key establishment. AD CS Phase 1 delivers the first half of that pairing.

The Clock You Are Actually Racing

The honest answer to “when will quantum computers break RSA?” is that nobody knows. The compliance answer is far more concrete, because regulators have decided not to wait for certainty. Three timelines now converge on the same decade:

Date	Milestone
Aug 2024	NIST finalizes FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA).
Nov 2024	NIST IR 8547 (draft), Transition to Post-Quantum Cryptography Standards, publishes the deprecation roadmap for RSA, ECDSA, ECDH, DSA, and finite-field DH.
2025	Microsoft announces its Quantum Safe Program and ships PQC algorithms through SymCrypt and the CNG APIs to Windows Insiders; Linux support follows via SymCrypt-OpenSSL.
Oct-Nov 2025	PQC reaches general availability in Windows Server 2025, Windows 11 24H2/25H2 (client enablement via KB5067036), and .NET 10.
May 12, 2026	AD CS ML-DSA support GA on Windows Server 2025 via security update KB5087539.
2027	NSA CNSA 2.0: new acquisitions for U.S. National Security Systems must support quantum-resistant algorithms.
2029	Microsoft’s stated goal for early PQC adoption across its own products and services.
2030	NIST IR 8547: algorithms at the 112-bit security level (RSA-2048 and ECDSA P-256) are deprecated. Continued use requires documented risk acceptance.
2033	Microsoft’s target for completing its transition to PQC, two years ahead of the federal deadline.
2035	NIST IR 8547 / NSM-10: all quantum-vulnerable public-key algorithms (RSA at any key size, ECDSA, ECDH, DSA, FFDH) are disallowed. No risk-acceptance option remains.

Now overlay your own certificate lifetimes onto that table. A 20-year root issued in 2026 expires in 2046, eleven years past the disallow date. A 10-year issuing CA created next year is still operating when RSA-2048 becomes a documented audit finding. This is why Microsoft shipped CA-side support first: the longest-lived objects in the hierarchy are the ones that must move earliest.

The Readiness Gap: What Recent Data Shows

Three independent surveys published over the past eighteen months converge on the same conclusion: awareness of the post-quantum transition is high, but deployment is not.

• ISACA’s Quantum Computing Pulse Poll, published April 28, 2025 from responses by more than 2,600 global digital-trust, cybersecurity, IT audit, and risk professionals, found that 62% worry quantum computing will break today’s encryption, yet only 5% say their organization has a defined quantum computing strategy or roadmap.
• DigiCert’s second annual Quantum Readiness Outlook, published July 23, 2026 from a survey of 1,001 IT and cybersecurity decision-makers across the US, UK, and Australia, found that 87% of organizations are planning, testing, or implementing PQC initiatives, but only 7% report quantum-safe or hybrid cryptography across more than half of their digital certificates: an increase of less than two percentage points from the 5% DigiCert measured in May 2025.
• CyberArk’s 2025 State of Machine Identity Security Report, published March 13, 2025 from a survey of 1,201 security and IT decision-makers, found that 72% of organizations experienced at least one certificate-related outage in 2024, while 34% still manage machine identity lifecycles with manual or non-automated methods.

Read together, these numbers describe the exact gap AD CS’s Phase 1 release lands into: organizations know the transition is coming, most have not deployed quantum-safe cryptography anywhere near production scale, and a third are still managing certificate lifecycles by hand: the same manual process that a parallel ML-DSA hierarchy, and the shrinking public TLS validity schedule, will not tolerate. Closing that gap starts with the discovery work in Phase 0 of the migration timeline below, not with the algorithm swap itself; see our guide on how to build a cryptographic bill of materials for what that discovery work actually involves.

What Microsoft Actually Shipped in AD CS

Phase 1 is deliberately scoped: it covers the signing plane of a Microsoft PKI, end to end. Specifically, AD CS on a patched Windows Server 2025 machine can now:

• Install Root, Subordinate, Enterprise, and Standalone CAs whose own key pair and certificate-signing operations use ML-DSA, including a fully post-quantum chain when every tier uses it.
• Publish certificate templates that issue ML-DSA leaf certificates for code signing, TLS/web server, user, and computer purposes.
• Enroll those certificates through the Certificates MMC snap-in and certreq.exe, including autoenrollment-style template ACL evaluation.
• Sign OCSP responses with an ML-DSA Online Responder signing certificate.
• Verify and apply Authenticode code signatures with ML-DSA certificates: Set-AuthenticodeSignature and the signature UI work end to end, and .NET 10 exposes the algorithm to developers through the MLDsa / MLDsaCng classes.

Microsoft has published the forward roadmap explicitly. Support arrives in phases, and the platform team has committed to extending PQC across the AD CS role services: the Certificate Enrollment Policy and Enrollment Web Services (CEP/CES), NDES, and the Online Responder:

Capability	Standard	Purpose	AD CS status
ML-DSA (pure)	FIPS 204	PQ digital signatures	Available now (Phase 1)
ML-KEM	FIPS 203	PQ key encapsulation	Planned (Phase 2)
Composite ML-DSA	IETF LAMPS draft	Classical + PQ signature in one certificate	Planned (Phase 2)
Composite ML-KEM	IETF LAMPS draft	Classical + PQ key encapsulation	Planned (Phase 2)
CEP / CES / NDES / OCSP role-service coverage	N/A	PQ enrollment and revocation plumbing	Committed; arriving incrementally

Platform baseline. PQC in AD CS requires Windows Server 2025 with the 2026-05 security update (KB5087539) or later on the CA, and Windows 11 24H2/25H2 with the 2025-10 update (KB5067036) or later on enrolling clients. There is no indication of a backport: Windows Server 2019 and 2022 CAs are not expected to receive PQC support. If your issuing CAs still run on older platforms, the OS upgrade is now formally on the PQC critical path. All PQC algorithms also require CNG Key Storage Providers: legacy CryptoAPI CSPs are not supported.

ML-DSA Prerequisites, Configuration Steps, and Common Errors

Use this table before touching the AD CS console. Each row maps a prerequisite or configuration gate to the validation check that confirms it is met, the common error when it is not, the rollback or fix, and the team that owns it. Working through this table in a lab environment before production deployment prevents the five errors that appear consistently in first-contact ML-DSA deployments.

Prerequisite / Configuration Step	Validation Check	Common Error If Not Met	Fix / Rollback	Owner
Windows Server 2025 + KB5087539 on CA host	winver shows Windows Server 2025; wmic qfe get HotFixID lists KB5087539; ML-DSA appears in Server Manager key algorithm list during CA setup	ML-DSA algorithm not listed in CA setup wizard; Setup fails with algorithm not supported error	Apply the 2026-05 cumulative update (KB5087539) or later; confirm update is listed in installed updates before retrying CA installation	PKI Engineer / Windows Infrastructure
Windows 11 24H2/25H2 + KB5067036 on enrolling clients	In the enrollment wizard, Key size field shows a real value (10,496 / 15,616 / 20,736) not 0; enrollment completes successfully and certificate appears in Certificates MMC	Enrollment wizard lists ML-DSA but fails on submit; Key size field shows 0, indicating the algorithm is only partially lit up in the client KSP	Confirm KB5067036 is installed on the client; apply any pending cumulative updates; retry enrollment after confirming Key size shows a valid value	PKI Engineer / Desktop / Client Engineering
CNG Key Storage Provider selected (not legacy CSP)	In the certificate template Cryptography tab, Provider Category is Key Storage Provider; ML-DSA appears in the algorithm list when Purpose is set to Signature	ML-DSA does not appear in the Cryptography tab even after patch; template is using legacy CryptoAPI CSP provider category	Set Provider Category to Key Storage Provider in the template Cryptography tab; ML-DSA will then appear when Purpose is set to Signature	PKI Engineer
Template Purpose set to Signature (exactly)	Request Handling tab shows Purpose: Signature; ML-DSA appears in the Cryptography tab algorithm list; no Key Encipherment or Key Agreement in Key Usage extension	ML-DSA silently disappears from the Cryptography tab; no error message is shown; the only symptom is that ML-DSA is not listed despite the CNG KSP being selected	Open the template Request Handling tab and set Purpose to Signature; remove any Key Encipherment, Key Agreement, or EFS/S/MIME EKU values; ML-DSA will reappear in the algorithm list	PKI Engineer
NoHash passed explicitly in scripted CA installation	CA installation script includes -HashAlgorithmName “NoHash”; after installation certsrv.msc shows Hash Algorithm: NoHash and Signature Algorithm: ML-DSA; pkiview.msc shows CA healthy	CA setup fails with hash algorithm error or installs with SHA-256 hash applied to an ML-DSA key, producing a non-compliant CA certificate; error may be silent if the script does not validate the resulting certificate	Add -HashAlgorithmName “NoHash” to the Install-AdcsCertificationAuthority PowerShell cmdlet or certutil -installcert equivalent; validate the installed CA certificate signature algorithm before issuing any certificates; rebuild the CA if SHA-256 was applied to an ML-DSA key	PKI Engineer / Automation
HSM CNG KSP verified for ML-DSA support	HSM vendor documentation confirms ML-DSA support in the specific firmware version installed; ML-DSA key generation through the HSM CNG KSP succeeds in a test; FIPS 140-3 validation certificate covers the ML-DSA algorithm and the installed firmware version	HSM fails to generate ML-DSA key or returns algorithm not supported error through the CNG KSP; CA installation fails at key generation step	Verify firmware version and CNG KSP integration maturity with the HSM vendor; upgrade HSM firmware if ML-DSA support is available in a later release; run Phase 1 lab on Microsoft Software KSP while waiting for HSM validation	PKI Engineer / HSM Administrator

ML-DSA Under the Hood: What PKI Engineers Should Know

ML-DSA descends from CRYSTALS-Dilithium, the primary signature winner of NIST’s competition. Its security rests on the hardness of the Module Learning With Errors and Module Short Integer Solution problems over structured lattices, mathematics with no known efficient quantum attack. Two of its properties directly shape how AD CS behaves, so they are worth internalizing before you touch a console.

It is a signature-only algorithm

ML-DSA cannot encrypt data and cannot perform key exchange. That single fact explains most of the configuration constraints you will hit: templates must be signature-purpose, Key Encipherment and Key Agreement key usages are forbidden, EFS and secure-email EKUs are rejected, and TLS session confidentiality is untouched until ML-KEM arrives. If a workflow needs a key to protect data rather than prove identity or integrity, ML-DSA is the wrong tool by design.

Three parameter sets, three security/size trade-offs

AD CS supports all three FIPS 204 parameter sets, in pure (non-composite) mode. Pick based on the security category you need and the size budget you can carry:

Parameter set	NIST category	Public key	Private key	Signature	“Key size” shown in Windows UI
ML-DSA-44	Level 2	1,312 B	2,560 B	2,420 B	10,496 bits
ML-DSA-65	Level 3	1,952 B	4,032 B	3,309 B	15,616 bits
ML-DSA-87	Level 5	2,592 B	4,896 B	4,627 B	20,736 bits

A detail that confuses people on first contact: the Windows UI reports key sizes like 15,616 bits, which looks alien next to RSA-2048. It is simply the public key length expressed in bits (1,952 bytes x 8). Nothing exotic: just a much bigger key. As working guidance, ML-DSA-65 is the sensible default for issuing CAs and leaf certificates (Category 3 sits alongside AES-192), ML-DSA-87 suits roots and long-lived anchors where you want maximum margin, and ML-DSA-44 is for genuinely size-constrained cases where Category 2 is an accepted trade.

Why the hash algorithm dropdown disappears

Classical PKI is built on hash-then-sign: the CA computes a digest of the to-be-signed data, then signs the digest with its private key. Hash choice was a separate, configurable degree of freedom, which is exactly how the industry ended up with MD5 and SHA-1 signed by perfectly good keys, and then had to run painful migrations to fix it. ML-DSA removes that knob: message processing is an integral part of the signature scheme itself, internally fixed and not operator-selectable.

AD CS surfaces this honestly. The moment you select an ML-DSA key algorithm during CA setup, the hash algorithm list collapses to a single entry: NoHash. On certificate templates, the hash selector and the “alternate signature format” control (the PKCS#1 v2.1 toggle) grey out: there is no signature-scheme variant to choose. NoHash does not mean the data is unhashed; it means the hashing is baked into FIPS 204 and AD CS will not pretend you have a choice. One whole class of historical PKI misconfiguration simply ceases to exist.

Pure vs. Composite Certificates: The Transition Question

Post-quantum certificates come in two architectural flavors, and Microsoft’s roadmap deliberately includes both:

• Pure. The certificate uses a single post-quantum algorithm: what AD CS ships today. It is the cleanest end-state, but every relying party in the chain must already understand ML-DSA to validate it. In a heterogeneous estate full of appliances, embedded stacks, and legacy middleware, that is a real constraint.
• Composite. The certificate carries a classical key (RSA or ECDSA) and a post-quantum key together, and its signature contains both a classical and a post-quantum signature. Validation requires both to verify, so forging it means breaking both algorithms, and the certificate stays secure as long as either one stands. The price is size (you are carrying two of everything) and the requirement that validators understand the composite format, currently defined in IETF LAMPS drafts.

The practical reading: pure ML-DSA fits closed-loop, greenfield ecosystems where you control every validator: internal code signing, infrastructure attestation, machine-to-machine trust inside a managed fleet. Composite is the migration vehicle for mixed estates, where you need post-quantum protection without betting operations on universal ML-DSA support on day one. AD CS Phase 2 is slated to bring composite ML-DSA and composite ML-KEM; until then, plan pure deployments around relying-party compatibility testing.

Which Workloads Should Move to ML-DSA Now? A Decision Matrix

Not every certificate workload is ready to move, and Phase 1’s scope makes that decision mostly mechanical: if a workload needs encryption, or depends on a role service that has not shipped yet, it waits. Use this matrix to sort your own backlog before you open the AD CS console.

Workload	Move to ML-DSA now?	Why
Internal code signing and firmware signing	Yes, pilot now	Authenticode and .NET 10’s MLDsa APIs work end to end, and you control every validator in a closed-loop signing chain.
OCSP response signing	Yes, pilot now	The Online Responder’s ML-DSA support is GA, and a signing certificate is low blast radius to test.
Internal user or computer certificates via MMC/certreq	Yes, in a parallel lab hierarchy	Enrollment is GA, but autoenrollment and NDES are not, so plan for manual or scripted issuance during the pilot phase.
Public-facing TLS/web server certificates	Not yet	Schannel does not bind ML-DSA server certificates for HTTPS, and most public relying parties cannot validate ML-DSA chains.
Smart card logon and PKINIT	Not yet	Kerberos/PKINIT authentication flows do not support ML-DSA in this release.
NDES/SCEP-issued device certificates (MDM)	Not yet	NDES enrollment for ML-DSA has not shipped; wait for the committed role-service coverage.
S/MIME or EFS encryption	Never with ML-DSA specifically	ML-DSA is signature-only; encryption workloads need ML-KEM, a separate, later phase.
Certificates validated by mixed or third-party relying parties	Wait for composite certificates	Composite ML-DSA (Phase 2) lets a certificate validate against both classical and post-quantum verifiers during the transition.

The pattern underneath the table: everything in the “yes” rows is a closed loop you control end to end, and everything in the “not yet” rows depends on a role service, protocol, or external relying party Microsoft has not extended to ML-DSA yet. That is also the fastest way to explain the phase boundary to a stakeholder who was not in the room for the signature-only discussion above.

Standing Up an ML-DSA CA: What Works Today

New hierarchies only, by design

The single most important deployment fact: ML-DSA CAs must be newly installed. There is no in-place conversion of an existing CA, and no renew-with-new-algorithm path: changing the public-key algorithm means a new key, a new certificate, and effectively a new CA identity. Microsoft’s guidance is to build a parallel post-quantum hierarchy alongside your production PKI and migrate workloads across deliberately. Inconvenient as that sounds, it mirrors how disciplined PKI generations have always been rotated, and it means you can start evaluating today with zero risk to production issuance.

Installing the CA

In the Server Manager AD CS configuration wizard, the three ML-DSA parameter sets now appear in the key algorithm list alongside RSA and ECDSA, and selecting one collapses the hash list to NoHash.

Field note: the NoHash trap. You must pass -HashAlgorithmName “NoHash” explicitly. The AD CS setup engine initializes its defaults to RSA with SHA-256, and it keeps that SHA-256 hash even after you switch the key algorithm to ML-DSA, so an ML-DSA install that omits the parameter fails. The same logic applies in automation: any deployment script that hard-codes SHA256 needs a conditional branch before it touches a PQ CA.

After installation, certsrv.msc shows exactly what you would hope for: the Microsoft Software Key Storage Provider holding an ML-DSA key, hash algorithm NoHash, and a CA certificate whose signature algorithm is ML-DSA. Chain building, CDP/AIA publication, and pkiview.msc health checks behave normally.

Certificate templates: five settings that gate everything

ML-DSA appears in the template Cryptography tab only when the template is shaped correctly, and several of the requirements trace straight back to “signature-only”:

Template setting	Required value	Why it matters
Cryptographic provider category	CNG Key Storage Provider	PQC exists only in the CNG stack; legacy CSP-based templates will never list ML-DSA.
Compatibility (CA and recipient)	Windows Server 2008 or later	CNG providers only appear in the provider list at this compatibility level or above.
Request Handling – Purpose	Signature: exactly	This is the gotcha that costs people an afternoon: with any other purpose (including “Signature and encryption”), ML-DSA silently disappears from the Cryptography tab.
Application Policies (EKU)	No EFS, no Secure E-mail	Both imply encryption operations ML-DSA cannot perform.
Key Usage extension	No Key Encipherment, no Key Agreement	Same reason: the key pair cannot establish or transport secrets.

Enrollment, OCSP, and code signing

Enrollment works today through the Certificates MMC wizard and certreq.exe from patched Windows 11 24H2/25H2 clients. NDES (SCEP) enrollment is explicitly not available yet: relevant if your MDM-issued device certificates ride on NDES.

Field note: the half-patched client. On a partially patched Windows 11 client, the enrollment wizard may list ML-DSA and then fail when you actually enroll. Check the wizard’s Key size field to tell why: a real value (10,496 / 15,616 / 20,736) means the client is fully enabled, while 0 means the algorithm is only partly lit up in the client’s key storage provider: finish patching before you blame the CA.

The Online Responder accepts an ML-DSA OCSP Response Signing certificate (duplicate the default template rather than editing it) and signs responses without complaint. One cosmetic quirk: the responder’s hash-algorithm property can render a nonsense value for ML-DSA configurations, because there is no hash to display. Ignore the string and trust pkiview.msc, which reports the responder healthy. Authenticode is similarly complete: signing and verifying with Set-AuthenticodeSignature / Get-AuthenticodeSignature works end to end, which makes internal code signing one of the most credible first production workloads for a PQ hierarchy.

What Is Not There Yet

Honest scoping is half of good consulting, so here is the current boundary line in one view:

Works today (Phase 1)	Not yet / planned
ML-DSA Root, Sub, Enterprise and Standalone CAs (new installs)	In-place migration or algorithm-change renewal of existing CAs: will not come; plan parallel hierarchies
ML-DSA leaf issuance: code signing, web server, user, computer templates	NDES/SCEP enrollment; full CEP/CES web-service coverage (committed, incremental)
Enrollment via Certificates MMC and certreq.exe	IIS HTTPS bindings with ML-DSA server certificates: Schannel TLS authentication is not enabled for it yet
OCSP response signing with ML-DSA	Kerberos / PKINIT and smart-card logon flows
Authenticode code signing and verification; .NET 10 MLDsa APIs	Anything encryption-shaped (EFS, S/MIME encryption): by design until ML-KEM lands
Windows Server 2025 + Windows 11 24H2/25H2 platform support	Composite ML-DSA / ML-KEM certificates (Phase 2); Windows Server 2019/2022 (no backport expected)

Read the right-hand column carefully before promising anyone a “quantum-safe intranet.” Today’s release secures the issuance and signing plane. The session plane (TLS key exchange, and therefore harvest-now-decrypt-later protection for data in motion) waits on ML-KEM integration through the TLS stack. Third-party relying parties are their own frontier: many applications, appliances, and HSM-adjacent middleware do not yet parse ML-DSA certificates, so every pilot needs a compatibility matrix, not an assumption.

Operational Realities: Size, HSMs, and Running Two PKIs

Everything gets bigger

Lattice security is paid for in bytes. Compare the artifacts your infrastructure actually moves and stores:

Algorithm	Public key	Signature	Signature vs. RSA-2048
RSA-2048	256 B	256 B	1x (baseline)
ECDSA P-256	~64 B	~70 B	~0.3x
ML-DSA-44	1,312 B	2,420 B	~9x
ML-DSA-65	1,952 B	3,309 B	~13x
ML-DSA-87	2,592 B	4,627 B	~18x

A leaf certificate that weighs roughly 1-1.5 KB with RSA lands in the 6-7 KB range at ML-DSA-65 once you account for the embedded public key plus the issuing CA’s signature; a three-tier chain crosses 20 KB before the handshake even starts. OCSP responses grow by a signature plus, typically, an embedded signing certificate. Budget for the consequences now: CDP/AIA and OCSP bandwidth and caching, certificate stores and the CA database, CLM inventories, TLS record and MTU behavior once ML-KEM handshakes arrive, and hard capacity limits on smart cards, TPMs, and constrained devices. None of this is prohibitive (public web PKI is absorbing the same shift), but it belongs in your capacity model, not in your incident postmortem.

HSMs: verify before you promise

The Phase 1 experience runs on the Microsoft Software Key Storage Provider, which is fine for labs and many internal hierarchies. Production roots and issuing CAs in regulated environments will want hardware-backed ML-DSA keys, and that depends entirely on your HSM vendor’s CNG provider exposing the algorithm on firmware that is (or is on a path to being) FIPS 140-3 validated. The major vendors (Thales Luna, entrust nShield, cloud HSM services) have been adding FIPS 203/204 support across recent firmware generations, but validation status and KSP integration maturity vary by model and release. Make “show me ML-DSA through your CNG KSP and show me the validation paperwork” a literal line item in your pilot plan, and decide consciously whether early phases run on software keys while hardware catches up.

You will be running two PKIs for years

A parallel hierarchy is not a weekend lab: it is a second production environment with its own templates, CDP/AIA publication, OCSP, monitoring, key ceremonies, CP/CPS deltas, and eventually a decommissioning plan for the classical side. The organizations that handle this well are the ones that treat the transition as a crypto-agility program: if certificate issuance and renewal are already automated and inventory-driven, swapping algorithms becomes a configuration change executed by machinery. If your estate still renews certificates by spreadsheet and calendar reminder, the PQC migration will feel like the SHA-1 deprecation again, except across every certificate you own, with bigger payloads and harder deadlines.

A Pragmatic Migration Timeline

Mapping the regulatory dates onto concrete PKI work yields a five-phase plan. The windows below assume an enterprise of meaningful size starting roughly now; compress or stretch to taste, but keep the ordering: each phase de-risks the next. For the fuller, cross-technology version of this roadmap beyond AD CS specifically, see our PQC Migration in 2026 guide. Track overall post-quantum migration planning through the PQC Center of Excellence.

Phase	Window	What to actually do
0. Inventory and exposure mapping	Now – end 2026	Build a cryptographic inventory (a CBOM) across CAs, templates, keys, protocols, applications, and embedded devices. Flag the two high-risk classes: long-lived signatures (roots, code/firmware signing, document trust) and long-confidentiality data exposed to harvest-now-decrypt-later. Bring CA platforms to Windows Server 2025 and the client fleet to the PQC-capable baseline.
1. Parallel PQ pilot	2026 – 2027	Stand up an isolated ML-DSA two-tier hierarchy in the lab. Exercise CA install, templates, MMC/certreq enrollment, OCSP, and Authenticode end to end. Run a relying-party compatibility matrix (Windows, OpenSSL 3.5+, Java, network appliances, middleware). Measure size and performance deltas. Draft the CP/CPS amendments and HSM requirements now, while nothing is urgent.
2. Targeted production use	2027 – 2028	Move closed-loop signature workloads first (internal code signing, infrastructure attestation, document signing) where you control every validator. Adopt composite certificates for mixed-trust paths as Phase 2 ships. Bake PQC support into procurement language so every new appliance, HSM, and application arrives ready.
3. Hierarchy transition	2028 – 2030	Issue the next generation of roots and issuing CAs as ML-DSA or composite. Default new issuance away from RSA-2048 and P-256 ahead of the 2030 deprecation. Integrate ML-KEM for TLS as Windows and your load-balancing/inspection stack enable it.
4. Estate migration and retirement	2030 – 2033	Bulk-migrate leaf estates using automated certificate lifecycle tooling: at modern certificate volumes and shrinking lifetimes, manual migration is not arithmetic that closes. Retire classical hierarchies on a published schedule, aligned with Microsoft’s own 2033 full-transition target.
Hard stop	2035	RSA, ECDSA, and classical DH are disallowed under NIST IR 8547. Nothing quantum-vulnerable should remain in production trust paths.

What This Says About AD CS’s Future

There is a second-order signal here worth naming. For a decade, the safe assumption was that AD CS would never see meaningful investment again, and platform decisions were made accordingly. Shipping a NIST-fresh signature algorithm (with a published multi-phase roadmap covering ML-KEM, composite certificates, and the enrollment role services) is not maintenance-mode behavior.

The timing also intersects with a quieter shift in the public trust ecosystem: public CAs are removing the Client Authentication EKU from TLS certificates as root programs split server and client trust, which means the enormous world of mTLS (service meshes, device fleets, B2B API authentication) is migrating to private CAs whether anyone planned it or not. A private CA platform that ships in the OS license, integrates with AD identity, and now signs with post-quantum algorithms is suddenly a very rational landing zone for those workloads. AD CS is not just surviving the PQC transition; it is using it to re-enter the conversation.

How Can Encryption Consulting Help?

Everything above reduces to a sequencing problem: know what you have, prove what works, automate the swap, and hit dates that are already on the calendar. That is precisely the ground Encryption Consulting works every day: we have helped 100+ Fortune 500 organizations assess, design, and operate their cryptographic estates, and our PQC Advisory Services were built for exactly this transition:

Where teams get stuck	How we help
“We don’t actually know where quantum-vulnerable cryptography lives in our environment.”	Our PQC Advisory engagement begins with a Quantum Threat Assessment, and CBOM Secure builds an automated, continuously updated cryptographic bill of materials across certificates, keys, algorithms, and protocols: the inventory every later phase depends on.
“We need a defensible roadmap, not a science project.”	We deliver a Quantum Readiness Roadmap and Strategy aligned to NIST, CISA, and NSA guidance: phased milestones, crypto-agility operating model, and proof-of-concept validation of candidate algorithms before anything touches production.
“Our AD CS estate needs a parallel PQ hierarchy designed properly.”	Our PKI Assessment and Design/Implementation services cover hierarchy architecture, HSM integration, CP/CPS development, and template governance, and PKI-as-a-Service can host the post-quantum generation on FIPS 140-3 Level 3 HSMs if you would rather consume it than build it.
“When the algorithm changes, we have tens of thousands of certificates to move.”	CertSecure Manager, our certificate lifecycle management platform, was built with crypto-agility at its core: continuous discovery across AD CS, HashiCorp Vault, cloud, and appliance estates, risk-profiled inventory, and zero-touch renewal at fleet scale: so an algorithm migration becomes a policy change, not a multi-quarter project.
“Our code signing has to survive the transition intact.”	CodeSign Secure provides policy-driven, HSM-backed signing workflows across Windows, Linux, macOS, and CI/CD pipelines: the natural control plane for moving Authenticode and firmware signing onto post-quantum algorithms.

Conclusion

The May 2026 update is best understood as a starting gun. AD CS can now build a fully post-quantum signing plane (CA hierarchy, issuance, OCSP, code signing) on standardized, NIST-approved cryptography, with key encapsulation and composite certificates already on the published roadmap. The technology question has shifted from “when will Microsoft move?” to “how ready is my estate to follow?”

The uncertainty about quantum hardware cuts both ways, but the compliance calendar does not: 2030 and 2035 are written down, and trust anchors signed today will still be alive when those dates arrive. The organizations that will cross this transition calmly are the ones treating it as a crypto-agility program: inventory first, automation second, algorithms third. Stand up the lab hierarchy, find your incompatibilities while they are cheap, and let the swap itself be boring. That is what good PKI engineering has always looked like.

This post is reviewed on a quarterly cadence given the active NIST IR 8547, Microsoft AD CS roadmap, and HSM vendor PQC validation schedules, and immediately whenever Microsoft ships a new AD CS PQC capability or NIST updates the deprecation timeline.

Frequently Asked Questions

Can I upgrade my existing AD CS CA to ML-DSA?

No. ML-DSA CAs must be newly installed: there is no in-place conversion and no renew-with-new-algorithm path, since changing the public-key algorithm means a new key and a new CA identity. The supported pattern is a parallel post-quantum hierarchy operated alongside your existing PKI while workloads migrate.

Does ML-DSA in AD CS make my TLS quantum-safe?

Not yet. ML-DSA covers signatures: certificate and OCSP integrity, code signing, authentication of identities. Session confidentiality depends on the key exchange, which needs ML-KEM through the TLS stack; today, IIS will not even bind an ML-DSA server certificate for HTTPS. Harvest-now-decrypt-later protection for data in motion arrives with the key-encapsulation phase, not this one.

Which ML-DSA parameter set should I standardize on?

ML-DSA-65 (NIST Category 3) is the pragmatic default for issuing CAs and leaf certificates. Reserve ML-DSA-87 for roots and long-lived anchors where maximum margin justifies the size, and treat ML-DSA-44 as a deliberate exception for size-constrained scenarios where Category 2 is an accepted risk decision.

Why can’t I choose a hash algorithm when using ML-DSA in AD CS?

Because FIPS 204 folds message processing into the signature scheme itself: there is no separate hash-then-sign step to configure. AD CS represents this as the single NoHash option. Remember to pass it explicitly in scripted installs; the setup engine’s defaults remain RSA/SHA-256 and do not auto-correct when you select an ML-DSA key.

Will Windows Server 2019 or 2022 get ML-DSA/PQC support in AD CS?

There is no indication of a backport: PQC in AD CS is a Windows Server 2025 capability. If your CAs run on older platforms, the OS upgrade now sits on the post-quantum critical path and belongs in next year’s plan, not 2030’s.

What is the main takeaway from this article on ML-DSA support in AD CS?

Microsoft’s May 2026 update (KB5087539) gives AD CS the ability to build a fully post-quantum signing plane using ML-DSA (FIPS 204). ML-DSA is signature-only and requires new parallel hierarchies rather than in-place migration. The practical first move is a cryptographic inventory, not an algorithm swap: NIST IR 8547 deprecates RSA-2048 and ECDSA P-256 after 2030 and disallows all quantum-vulnerable algorithms after 2035, and long-lived trust anchors issued today already overlap those dates.

Why does ML-DSA in AD CS matter for enterprise PKI teams?

AD CS anchors certificate issuance across enterprise Windows estates: domain authentication, smart cards, device enrollment, internal TLS, code signing. DigiCert’s July 2026 Quantum Readiness Outlook found 87% of organizations are planning or piloting PQC, but only 7% have deployed quantum-safe or hybrid cryptography across most of their certificates. KB5087539 gives Windows-centric PKI teams a concrete, Microsoft-native starting point. The regulatory clock is fixed: RSA-2048 and ECDSA P-256 are deprecated after 2030, all quantum-vulnerable algorithms disallowed after 2035 under NIST IR 8547.

What risks increase if post-quantum PKI planning is handled manually or reactively?

Three risk categories increase: long-lived trust anchor exposure (a 20-year root issued in 2026 is still live in 2046, eleven years past the 2035 disallow date); harvest-now-decrypt-later exposure (adversaries recording encrypted traffic today intend to decrypt it once quantum capability matures); and estate migration complexity (CyberArk’s 2025 report found 34% of organizations still manage certificate lifecycles manually, making bulk ML-DSA migration a SHA-1-level event at much larger scale).

What prerequisites are required before implementing ML-DSA in AD CS?

Five prerequisites must all be met: Windows Server 2025 + KB5087539 on the CA host; Windows 11 24H2/25H2 + KB5067036 on enrolling clients; CNG Key Storage Provider selected in the certificate template (not legacy CSP); certificate template Purpose set to Signature exactly; and -HashAlgorithmName “NoHash” passed explicitly in any scripted CA installation. The prerequisites table earlier in this article covers the validation check, common error, and fix for each.

What common errors should administrators watch for when deploying ML-DSA in AD CS?

Five errors appear consistently: ML-DSA missing from the Cryptography tab (template Purpose is not set to Signature exactly); CA setup failing with a hash algorithm error (NoHash was omitted from the install command); enrollment failing on a client that lists ML-DSA with Key size showing 0 (client is partially patched); OCSP hash algorithm displaying a nonsense value for ML-DSA (cosmetic only, trust pkiview.msc); and HSM failing to generate an ML-DSA key (HSM firmware does not yet support ML-DSA through the CNG KSP). The prerequisites and common errors table in this article maps each error to its fix.

References and Further Reading

• Post-Quantum Cryptography in AD CS overview (Microsoft Learn)
• What is ML-DSA support in AD CS? (Microsoft Learn)
• KB5087539: May 12, 2026 security update for Windows Server 2025
• Microsoft Security Community: Post-Quantum Cryptography APIs now generally available on Microsoft platforms