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

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.

A Quiet Update With Loud Implications

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 (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.

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 & 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 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 × 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.

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 & 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 & 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	1× (baseline)
ECDSA P-256	~64 B	~70 B	~0.3×
ML-DSA-44	1,312 B	2,420 B	~9×
ML-DSA-65	1,952 B	3,309 B	~13×
ML-DSA-87	2,592 B	4,627 B	~18×

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.

Phase	Window	What to actually do
0. Inventory & 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 & 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 & 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.

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 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 anymore?

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 PQC support?

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.

When do we genuinely have to act?

Deprecation pressure on RSA-2048 and ECDSA P-256 begins in 2030 under NIST IR 8547, with a hard disallow of all quantum-vulnerable public-key algorithms in 2035, and CNSA 2.0 starts forcing the issue through procurement as early as 2027. But the real forcing function is your own certificate lifetimes: long-lived anchors issued today already overlap those dates. The inventory work should start now; the algorithm swap then happens on your schedule instead of an auditor’s.

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.

References & 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