Le NIST a finalisé ML-DSA (FIPS 204) en août 2024. Microsoft l'a intégré à SymCrypt, sa bibliothèque cryptographique de référence, et Active Directory Certificate Services peut désormais émettre des certificats à clé ML-DSA — dans les trois jeux de paramètres, en mode pur uniquement. Avec des signatures de 2,4 à 4,6 Ko là où ECDSA tient en ~64 octets, le sujet mérite mieux qu'une case cochée dans un plan de migration.
Pour des milliers d'organisations, la PKI interne, c'est AD CS. Pas une CA choisie après un appel d'offres : un rôle Windows Server installé il y a dix ou quinze ans, adossé à l'Active Directory, qui émet des certificats machine, utilisateur, 802.1X, smartcard, sans que personne n'y pense vraiment. C'est précisément pour cela que l'arrivée du post-quantique dans AD CS est un événement : le jour où la CA « par défaut » de l'écosystème Windows sait émettre du ML-DSA, la transition post-quantique cesse d'être un sujet de laboratoire pour devenir une option dans une console MMC.
Microsoft a engagé ce mouvement par le bas de sa pile : SymCrypt, la bibliothèque cryptographique qui sous-tend CNG et l'ensemble des primitives de Windows, intègre ML-DSA (signature, FIPS 204) et ML-KEM (encapsulation de clé, FIPS 203). AD CS en hérite : il devient possible d'émettre des certificats X.509 dont la clé publique et la signature relèvent de ML-DSA. Le support est généralement disponible depuis la mise à jour de sécurité de mai 2026 (KB5087539) sur Windows Server 2025, pour les autorités de certification comme pour les répondeurs OCSP.
C'est une étape réelle. Mais entre « AD CS sait émettre du ML-DSA » et « ma PKI est prête pour le post-quantique », il y a un écart considérable. Cet article délimite précisément ce que Microsoft couvre — et surtout ce qui reste à votre charge.
ML-DSA en deux mots : trois niveaux, des signatures dix fois plus lourdes
ML-DSA (Module-Lattice-Based Digital Signature Algorithm, anciennement CRYSTALS-Dilithium) est l'algorithme de signature post-quantique standardisé par le NIST dans FIPS 204, finalisé en août 2024. Il repose sur des problèmes de réseaux euclidiens modulaires, réputés résistants aux algorithmes quantiques connus, dont celui de Shor.
Le standard définit trois jeux de paramètres, correspondant aux catégories de sécurité NIST :
| Jeu de paramètres | Catégorie NIST | Taille de signature |
|---|---|---|
| ML-DSA-44 | 2 | ~2,4 Ko |
| ML-DSA-65 | 3 | ~3,3 Ko |
| ML-DSA-87 | 5 | ~4,6 Ko |
Le chiffre à retenir est celui des tailles. Une signature ECDSA P-256 pèse environ 64 octets. Une signature ML-DSA-65 — le jeu médian, le choix naturel pour une CA — en pèse plus de cinquante fois plus, et la clé publique suit la même inflation. Concrètement : chaque certificat de la chaîne grossit de plusieurs kilooctets, un handshake TLS transporte la chaîne complète plus la signature de la clé éphémère, et les équipements contraints (IoT, OT, radius, matériel réseau ancien) qui bufferisent les certificats dans des tailles fixes peuvent simplement échouer. Ce n'est pas un détail d'implémentation : c'est le paramètre dimensionnant de toute architecture de certificats post-quantiques.
Ce que Microsoft couvre réellement
Le périmètre livré est net, et il faut le créditer de sa clarté :
- Émission de certificats à clé ML-DSA, portée par SymCrypt et exposée à travers AD CS ;
- Les trois jeux de paramètres — ML-DSA-44, ML-DSA-65, ML-DSA-87 — laissant le choix du compromis sécurité/taille ;
- ML-DSA pur uniquement : la clé du certificat est une clé ML-DSA, la signature de l'émetteur est ML-DSA. Point.
Ce dernier point est la phrase la plus importante de l'annonce, et c'est une phrase en creux : pas d'hybride, pas de composite. AD CS n'émet ni certificats composites (une structure combinant clé classique et clé post-quantique sous un OID unique, encore à l'état de draft au sein du groupe LAMPS de l'IETF), ni mécanisme de certificats liés classique + PQ. Vous obtenez du ML-DSA seul, ou rien.
Pour un pilote interne, pour valider la chaîne d'outillage, pour mesurer l'impact des tailles sur vos handshakes : c'est exactement ce qu'il faut. Pour un déploiement de production en environnement réglementé français, c'est là que les ennuis commencent.
Piège n°1 : pas d'hybridation — et l'ANSSI la demande
L'ANSSI, dans ses avis sur la transition post-quantique, recommande l'hybridation pendant la phase de transition : combiner un algorithme classique éprouvé (ECDSA, RSA) et un algorithme post-quantique, de sorte que la sécurité tienne tant que l'un des deux n'est pas cassé. Le raisonnement est prudentiel : ML-DSA est jeune. Sa cryptanalyse a une dizaine d'années derrière elle, contre plus de quarante pour RSA. Si une faiblesse était découverte — non pas quantique, mais classique, dans les hypothèses de réseaux ou dans les implémentations —, un système ML-DSA pur n'aurait aucun filet.
Un déploiement AD CS en ML-DSA pur ne répond donc pas à cette attente. Il remplace un risque (quantique, futur) par un autre (algorithmique, immédiat) au lieu de couvrir les deux. En contexte réglementé français — OIV, OSE, secteurs sous référentiels ANSSI —, un dossier d'architecture fondé sur du ML-DSA seul s'expose à un avis défavorable. Nous avons détaillé ce raisonnement dans « Pourquoi ML-DSA seul ne suffit pas », mais la conclusion tient en une ligne : le mode pur est un outil de pilote, pas une cible de production en France aujourd'hui.
À noter : la position n'est pas uniforme entre agences. La CNSA 2.0 de la NSA assume, elle, une cible finale en algorithmes post-quantiques seuls. Mais si votre référentiel est celui de l'ANSSI, c'est l'hybride qui fait foi pendant la transition.
Piège n°2 : ML-KEM ne fabrique pas de certificats
La communication autour du post-quantique Windows mentionne ML-DSA et ML-KEM, et la confusion s'installe vite dans les comités de pilotage. Remettons les rôles en place.
ML-KEM (FIPS 203, anciennement CRYSTALS-Kyber) est un mécanisme d'encapsulation de clé : il sert à établir un secret partagé, typiquement dans l'échange de clés TLS. C'est le composant qui répond à la menace « harvest now, decrypt later » — l'interception aujourd'hui de trafic chiffré pour déchiffrement futur.
ML-DSA (FIPS 204) est un algorithme de signature : c'est lui, et lui seul, qui concerne l'émission de certificats, les chaînes de confiance, la signature de code ou d'horodatage.
Un déploiement ML-KEM dans votre pile TLS ne change rien à vos certificats. Inversement, émettre des certificats ML-DSA ne protège en rien le trafic capturé aujourd'hui. Les deux chantiers sont complémentaires, portés par des équipes souvent différentes, avec des urgences différentes — le « harvest now » rend ML-KEM plus urgent pour la confidentialité longue durée, tandis que les signatures peuvent suivre le rythme des cycles de renouvellement. Confondre les deux dans une même ligne de roadmap est le plus sûr moyen de ne bien traiter ni l'un ni l'autre.
Piège n°3 : une feuille post-quantique sous une chaîne classique ne prouve rien
Supposons que vous configuriez demain un template AD CS pour émettre des certificats serveur en ML-DSA-65. Question : qui signe ces certificats ?
Si la réponse est « ma CA émettrice actuelle, à clé RSA-2048 », vous avez construit une chaîne incohérente. La sécurité d'une chaîne de certification est celle de son maillon le plus faible : un attaquant disposant d'un ordinateur quantique pertinent ne s'attaquera pas à votre clé ML-DSA — il forgera une signature de votre CA RSA et émettra le certificat qu'il voudra. La feuille post-quantique est alors un ornement.
Une migration cohérente se pense du haut vers le bas : la racine (ou au minimum une nouvelle branche d'émission) doit elle-même être à clé post-quantique avant que les feuilles PQ n'aient un sens cryptographique. Concrètement, cela signifie créer une hiérarchie parallèle — nouvelle racine ou nouvelle CA subordonnée ML-DSA —, la distribuer dans les magasins de confiance, puis y rattacher les profils migrés. C'est un projet de cérémonie de clés, de distribution de trust anchors via GPO ou MDM, et de double exploitation pendant plusieurs années. AD CS vous donne l'outil d'émission ; l'architecture de la chaîne, elle, reste entièrement votre problème.
Piège n°4 : émettre est une chose, faire valider en est une autre
Un certificat n'a de valeur que si le pair d'en face sait le valider. Or, côté validation, l'écosystème est en avance sur presque rien.
Les clients Windows récents, alignés sur les mêmes versions de SymCrypt, valident ML-DSA. En dehors de ce périmètre, le paysage est le suivant : les navigateurs expérimentent ML-KEM dans l'échange de clés TLS mais ne valident pas les signatures ML-DSA dans les chaînes de certificats publiques ; les piles TLS non-Windows (OpenSSL et ses dérivés dans leurs versions massivement déployées, piles embarquées, middlewares Java) offrent un support au mieux expérimental ; les équipements réseau — load balancers, proxies d'inspection, appliances VPN, contrôleurs radius — ne savent en général ni parser ni vérifier ces certificats.
La conséquence pratique est immédiate : les cas d'usage viables aujourd'hui sont les périmètres fermés et homogènes. Authentification machine intra-domaine entre serveurs Windows à jour, canaux internes maîtrisés de bout en bout, pilotes de laboratoire. Tout profil de certificat dont les consommateurs sont hétérogènes — TLS public, partenaires B2B, flotte IoT, équipements réseau — est hors de portée d'un déploiement ML-DSA pur, quelle que soit la bonne volonté de votre CA. Cartographier qui valide quoi est un prérequis au moins aussi structurant que la migration de la CA elle-même.
Piège n°5 : et vos HSM, ils en pensent quoi ?
Une CA de production digne de ce nom protège sa clé privée dans un HSM. Or le support de ML-DSA côté HSM — génération de clé, signature à l'intérieur de l'enclave, mécanismes PKCS#11 correspondants — reste en cours de maturation chez plusieurs fournisseurs : selon les gammes, il passe par des firmwares récents, des SDK spécifiques ou des modules d'extension, avec des niveaux de certification qui suivent avec retard. À la mi-2026, plusieurs fournisseurs ont fait certifier leurs algorithmes ML-DSA/ML-KEM/SLH-DSA au programme CAVP du NIST (Entrust nShield 5 en firmware 13.8.0, Utimaco en firmware 4.40+, Thales Luna en 7.9…) — mais la validation FIPS 140-3 combinée au PQC reste, chez la plupart, en cours (statut « Modules in Process »), et la normalisation PKCS#11 3.2 des mécanismes ML-DSA n'est pas encore universellement déployée.
Le piège opérationnel est tentant et dangereux : monter une CA ML-DSA dont la clé vit en logiciel parce que le HSM en place ne suit pas. On obtient alors une CA « post-quantique » dont la clé privée est moins bien protégée que celle de la CA RSA qu'elle prétend remplacer — un recul net de posture au nom de la modernité. Avant d'inscrire une CA ML-DSA au calendrier, la question à poser à votre fournisseur HSM n'est pas « supportez-vous ML-DSA ? » mais : sur quel firmware, avec quels mécanismes PKCS#11, sous quelle certification, et à quelle échéance sur ma gamme.
Ce qu'il faut en faire : un pilote, pas une bascule
Mis bout à bout, ces cinq points dessinent une conclusion équilibrée. Le support ML-DSA dans AD CS est une excellente nouvelle : il met le post-quantique à portée de la PKI la plus déployée du monde et permet enfin des pilotes réalistes sur l'outillage que les équipes connaissent. Et dans le même mouvement, il ne couvre ni l'hybridation attendue par l'ANSSI, ni la refonte de la chaîne, ni l'hétérogénéité des validateurs, ni la maturité HSM.
La démarche raisonnable en 2026 tient en quatre temps. Inventorier : quels profils, quels algorithmes, quels consommateurs, quelles échéances. Piloter : une branche d'émission ML-DSA sur un périmètre fermé Windows-à-Windows, pour mesurer les tailles, les temps de validation, le comportement des applications. Architecturer : décider dès maintenant où l'hybride sera exigé et acter qu'AD CS seul n'y répondra pas. Séquencer : la chaîne d'abord, les feuilles ensuite, au rythme des renouvellements plutôt qu'en big bang.
Où PKIFactor / ZetaCA interviennent
Le message qui découle de tout ce qui précède : il n'y a pas besoin de tout remplacer. Votre AD CS reste pertinent pour ce qu'il fait bien, y compris pour des pilotes ML-DSA purs sur des périmètres Windows homogènes.
C'est le rôle d'une couche d'orchestration comme PKIFactor : connecter l'AD CS existant, une CA post-quantique, Vault, EJBCA ou des CA publiques derrière un même plan de contrôle, migrer les profils de certificats un par un vers la bonne autorité, et garder l'inventaire — répartition algorithmique comprise — sur les deux mondes à la fois. Pour les profils qui doivent aller au-delà de ce qu'AD CS couvre — typiquement l'hybride exigé en contexte ANSSI, avec clés en HSM via PKCS#11 —, ZetaCA fournit l'autorité PQ-native qui s'insère dans cette orchestration sans toucher à l'existant.
Si vous voulez objectiver votre point de départ, notre outil d'audit crypto gratuit est en accès libre sur audit.zetacert.com — et si un pilote vous tente, réservez un POC.
À retenir
- AD CS émet désormais du ML-DSA (FIPS 204, trois jeux de paramètres) via SymCrypt — en mode pur uniquement, sans hybride ni composite.
- L'ANSSI recommande l'hybridation pendant la transition : un déploiement ML-DSA pur ne répond pas à cette attente en contexte réglementé français.
- ML-KEM ≠ certificats : c'est de l'encapsulation de clé (TLS), pas de la signature — deux chantiers distincts à ne pas confondre.
- Une feuille PQ sous une chaîne RSA ne prouve rien, et la validation hors Windows comme le support HSM restent immatures : pilotez sur périmètre fermé, séquencez la chaîne d'abord.
