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

Author Uwe GradeneggerPosted on Categories Network Device Registration Service (NDES), Certificate usageTags , , , ,

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

In her documentary They do say that NDES is not compatible with ML-DSA,:

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

But that's not entirely true…

NDES is known for its Registration Authority certificates, which definitely one Cryptographic Service Provider (CSP) are limited to the RSA algorithm. However, that does not mean that modern algorithms cannot be used to request certificates via NDES. This has already been the case with elliptic curves or AES for the internal CMS message It works, so why not use ML-DSA as well?

The Test Environment

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

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

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

Findings

NDES CertificateInsight
Web Server CertificateMust be issued by a traditional certificate authority (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 July 2026 Patch Broken Again.

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, that will TameMyCerts Policy Module Active Directory Certificate Services in the next version will also support ML-DSA, so that it can be combined with NDES and other use cases as usual.

Related links:

External sources

en_USEnglish
de_DEDeutsch fr_FRFrançais en_USEnglish