While companies are right to move cautiously with PKI program changes, planning the migration to quantum-safe cryptography is something to get in front of now. The arrival date of a cryptographically relevant quantum computer remains uncertain. Once such computers exist, however, signatures created with those algorithms can no longer be trusted, because an attacker could derive the private keys and forge them. Moreover, not all the risk of exposure is in the future. An attacker can capture encrypted traffic today—including the key exchange—and store it until a sufficiently powerful quantum computer can break the vulnerable cryptography protecting it. This “harvest now, decrypt later” threat is especially concerning information that needs to remain confidential for years. Note that harvest-now-decrypt-later is a confidentiality problem solved by quantum-safe key establishment such as ML-KEM; ML-DSA, the focus of this post, protects signatures.
The time is ripe for Active Directory Certificate Services (AD CS) administrators to start planning a migration to post-quantum cryptography (PQC). Microsoft has already taken the first step. With the May 12, 2026, security update for Windows Server 2025 (KB5087539), AD CS supports creating certification authorities that sign with the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), which the National Institute of Standards and Technology (NIST) standardized in FIPS 204 to resist attacks by quantum computers. All three ML-DSA parameter sets (ML-DSA-44, ML-DSA-65, and ML-DSA-87) are available, but only on newly installed CAs. Existing CAs can’t be migrated in place, so plan on building a new hierarchy alongside your current one.
There are, however, significant challenges to overcome to get an organization ready for a PQC AD CS environment. Getting relying parties and applications to support PQC is a familiar challenge, but AD CS and the wider Microsoft stack add some considerations of their own. In this post, I’ll offer some advice for handling them.
Before we go on, it’s worth noting that AD CS currently supports pure ML-DSA signatures for post-quantum CAs. Microsoft lists three more algorithms as planned Phase 2 capabilities: composite signatures, which combine ML-DSA with a legacy signature algorithm such as RSA or ECDSA; the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), which establishes shared secrets for encryption; and composite ML-KEM. Microsoft has not yet published a release date for Phase 2, but the groundwork is being laid. The July 2026 Windows updates added hybrid ML-KEM key exchange to TLS 1.3 and composite algorithm support to the Windows cryptography APIs, even though AD CS can’t issue those certificates yet. If your evaluation depends on these capabilities, start with a focused ML-DSA lab now, and expand it when the additional algorithms and enrollment capabilities your organization needs become available.
Active Directory
Windows Server 2025 gained CNG API support for ML-DSA in the November 11, 2025 update (KB5068861), which is the platform prerequisite for domain controllers (DCs) to process certificates with ML-DSA signatures. Many applications depend on Active Directory (AD), but they don’t all connect or authenticate in the same way. Two certificate-dependent scenarios that need particular attention during a PQC migration are LDAP over TLS (LDAPS) and Kerberos PKINIT, which supports smart-card sign-in and certain Windows Hello for Business deployments.
For LDAPS, DCs present TLS certificates to authenticate themselves to clients. If a client cannot handle the ML-DSA public key or signatures in the certificate chain presented by a DC, the TLS connection will fail. That failure can happen at two layers: the client’s certificate validation must understand ML-DSA, and its TLS stack must offer an ML-DSA signature scheme during the handshake. Microsoft says Schannel supports ML-DSA certificates in supported scenarios on recent Windows builds, but older Windows versions, appliances, and third-party TLS libraries may not. Test LDAPS from each client platform rather than assuming that a successful enrollment means a working connection.
DC selection adds another wrinkle. Some applications connect to a specific DC, while others use discovery or DNS that can lead them to different DCs over time. During a mixed deployment, an application might work with one DC and fail when it reaches another. Pinning applications to a specific DC or set of DCs is neither recommended nor widely supported. Placing systems in a separate organizational unit (OU) isn’t a solution either; OUs don’t define or limit the pool of DCs that might service a client’s request. A dedicated AD site can steer clients toward particular DCs, but it doesn’t guarantee which DC they reach, because clients can fall back to DCs in other sites. On the other hand, a separate PQC testing forest can provide a more predictable environment.
Then there’s the discovery problem: who is using AD? In many organizations, AD-relying applications have accumulated over years without any inventory, because AD doesn’t require clients to be onboarded. Logs, network monitoring, and conversations with application owners can help build such an inventory, but they rarely provide a complete picture overnight. The PKI and directory teams can make that uncertainty more manageable by communicating early, identifying dependencies, providing a PQC test environment, and planning a staged rollout with a clear rollback path. Application owners need time to test—and a successful certificate enrollment should be the beginning of that testing, not the finish line.
Clients that sign in with smart cards or through Windows Hello for Business deployments that rely on PKINIT—and the domain controllers authenticating them—must support the relevant certificate algorithms within the authentication protocol. The ability to verify an ML-DSA signature alone does not establish that support. Legacy or unmanaged clients may therefore need to continue using certificates from a PKI based on classical algorithms, with matching domain controller certificates and authentication paths kept in place.
Enrollment Limitations
Microsoft confirms that the built-in Windows enrollment interfaces used by certreq.exe and the Certificates Microsoft Management Console (MMC) snap-in work with ML-DSA CAs. The Network Device Enrollment Service (NDES), however, does not currently support ML-DSA enrollment. Although many Mobile Device Management (MDM) solutions integrate with AD CS, a large portion of them rely on NDES to act as the intermediary between devices and the CA. Mobile device certificate enrollment will likely be a gap in the Microsoft stack for the foreseeable future. It would be prudent to keep up to date with MDM developments and be ready to test viable alternatives once they become available.
Certificate Templates
Existing certificate templates may need some adjustments before they can issue certificates with ML-DSA public keys. These templates must use a CNG Key Storage Provider, because legacy Cryptographic Service Providers (CSPs) don’t support ML-DSA. That, in turn, requires setting both the Certification Authority and Certificate Recipient compatibility settings to Windows Server 2008 or later; otherwise, CNG providers won’t appear in the template. When using ML-DSA to sign certificates at the CA level, end-entity certificates can continue to use traditional algorithms, providers, and templates without these restrictions. This enables testing of ML-DSA-signed certificate chains without requiring end-to-end PQC. However, when issuing end-entity certificates with ML-DSA keys, additional restrictions apply. Because ML-DSA supports signatures only, templates must have their purpose set to Signature and exclude encryption-related key usages such as Key Encipherment, Data Encipherment, and Key Agreement. Microsoft’s current guidance also excludes the Encrypting File System (EFS) and Secure Email application policies from these templates.
Microsoft plans to add ML-KEM and composite algorithms, but composite signatures alone won’t address encryption requirements. The published roadmap does not say whether or when EFS or S/MIME will support post-quantum certificates.
I recommend planning a new set of certificate templates for use with ML-DSA CAs. If your organization already has formal processes in place for creating, managing, and applying access control to templates, that’s great! If not, this is a good opportunity to start fresh. In a test forest, you certainly don’t need the oversight and governance of a production environment, but it’s an ideal place to start developing a disciplined certificate template management playbook.
Hardware Key Protection
Moving to a new key algorithm may have infrastructure implications for your PKI program. You’re hopefully using hardware security modules (HSMs) to protect your CA keys. You’ll need to do some research into whether the devices you currently have can support the ML-DSA algorithm at the FIPS 140-3 level your organization requires. Check that ML-DSA is covered by the module’s FIPS 140-3 validation, not just listed as a supported feature: the algorithm should have a Cryptographic Algorithm Validation Program (CAVP) certificate and sit inside the validated boundary. The vendor must also ship a CNG Key Storage Provider that exposes ML-DSA, because AD CS uses ML-DSA only through CNG. Even if your HSMs meet all of these requirements, it’s likely that you’ll still need to apply a firmware update to gain access to the feature. Finally, you’ll definitely have to continue to support legacy applications that aren’t compatible with ML-DSA signatures, so you’ll be operating parallel PKIs for the foreseeable future. Ensure that you have enough storage space and licenses on your HSMs to facilitate capacity for overlapping hierarchies, retained keys, and renewal generations being protected. Keep in mind that ML-DSA private keys are larger (up to about 4.9 KB for ML-DSA-87), so check per-key storage limits as well as key counts. Don’t let this stop you from building an ML-DSA lab using software keys. Just make sure that there is no sensitive data in your test environment that would require hardware-backed key protection.
Conclusion
Like other vendors such as EJBCA, Microsoft is taking a phased approach to bringing post-quantum cryptography to AD CS. Although current support is limited to ML-DSA digital signatures, building an ML-DSA AD CS test environment is a great way to dip your organization’s toe into quantum-resistant PKI.
The real value of that lab comes from moving beyond certificate issuance. Can your applications use the certificates? Can your clients validate the chain and check revocation? Do your enrollment, renewal, and recovery processes still work? Answering those questions now will help you identify dependencies and give application owners time to prepare.
Of course, a successful lab won’t mean your organization is ready to replace every production certificate, but it will give you a clearer picture of what comes next. Start small, work closely with your directory and application teams, and document what works—and what doesn’t.
