How to Build an ML-DSA CA Hierarchy in Microsoft AD CS

Quick answer: Building an ML-DSA certification authority hierarchy in AD CS on Windows Server 2025 follows the same two-tier root and subordinate pattern as any classical PKI, with three real differences: the KeyLength parameter is specified in bits derived from the algorithm’s actual key size (20,736 bits for ML-DSA-87), the CryptoProviderName must reference the ML-DSA CNG provider explicitly, and there is no in-place upgrade path, so this has to be a new hierarchy stood up in parallel to production, not a modification of an existing CA. You need two servers running Windows Server 2025 with the May 2026 security update (KB5087539) or later, one for the root and one for the subordinate CA, plus a domain-joined Windows 11 client with the October 2025 update or later for enrollment testing. This guide walks the actual configuration: prerequisites, root and subordinate setup, certificate templates, validation, and what to monitor after deployment.

Our ML-DSA support for your Microsoft PKI guide covers what this capability means strategically. This guide is the hands-on companion: the actual commands and configuration steps for standing up a working ML-DSA CA hierarchy in a lab or pilot environment.

Key Takeaways

• An ML-DSA CA hierarchy requires Windows Server 2025 with the May 2026 security update (KB5087539) or later on both the root and subordinate CA servers.
• PowerShell’s Install-AdcsCertificationAuthority takes KeyLength in bits, calculated from the ML-DSA parameter set’s actual key size, and a CryptoProviderName referencing the ML-DSA CNG provider.
• Certificate templates need two specific changes to support ML-DSA: a non-legacy CNG Key Storage Provider, and Purpose set to Signature, since ML-DSA supports only signing, never encryption.
• AD CS supports all three ML-DSA parameter sets in pure mode, across CA hierarchy setup, leaf certificate issuance, and OCSP response signing.
• There is no in-place upgrade path from an existing CA; this deployment has to stand up new root and subordinate CAs in parallel, validated before any production migration.

Prerequisites

• A domain controller running the latest available Windows Server release; Windows Server 2025 is recommended.
• Two servers running Windows Server 2025 with the 2026-05 security update (KB5087539) or later: one for the Root CA, one for the Subordinate CA.
• For enrollment testing: a domain-joined client running Windows 11, version 24H2 or 25H2, with the 2025-10 non-security update (KB5067036) or later.
• Membership in Domain Admins or equivalent, to manage certificate templates and AD CS role installation.

Root CA Setup

The root CA can be configured through the Certification Authority console or PowerShell. The PowerShell path is more reliable for reproducible lab and pilot deployments. The example below uses ML-DSA-87, the highest parameter set:

# KeyLength is specified in bits. For ML-DSA-87: 2592 bytes x 8 = 20736 bits

# For Standalone Root CA (recommended for production)
Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "<your-root-ca-name>" `
  -KeyLength 20736 `
  -HashAlgorithm NoHash `
  -CryptoProviderName "ML-DSA:87#Microsoft Software Key Storage Provider"

# For Enterprise Root CA (lab and test environments)
Install-AdcsCertificationAuthority `
  -CAType EnterpriseRootCA `
  -CACommonName "<your-root-ca-name>" `
  -KeyLength 20736 `
  -HashAlgorithm NoHash `
  -CryptoProviderName "ML-DSA:87#Microsoft Software Key Storage Provider"

Replace the placeholder with your root CA’s common name. Standalone Root CA is the recommended pattern for production, offline root deployments; Enterprise Root CA is appropriate for lab and test environments where the root is domain-joined. Note the HashAlgorithm value: NoHash, since ML-DSA’s signing construction does not use a separate hash algorithm parameter the way classical RSA or ECDSA CA configuration does. After installation, confirm the root CA certificate actually uses the selected ML-DSA algorithm by opening the Certification Authority console (certsrv.msc) and inspecting the CA certificate properties.

Subordinate CA Setup

The subordinate CA follows the same pattern, issued from the ML-DSA root established above, completing a two-tier PKI hierarchy where both tiers use ML-DSA as the signature algorithm. Full post-quantum protection depends on ML-DSA signatures across the entire certificate chain, root through subordinate through leaf; a hierarchy with a classical root and an ML-DSA subordinate does not provide the protection the migration is meant to deliver, so both tiers need to be deployed together as part of the same parallel hierarchy.

Configuring Certificate Templates

A certificate template needs two specific changes before it supports ML-DSA:

1. CNG provider: set the template’s provider to a non-legacy Cryptographic Service Provider, specifically a Key Storage Provider. Post-quantum algorithms are only available through CNG providers, never the legacy CryptoAPI path.
2. Signature purpose: set Purpose under Request Handling to Signature. ML-DSA supports only signing operations, never encryption, so any template still configured for encryption or key exchange purposes will not offer ML-DSA as an option.

To make CNG providers selectable at all in the template, set both the Certification Authority and Certificate recipient compatibility settings to at least Windows Server 2008. Several built-in templates already default to Purpose: Signature, which means ML-DSA becomes available simply by setting the Key Storage Provider on the Cryptography tab; for any other template, change Purpose to Signature on the Request Handling tab first. When configuring extensions, confirm Application Policies do not include encryption-related OIDs like Encrypting File System or Secure E-mail, and confirm Key Usage does not include encryption options like Allow key exchange only with key encryption, since either will conflict with a signature-only algorithm. To build an ML-DSA code signing template specifically, duplicate an existing code signing template and apply the same provider and purpose changes.

Configuring OCSP Response Signing

Revocation checking for ML-DSA-issued certificates should itself use ML-DSA-signed OCSP responses for full end-to-end post-quantum protection. Duplicate the built-in OCSP Response Signing template, set Provider Category to Key Storage Provider and Algorithm name to your chosen ML-DSA parameter set (for example, ML-DSA:65), grant Enroll and Autoenroll permissions to the Online Responder’s computer account, and issue the template from the ML-DSA-configured subordinate CA. Add a new Revocation Configuration in the Online Responder management console pointing at the ML-DSA subordinate CA’s certificate to complete the setup.

Validation and Monitoring

Before treating a pilot as production-ready, validate the full chain: issue a test leaf certificate from the ML-DSA subordinate CA and confirm the enrolling client (Windows 11, 24H2 or 25H2, with KB5067036 or later) successfully requests, receives, and validates it, exercising the actual enrollment path rather than just inspecting certificates in the console. Confirm OCSP responses for that certificate validate correctly using the ML-DSA signing configuration. For ongoing monitoring, track certificate issuance volume and any enrollment failures on the new hierarchy specifically, since a parallel-hierarchy pilot needs its own visibility separate from production CA monitoring, and watch for legacy-CSP-based enrollment attempts against ML-DSA-only templates, which will surface as a distinct failure pattern during the transition period.

Rollback Considerations

Because this is a parallel hierarchy rather than an in-place upgrade, rollback is structurally simple at the infrastructure level: production continues operating on the existing classical hierarchy throughout the pilot, untouched. The real rollback consideration is client and application trust: once clients begin trusting the new ML-DSA root as part of pilot testing, removing that trust cleanly if the pilot needs to be abandoned requires the same explicit trust-store management as adding it did. Keep the pilot’s trust distribution scoped to a defined test population rather than pushing the new root broadly until the hierarchy is fully validated.

What We’d Actually Recommend

Start with ML-DSA-65 for lab and pilot work unless your regulatory environment specifically requires ML-DSA-87 (CNSA 2.0 or similar), since it offers a smaller key and signature footprint while still providing strong security margins. Build the full root-to-subordinate-to-leaf chain in ML-DSA from the start rather than mixing algorithm tiers, since a mixed hierarchy does not deliver genuine end-to-end post-quantum protection. Scope trust distribution tightly during the pilot phase, and validate the complete enrollment and OCSP path with real client hardware before expanding beyond a test population.

How Encryption Consulting Can Help

Planning exactly which certificate templates, applications, and legacy CSP dependencies in your environment will need to migrate to the new ML-DSA hierarchy is the inventory work CBOM Secure is built to support, mapping your existing certificate estate and its provider configurations before the pilot begins.

Our PQC Advisory Services plan the parallel-hierarchy deployment, pilot scope, and production cutover sequencing this guide walks through, tailored to your specific AD CS environment and application dependencies. For organizations that want the CA hierarchy managed rather than self-operated, CertSecure Manager issues and manages ML-DSA, hybrid, and classical certificates across Microsoft AD CS and other CA platforms from a single policy plane.

A Familiar Pattern, With Real Differences

Standing up an ML-DSA CA hierarchy in AD CS follows the two-tier pattern any PKI administrator already knows: root, subordinate, templates, OCSP. The differences that matter are specific and manageable once you know to look for them: bit-length key sizing, the ML-DSA CNG provider string, the signature-only purpose requirement, and the hard constraint that this has to be a new, parallel hierarchy rather than an in-place change to an existing CA. Getting the pilot environment right, validated end to end before any production trust decision, is what turns this from a lab exercise into a credible migration path.

Frequently Asked Questions

What KeyLength value do I use for ML-DSA-87 in Install-AdcsCertificationAuthority?

20736 bits, derived from ML-DSA-87’s 2,592-byte key size (2,592 bytes times 8 bits per byte). The KeyLength parameter is always specified in bits, not bytes, which is a common source of configuration errors.

Can I upgrade my existing production CA to ML-DSA instead of building a new hierarchy?

No. There is no in-place upgrade path. ML-DSA support requires deploying new root and subordinate certification authorities, validated in parallel to production, then migrated to deliberately.

Why doesn’t my certificate template show ML-DSA as an available algorithm?

Most commonly because the template is still using a legacy Cryptographic Service Provider instead of a CNG Key Storage Provider, or because Purpose under Request Handling is not set to Signature. Both changes are required before ML-DSA appears as a selectable algorithm.

Does AD CS support ML-DSA for OCSP response signing?

Yes. Configuring an ML-DSA-signed OCSP Response Signing template, issued from an ML-DSA subordinate CA, lets Online Responders provide end-to-end post-quantum revocation checking for ML-DSA-issued certificates.

Which client build do I need to test ML-DSA certificate enrollment?

A domain-joined Windows 11 client on version 24H2 or 25H2, with the 2025-10 non-security update (KB5067036) or later installed.