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

Zur Sinnhaftigkeit

Auch wenn es funktioniert stellt sich die Frage nach der Sinnhaftigkeit.

  • Kein Mobile Device Management (MDM)-Hersteller dieser Welt hat derzeit eine Implementierung für Postquanten-Kryptoalgorithmen, um diese dann mit SCEP zu nutzen.
  • Microsoft selbst sagt aus, dass die diese Kombination nicht unterstützen.
  • Die ganze PQC-Implementierung in Windows scheint noch nicht Produktionsreif zu sein. Beispielsweise wurde sie im Juli 2026 Patch gleich wieder kaputtgemacht.

Die Übung hat dennoch ihren Zweck erreicht. So kann ermittelt werden, was mit PQC bereits realisierbar ist und was nicht. Und so interpretiere ich den derzeitigen Stand der Implementierung in Windows: Als ein frühes Testfeld, um Erfahrungen zu gewinnen und sich auf den produktiven Einsatz vorzubereiten.

Eine Sache noch

Natürlich wird das TameMyCerts Policy Module für die Active Directory Certificate Services in der nächsten Version auch ML-DSA unterstützen, sodass es wie gewohnt mit NDES und anderen Use Cases kombiniert werden kann.

Related links:

External sources

en_USEnglish
de_DEDeutsch fr_FRFrançais en_USEnglish