Requesting Certificates with ML-DSA-Based Keys Through the Network Device Enrollment Service (NDES)

Author Uwe Gradenegger Posted on Categories Network Device Enrollment Service (NDES), Certificate usage Tags PSCertificateEnrollment, Mobile device management (MDM), Post-quantum cryptography, SCEP, ML-DSA

With the May 2026 security update, Microsoft has added support for the ML-DSA algorithm in Active Directory Certificate Services.

In their documentation, they do write that NDES is not compatible with ML-DSA :

You can enroll ML-DSA certificates through the Certificates Microsoft Management Console (MMC) snap-in and certreq.exe. Enrollment through the Network Device Enrollment Service (NDES) isn't currently available.

But that's not entirely true…

Because its Registration Authority certificates absolutely require a Cryptographic Service Provider (CSP) , NDES is limited to the RSA algorithm. However, that does not mean that modern algorithms cannot be used to request certificates via NDES. This already worked with elliptic curves or AES for the internal CMS message , so why not with ML-DSA as well?

The Test Environment

For the test environment, I set up a certification authority hierarchy that uses ML-DSA-based keys itself. To ensure that the process is reproducible, I have extended my ADCS Deployment Scripts to include support for ML-DSA.

I installed the NDES server without an Enterprise Administrator rights on a Windows Server 2025 with the May 2026 patch level.

So that I can generate SCEP certificate requests using ML-DSA, I have extended the PSCertificateEnrollment PowerShell module accordingly.

Findings

NDES CertificateInsight
Web Server CertificateMust be issued by a classic hierarchy (RSA or ECC). The TLS stack in Windows still seems to have issues when a certificate in the chain uses ML-DSA .
NDES Enrollment AgentIt can originate from a pure ML-DSA hierarchy, but must itself use an RSA key due to CSP restrictions. It must be issued by the same certification authority that will issue the device certificates.
NDES CEP EncryptionIt can originate from a pure ML-DSA hierarchy, but must itself use an RSA key due to CSP restrictions. It must be issued by the same certification authority that will issue the device certificates.
NDES Device CertificateCan use ML-DSA throughout the entire chain.

The result

The result is almost unspectacular—it just works. It seems that NDES doesn't really care what content is being transmitted.

$otp = Get-NDESOTP -ComputerName "ndes01.intra.pqclabor.de"
Get-SCEPCertificate `
  -ComputerName "ndes01.intra.pqclabor.de" `
  -ChallengePassword $otp `
  -Subject "CN=test" `
  -KeyAlgorithm ML-DSA:44

On Meaningfulness

Even if it works, the question remains as to whether it makes sense.

  • No Mobile Device Management (MDM) vendor in the world currently offers an implementation of post-quantum cryptographic algorithms for use with SCEP.
  • Microsoft itself states that it does not support this combination.
  • The entire PQC implementation in Windows does not yet appear to be production-ready. For example, it was broken again right away by the July 2026 patch .

Nevertheless, the exercise has achieved its purpose. It allows us to determine what is already feasible with PQC and what is not. And this is how I interpret the current state of implementation in Windows: as an early testing ground for gaining experience and preparing for production use.

One more thing

Of course, the TameMyCerts Policy Module for Active Directory Certificate Services will also support ML-DSA in the next version, so that it can be combined with NDES and other use cases as usual.

External sources