NIST finalized ML-DSA (FIPS 204) in August 2024. Microsoft has integrated it into SymCrypt, its core cryptographic library, and Active Directory Certificate Services can now issue certificates with ML-DSA keys — in all three parameter sets, in pure mode only. With signatures weighing 2.4 to 4.6 KB where ECDSA fits in ~64 bytes, this deserves more than a checked box in a migration plan.
For thousands of organizations, the internal PKI is AD CS. Not a CA selected through an RFP: a Windows Server role installed ten or fifteen years ago, bolted onto Active Directory, quietly issuing machine, user, 802.1X, and smartcard certificates without anyone giving it much thought. That is exactly why post-quantum landing in AD CS is an event: the day the "default" CA of the Windows ecosystem can issue ML-DSA, the post-quantum transition stops being a lab topic and becomes an option in an MMC console.
Microsoft started this move at the bottom of its stack: SymCrypt, the cryptographic library underpinning CNG and all of Windows' primitives, now includes ML-DSA (signatures, FIPS 204) and ML-KEM (key encapsulation, FIPS 203). AD CS inherits it: you can now issue X.509 certificates whose public key and signature are ML-DSA. Support is generally available since the May 2026 security update (KB5087539) on Windows Server 2025, for certification authorities and OCSP responders alike.
It is a real milestone. But between "AD CS can issue ML-DSA" and "my PKI is post-quantum ready" lies a considerable gap. This article maps out precisely what Microsoft covers — and, more importantly, what remains on your plate.
ML-DSA in a nutshell: three levels, signatures ten times heavier
ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly CRYSTALS-Dilithium) is the post-quantum signature algorithm standardized by NIST in FIPS 204, finalized in August 2024. It rests on module lattice problems, believed to resist known quantum algorithms, including Shor's.
The standard defines three parameter sets, mapped to the NIST security categories:
| Parameter set | NIST category | Signature size |
|---|---|---|
| ML-DSA-44 | 2 | ~2.4 KB |
| ML-DSA-65 | 3 | ~3.3 KB |
| ML-DSA-87 | 5 | ~4.6 KB |
The number to remember is the sizes. An ECDSA P-256 signature weighs about 64 bytes. An ML-DSA-65 signature — the middle set, the natural choice for a CA — weighs more than fifty times that, and the public key inflates just as much. In practice: every certificate in the chain grows by several kilobytes, a TLS handshake carries the full chain plus the signature over the ephemeral key, and constrained devices (IoT, OT, RADIUS, aging network gear) that buffer certificates in fixed-size allocations may simply fail. This is not an implementation detail: it is the sizing parameter of any post-quantum certificate architecture.
What Microsoft actually covers
The delivered scope is crisp, and it deserves credit for its clarity:
- Issuance of certificates with ML-DSA keys, powered by SymCrypt and exposed through AD CS;
- All three parameter sets — ML-DSA-44, ML-DSA-65, ML-DSA-87 — leaving the security/size trade-off up to you;
- Pure ML-DSA only: the certificate key is an ML-DSA key, the issuer's signature is ML-DSA. Full stop.
That last point is the most important sentence in the announcement, and it is a sentence defined by what it omits: no hybrid, no composite. AD CS issues neither composite certificates (a structure combining a classical key and a post-quantum key under a single OID, still at draft stage within the IETF LAMPS working group), nor any linked classical + PQ certificate mechanism. You get ML-DSA alone, or nothing.
For an internal pilot, for validating your tooling chain, for measuring the size impact on your handshakes: this is exactly what you need. For a production deployment in a French regulated environment, this is where the trouble starts.
Pitfall #1: no hybridization on offer — and ANSSI requires it
ANSSI, in its guidance on the post-quantum transition, recommends hybridization during the transition phase: combining a battle-tested classical algorithm (ECDSA, RSA) with a post-quantum one, so that security holds as long as either one remains unbroken. The reasoning is prudential: ML-DSA is young. Its cryptanalysis has about a decade behind it, versus more than forty years for RSA. If a weakness were found — not quantum, but classical, in the lattice assumptions or in the implementations — a pure ML-DSA system would have no safety net.
A pure ML-DSA AD CS deployment therefore does not meet this expectation. It swaps one risk (quantum, future) for another (algorithmic, immediate) instead of covering both. In a French regulated context — OIVs, OSEs, sectors governed by ANSSI frameworks — an architecture file built on ML-DSA alone exposes itself to an unfavorable opinion. We laid out the full reasoning in "Why ML-DSA alone is not enough", but the conclusion fits in one line: pure mode is a pilot tool, not a production target in France today.
Worth noting: the position is not uniform across agencies. The NSA's CNSA 2.0 explicitly targets a final state of post-quantum algorithms alone. But if your reference framework is ANSSI's, hybrid is what counts during the transition.
Pitfall #2: ML-KEM does not make certificates
The messaging around post-quantum Windows mentions ML-DSA and ML-KEM, and confusion sets in quickly in steering committees. Let's put the roles back where they belong.
ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) is a key encapsulation mechanism: it establishes a shared secret, typically in the TLS key exchange. It is the component that answers the "harvest now, decrypt later" threat — intercepting encrypted traffic today to decrypt it in the future.
ML-DSA (FIPS 204) is a signature algorithm: it, and it alone, is what matters for certificate issuance, trust chains, code signing, and timestamping.
Deploying ML-KEM in your TLS stack changes nothing about your certificates. Conversely, issuing ML-DSA certificates does nothing to protect traffic being captured today. The two workstreams are complementary, often owned by different teams, with different urgencies — "harvest now" makes ML-KEM the more pressing one for long-lived confidentiality, while signatures can follow the pace of renewal cycles. Conflating the two into a single roadmap line is the surest way to handle neither properly.
Pitfall #3: a post-quantum leaf under a classical chain proves nothing
Suppose you configure an AD CS template tomorrow to issue ML-DSA-65 server certificates. Question: who signs those certificates?
If the answer is "my current issuing CA, with its RSA-2048 key," you have built an incoherent chain. The security of a certification chain is that of its weakest link: an attacker with a cryptographically relevant quantum computer will not attack your ML-DSA key — they will forge a signature from your RSA CA and issue whatever certificate they please. The post-quantum leaf is then an ornament.
A coherent migration is designed top-down: the root (or at minimum a new issuance branch) must itself have a post-quantum key before PQ leaves carry any cryptographic meaning. Concretely, that means creating a parallel hierarchy — a new root or a new ML-DSA subordinate CA — distributing it to trust stores, then attaching the migrated profiles to it. It is a project of key ceremonies, trust anchor distribution via GPO or MDM, and dual operations for several years. AD CS hands you the issuance tool; the chain architecture remains entirely your problem.
Pitfall #4: issuing is one thing, getting validated is another
A certificate is only worth something if the peer on the other end can validate it. And on the validation side, the ecosystem is ahead on almost nothing.
Recent Windows clients, aligned on the same SymCrypt versions, validate ML-DSA. Outside that perimeter, the landscape looks like this: browsers are experimenting with ML-KEM in the TLS key exchange but do not validate ML-DSA signatures in public certificate chains; non-Windows TLS stacks (OpenSSL and its derivatives in their widely deployed versions, embedded stacks, Java middleware) offer support that is experimental at best; network equipment — load balancers, inspection proxies, VPN appliances, RADIUS controllers — generally can neither parse nor verify these certificates.
The practical consequence is immediate: the viable use cases today are closed, homogeneous perimeters. Intra-domain machine authentication between up-to-date Windows servers, fully controlled internal channels, lab pilots. Any certificate profile whose consumers are heterogeneous — public TLS, B2B partners, IoT fleets, network gear — is out of reach for a pure ML-DSA deployment, no matter how willing your CA. Mapping who validates what is a prerequisite at least as structuring as the CA migration itself.
Pitfall #5: and what do your HSMs think about all this?
Any production CA worthy of the name protects its private key in an HSM. Yet ML-DSA support on the HSM side — key generation, signing inside the enclave, the corresponding PKCS#11 mechanisms — is still maturing at several vendors: depending on the product line, it requires recent firmware, specific SDKs, or extension modules, with certification levels lagging behind. As of mid-2026, several vendors have had their ML-DSA/ML-KEM/SLH-DSA algorithms certified under NIST's CAVP program (Entrust nShield 5 on firmware 13.8.0, Utimaco on firmware 4.40+, Thales Luna on 7.9…) — but combined FIPS 140-3 validation including PQC remains, for most, in progress ("Modules in Process" status), and PKCS#11 3.2 standardization of the ML-DSA mechanisms is not yet universally deployed.
The operational trap is tempting and dangerous: standing up an ML-DSA CA whose key lives in software because the incumbent HSM cannot keep up. What you get is a "post-quantum" CA whose private key is less well protected than that of the RSA CA it claims to replace — a clear regression in posture in the name of modernity. Before putting an ML-DSA CA on the calendar, the question to ask your HSM vendor is not "do you support ML-DSA?" but: on which firmware, with which PKCS#11 mechanisms, under which certification, and on what timeline for my product line.
What to do with it: a pilot, not a cutover
Taken together, these five points draw a balanced conclusion. ML-DSA support in AD CS is excellent news: it puts post-quantum within reach of the world's most widely deployed PKI and finally enables realistic pilots on tooling teams already know. And in the same breath, it covers neither the hybridization ANSSI expects, nor the chain redesign, nor the heterogeneity of validators, nor HSM maturity.
The sensible approach in 2026 comes in four steps. Inventory: which profiles, which algorithms, which consumers, which deadlines. Pilot: an ML-DSA issuance branch on a closed Windows-to-Windows perimeter, to measure sizes, validation times, application behavior. Architect: decide now where hybrid will be required and acknowledge that AD CS alone will not deliver it. Sequence: chain first, leaves second, at the pace of renewals rather than in a big bang.
Where PKIFactor / ZetaCA fit in
The message that follows from everything above: there is no need to replace everything. Your AD CS remains relevant for what it does well, including pure ML-DSA pilots on homogeneous Windows perimeters.
That is the role of an orchestration layer like PKIFactor: connect the existing AD CS, a post-quantum CA, Vault, EJBCA, or public CAs behind a single control plane, migrate certificate profiles one by one to the right authority, and keep the inventory — algorithm breakdown included — across both worlds at once. For the profiles that must go beyond what AD CS covers — typically the hybrid required in ANSSI contexts, with keys in an HSM via PKCS#11 — ZetaCA provides the PQ-native authority that slots into this orchestration without touching the existing estate.
If you want an objective view of your starting point, our free crypto audit tool is openly available at audit.zetacert.com — and if a pilot tempts you, book a POC.
Key takeaways
- AD CS now issues ML-DSA (FIPS 204, three parameter sets) via SymCrypt — in pure mode only, with no hybrid or composite.
- ANSSI recommends hybridization during the transition: a pure ML-DSA deployment does not meet that expectation in a French regulated context.
- ML-KEM ≠ certificates: it is key encapsulation (TLS), not signatures — two distinct workstreams not to be conflated.
- A PQ leaf under an RSA chain proves nothing, and both non-Windows validation and HSM support remain immature: pilot on closed perimeters, sequence the chain first.
