Microsoft a choisi la Journée mondiale de préparation quantique de DigiCert, le 17 septembre 2026, pour révéler un détail resté jusque-là confidentiel : son programme Trusted Root Program fait tourner depuis plusieurs semaines un pilote de TLS post-quantique, hors production et hors confiance publique. Sept autorités de certification y participent, DigiCert en tête. L’objectif n’est pas de sécuriser le web grand public dès demain, mais de vérifier que des certificats post-quantiques peuvent traverser toute la chaîne : émission, validation, transport, sans casser les navigateurs, les bibliothèques TLS ou les équipements réseau existants.
L’annonce tombe quatre jours avant une échéance bien plus contraignante. Le 21 septembre 2026, le programme de validation cryptographique du NIST a basculé tous les certificats FIPS 140-2 encore actifs vers le statut « Historical ». Seuls les modules validés FIPS 140-3 restent éligibles aux nouveaux achats fédéraux américains. Entre ce pilote volontaire et cette bascule obligatoire, l’écosystème de la cryptographie à clé publique entre dans sa phase la plus délicate : celle où les algorithmes post-quantiques standardisés depuis 2024 doivent enfin fonctionner dans de vrais navigateurs, de vraies infrastructures, avec de vrais utilisateurs.
Ce que Microsoft et DigiCert ont annoncé le 17 septembre
Le pilote TLS post-quantique de Microsoft s’appuie sur le Trusted Root Program, le mécanisme qui décide quelles autorités de certification racines sont reconnues par Windows et par les applications Microsoft. Un porte-parole de Microsoft cité dans la couverture de SiliconANGLE, identifié sous le nom de Goodley, a présenté le test comme un moyen pour les autorités de certification de vérifier l’émission et la compatibilité de leurs certificats avec les capacités de la plateforme Microsoft, dans un environnement contrôlé. La source précise que ce pilote se déroule explicitement en dehors des scénarios de production et de confiance publique (SiliconANGLE, 17 septembre 2026).
DigiCert a publié sa propre politique de certification pour ce pilote, la TLS PQC Pilot Certificate Policy and Practices, entrée en vigueur le 18 septembre 2026. Le document est sans ambiguïté sur le périmètre : les certificats émis dans ce cadre visent des environnements de test fermés, des applications personnalisées et des bancs d’essai internes aux entreprises. Le but affiché est d’évaluer l’impact de la cryptographie post-quantique dans ces environnements, pas d’établir une norme pour les connexions web accessibles au public (politique DigiCert TLS PQC Pilot, 18 septembre 2026). La hiérarchie de certification créée pour l’occasion est temporaire : à la clôture du pilote, Microsoft retirera le certificat concerné de sa liste de confiance (CTL) du Trusted Root Program, et il cessera d’être traité comme une racine de confiance normale.
Un billet du blog DigiCert consacré aux discussions du CA/Browser Forum de Varsovie résume l’annonce de façon plus directe : lors de cette réunion, Microsoft a fait savoir qu’il lançait un programme pilote pour prendre en charge des racines ML-DSA pour TLS dans son Trusted Root Program (blog DigiCert, CA/Browser Forum Warsaw). C’est la première confirmation publique que Microsoft teste, concrètement, des racines de certification signées avec un algorithme post-quantique plutôt qu’avec RSA ou ECDSA, un domaine où DigiCert a déjà connu des incidents de sécurité par le passé sur ses certificats classiques.
Un pilote volontairement tenu à l’écart de la production
Ce choix de rester hors production mérite qu’on s’y arrête, car il dit beaucoup de l’état réel de préparation de l’industrie. Contrairement à l’échange de clés hybride ML-KEM, déjà activé par défaut dans Chrome depuis la version 124 en avril 2024 et qui représente aujourd’hui plus de 30 % des connexions TLS 1.3 mondiales selon les données Cloudflare Radar citées début 2026, la signature de certificats avec ML-DSA reste un terrain miné. Les navigateurs, les systèmes d’exploitation, les pare-feux, les équilibreurs de charge et les middleboxes n’ont pas tous été conçus pour accepter des chaînes de certificats plusieurs fois plus volumineuses que la norme actuelle.
Un test grandeur nature dans le web public exposerait donc des millions d’utilisateurs à des pannes de connexion, des échecs de négociation TLS ou des blocages silencieux par des équipements réseau incapables de traiter des poignées de main plus lourdes. En cantonnant le pilote à des environnements fermés, testbeds d’entreprise et applications personnalisées, Microsoft et DigiCert isolent le risque tout en collectant des données réelles sur l’interopérabilité entre logiciels PKI concurrents.
ML-KEM, ML-DSA, hybride X25519MLKEM768 : ce que teste réellement le pilote
Le pilote couvre deux briques distinctes de la cryptographie post-quantique, et il faut les distinguer clairement. La première concerne l’échange de clés, c’est-à-dire la manière dont un client et un serveur négocient une clé de session partagée au début d’une connexion TLS. Elle repose sur ML-KEM, le mécanisme d’encapsulation de clés standardisé par le NIST sous la référence FIPS 203. Dans le pilote comme dans la plupart des déploiements actuels, ML-KEM est utilisé en mode hybride, combiné à l’algorithme classique X25519 sous la forme X25519MLKEM768, identifiée par le point de code 0x11EC dans les spécifications IETF. Oracle a suivi la même logique dans Java 27, sorti le 15 septembre 2026, en intégrant cet échange hybride par défaut pour TLS 1.3. Ce choix hybride garantit qu’une connexion reste protégée par la cryptographie classique même si une faiblesse imprévue venait à affecter ML-KEM.
La seconde brique, bien plus sensible, concerne la signature des certificats eux-mêmes. C’est ML-DSA, standardisé sous FIPS 204, qui entre en jeu. Le RFC 9881 définit comment encoder une signature ML-DSA dans un certificat X.509 classique, et Cloudflare accepte déjà ce format pour les connexions vers les serveurs d’origine de ses clients. Signer une clé de session avec un algorithme hybride est une chose. Faire reconnaître par tout un écosystème de logiciels PKI une chaîne de certificats entièrement post-quantique en est une autre. C’est précisément ce que le pilote Microsoft-DigiCert cherche à valider : que les autorités de certification, les navigateurs de test et les applications personnalisées puissent émettre, transmettre et vérifier ces chaînes sans rupture.
Un échange de clés post-quantique protège la session. Il ne rend pas pour autant le certificat du serveur résistant à l’ordinateur quantique : un site peut très bien utiliser une négociation hybride ML-KEM tout en présentant encore un certificat RSA ou ECDSA classique. C’est cette distinction, souvent floue dans les discours marketing, que le pilote de septembre 2026 tente de clarifier en conditions réelles.
Sept autorités de certification, une politique commune
Selon les propos de Goodley rapportés par SiliconANGLE, DigiCert fait partie d’un groupe de sept autorités de certification engagées dans ce pilote. Les six autres noms n’ont pas été détaillés publiquement à ce stade, mais la structure du programme donne une indication claire : chaque autorité doit se conformer à une politique de certification et de pratiques commune, celle publiée par DigiCert, pour que les tests d’interopérabilité aient un sens comparatif. Sans référentiel partagé, chaque autorité produirait des certificats post-quantiques incompatibles entre eux, ce qui viderait le pilote de son intérêt.
Ce choix de mutualiser sept autorités plutôt que de laisser DigiCert opérer seule reflète aussi une réalité du marché des certificats : Microsoft doit convaincre l’ensemble de la chaîne de confiance, pas un seul fournisseur, avant d’envisager une bascule vers la production. Un test isolé ne prouverait rien sur la capacité du reste de l’écosystème à suivre.
Le vrai problème : des certificats trop lourds pour le web public
La difficulté technique centrale tient à la taille. Une estimation reprise par le site spécialisé postquantum.com situe un certificat ML-DSA encodé en X.509 à environ 14 700 octets, contre environ 736 octets pour un certificat conçu selon le modèle alternatif des Merkle Tree Certificates, proposé par Google et Cloudflare (postquantum.com, février 2026). L’écart, de l’ordre de vingt fois, illustre pourquoi une chaîne complète de certificats post-quantiques, avec plusieurs certificats intermédiaires, peut rapidement dépasser les limites de taille de poignée de main tolérées par certains équipements réseau, provoquer une fragmentation TCP supplémentaire ou se heurter à des limites strictes de longueur de chaîne dans d’anciennes bibliothèques TLS.
| Format de certificat | Taille approximative | Algorithme de signature | Statut fin septembre 2026 |
|---|---|---|---|
| Certificat X.509 avec ML-DSA | ≈ 14 700 octets | ML-DSA (FIPS 204) | Testé en pilote fermé Microsoft-DigiCert |
| Merkle Tree Certificate (MTC) | ≈ 736 octets | Preuves d’inclusion par hachage compact | En cours de standardisation IETF (groupe PLANTS) |
| Poignée de main hybride ML-KEM | Clé publique ML-KEM-768 ajoutée à l’échange X25519 | X25519MLKEM768 (échange de clés, pas signature) | Disponibilité générale chez Cloudflare, Chrome, Oracle Java 27 |
C’est cet écart de poids qui explique pourquoi Google et Cloudflare ont développé conjointement, via le groupe de travail PLANTS nouvellement formé à l’IETF, une architecture alternative pour l’authentification post-quantique du web public. Les Merkle Tree Certificates remplacent les signatures individuelles par certificat par des preuves d’inclusion compactes issues d’un arbre de hachage, et intègrent directement la transparence des certificats dans le processus d’émission. L’approche est présentée comme mieux adaptée au Chrome Root Store public, tandis que les certificats post-quantiques classiques, plus lourds, resteraient davantage réservés aux infrastructures à clé publique privées, comme celles d’entreprise.
Le calendrier resserré de l’automne 2026
Le pilote Microsoft-DigiCert ne surgit pas dans le vide. Il s’inscrit dans une séquence de dates qui, mises bout à bout, dessinent une pression réglementaire et opérationnelle inhabituelle pour un seul mois.
| Date | Événement | Organisme concerné |
|---|---|---|
| Avril 2026 | Mise à jour des recommandations PQC : ML-KEM-768/1024 pour l’échange de clés, ML-DSA-65/87 pour les signatures | Groupe européen de certification en cybersécurité |
| 15 septembre 2026 | Sortie de Java 27, avec échange de clés hybride post-quantique pour TLS 1.3 | Oracle |
| 17 septembre 2026 | Révélation du pilote TLS post-quantique Trusted Root Program, lors de World Quantum Readiness Day | Microsoft / DigiCert |
| 18 septembre 2026 | Entrée en vigueur de la politique de certification du pilote TLS PQC | DigiCert |
| 21 septembre 2026 | Bascule de tous les certificats FIPS 140-2 encore actifs vers le statut « Historical » | NIST (programme CMVP) |
| Janvier 2027 | Entrée en vigueur du portail d’achat CNSA 2.0 imposant des algorithmes résistants au quantique pour les nouveaux systèmes de sécurité nationale | NSA (États-Unis) |
Cette concentration d’échéances en une seule semaine n’est pas une coïncidence de calendrier éditorial. Elle traduit un basculement réel : la cryptographie post-quantique cesse d’être un sujet de recherche pour devenir une contrainte d’achat, de conformité et d’ingénierie que les équipes sécurité doivent gérer dès maintenant, avec des dates fermes plutôt que des horizons vagues.
Cloudflare, Google, AWS : chacun avance à son rythme
Le positionnement de Microsoft prend tout son sens une fois comparé à ce que font ses concurrents directs. Cloudflare a été le premier grand acteur d’infrastructure à généraliser l’échange de clés hybride ML-KEM sur l’ensemble de son réseau périphérique, en environnement de production complète, avec en plus la prise en charge de ML-DSA pour l’authentification des serveurs d’origine via son mécanisme Authenticated Origin Pulls. Sa feuille de route publique, jugée particulièrement détaillée par les observateurs du secteur, prévoit une authentification d’origine post-quantique généralisée à la mi-2026 et des Merkle Tree Certificates à l’horizon mi-2027.
Amazon Web Services suit une trajectoire plus ciblée : le géant du cloud propose un TLS post-quantique hybride ML-KEM sur les points de terminaison non-FIPS de trois services précis, AWS KMS, AWS Certificate Manager et AWS Secrets Manager, dans les régions de la partition « aws ». L’approche reste focalisée sur des services managés critiques plutôt que sur l’ensemble du trafic de la plateforme.
Google, de son côté, porte le projet des Merkle Tree Certificates aux côtés de Cloudflare, plutôt que de suivre la voie des certificats ML-DSA classiques pour le Chrome Root Store public. C’est une divergence stratégique notable face à Microsoft : là où le Trusted Root Program teste directement des racines ML-DSA, l’écosystème Chrome mise sur une architecture différente, jugée mieux taillée pour le volume et la latence du web public.
| Fournisseur | Échange de clés (ML-KEM) | Signature de certificats (ML-DSA) | Statut de déploiement |
|---|---|---|---|
| Cloudflare | X25519MLKEM768 sur tout le trafic périphérique | ML-DSA pour Authenticated Origin Pulls | Disponibilité générale |
| AWS | Hybride ML-KEM sur KMS, ACM, Secrets Manager (endpoints non-FIPS) | Non généralisé | Déploiement ciblé par service |
| Google / Chrome | X25519MLKEM768 par défaut depuis la version 124 (avril 2024) | Merkle Tree Certificates en développement (IETF PLANTS) | Production pour l’échange de clés, R&D pour les certificats |
| Oracle (Java 27) | Échange de clés hybride pour TLS 1.3 | Non précisé dans l’annonce | Disponible depuis le 15 septembre 2026 |
| Microsoft (Trusted Root Program) | Testé dans le pilote | Racines ML-DSA testées en pilote fermé | Pilote hors production, 7 autorités de certification |
Ce tableau dessine une carte à deux vitesses. L’échange de clés post-quantique est déjà un acquis technique largement industrialisé. La signature post-quantique des certificats, elle, reste au stade du pilote contrôlé chez la plupart des grands acteurs, à l’exception de l’usage ciblé que Cloudflare en fait déjà pour ses connexions d’origine.
Huit ans de standardisation, un contexte historique qui explique la prudence
Pour comprendre pourquoi Microsoft avance avec autant de précaution, il faut revenir sur le calendrier du NIST. Le processus de standardisation qui a produit FIPS 203 pour ML-KEM, FIPS 204 pour ML-DSA et FIPS 205 pour SLH-DSA a duré huit ans, entre le lancement de l’appel à candidatures et la publication finale des standards en 2024. Cette durée reflète l’ampleur du changement : remplacer RSA et les courbes elliptiques, utilisés depuis plus de vingt ans dans la quasi-totalité des connexions chiffrées du web, ne se fait pas en modifiant une simple ligne de configuration.
Windows 11 version 24H2 a déjà intégré ML-KEM et ML-DSA à l’interface cryptographique du système d’exploitation, mais les identifiants pour les signatures fondées sur le hachage, SLH-DSA, LMS et XMSS, n’y sont pas encore pris en charge de façon native selon les analyses publiées début septembre 2026. Cette intégration partielle, système d’exploitation par système d’exploitation, bibliothèque par bibliothèque, illustre pourquoi un pilote d’interopérabilité entre plusieurs éditeurs de logiciels PKI, plutôt qu’un simple déploiement unilatéral, s’imposait avant toute mise en production.
Ce que Microsoft et DigiCert affirment publiquement
Les prises de position publiques restent mesurées, presque prudentes dans leur formulation, ce qui contraste avec le ton parfois alarmiste d’autres communications sur la menace quantique. Selon Goodley, le porte-parole de Microsoft cité par SiliconANGLE, le pilote permet aux autorités de certification de tester l’émission et la compatibilité avec les capacités de la plateforme Microsoft dans un environnement contrôlé, sans exposer d’utilisateurs réels (source).
DigiCert va dans le même sens dans sa politique officielle publiée le 18 septembre : les certificats émis dans ce cadre sont réservés à des environnements de test fermés, des applications personnalisées et des bancs d’essai en entreprise, et leur but est d’évaluer l’impact de la cryptographie post-quantique sans chercher à établir une norme pour les connexions web publiques (source). Le blog DigiCert, en résumant les échanges du CA/Browser Forum de Varsovie, confirme que Microsoft a présenté ce programme pilote comme un moyen de prendre en charge des racines ML-DSA pour TLS au sein du Trusted Root Program (source).
Trois communications distinctes, trois formulations qui convergent vers le même message : il s’agit d’un test technique encadré, pas d’un lancement commercial déguisé. Cette cohérence de discours entre Microsoft et DigiCert contraste avec la communication plus offensive de Cloudflare sur ses propres chiffres de déploiement, ce qui reflète des postures d’entreprise différentes face à un même problème technique.
Impact sur le marché : coûts et calendrier pour les entreprises
Pour les responsables sécurité et les architectes PKI en entreprise, ce pilote a une valeur pratique immédiate, même s’ils n’y participent pas directement. Il donne un premier aperçu concret des frictions à anticiper avant une migration post-quantique interne : chaînes de certificats plus longues à transporter, temps de validation potentiellement allongés, compatibilité incertaine avec des équipements réseau plus anciens, et nécessité de tester les applications personnalisées avant tout basculement.
La bascule des certificats FIPS 140-2 vers le statut historique, effective depuis le 21 septembre 2026, ajoute une pression concrète sur les achats. Toute organisation qui vend des équipements ou des logiciels cryptographiques aux agences fédérales américaines doit désormais présenter une validation FIPS 140-3, sous peine de perdre l’éligibilité aux nouveaux marchés publics. Ce type de contrainte réglementaire, propre aux États-Unis dans son mécanisme, a l’habitude de se propager ensuite vers les cahiers des charges d’entreprises privées qui travaillent avec le secteur public, y compris en Europe.
L’échéance suivante, celle du portail d’achat CNSA 2.0 en janvier 2027 pour les systèmes de sécurité nationale américains, laisse aux équipementiers et fournisseurs de logiciels une fenêtre de quelques mois seulement pour valider leurs propres chaînes de certification post-quantique. Le pilote Trusted Root Program tombe donc à un moment où chaque semaine de test compte pour les fournisseurs qui espèrent rester éligibles à ces marchés.
L’Europe sous une pression réglementaire parallèle
Le calendrier américain ne dispense pas les entreprises européennes de leurs propres obligations. Le groupe européen de certification en cybersécurité a mis à jour ses recommandations en avril 2026, en fixant ML-KEM-768 ou 1024 pour l’échange de clés, et ML-DSA-65 ou 87 pour les signatures numériques, avec une fenêtre de migration fixée entre 2026 et 2027. Ces recommandations rejoignent les positions déjà connues de l’ANSSI en France, qui pousse vers une intégration progressive de la cryptographie post-quantique dans les certifications de sécurité des produits.
Pour les opérateurs d’importance vitale et les entités soumises au règlement européen sur la résilience cyber, la leçon du pilote Microsoft-DigiCert est directe : la partie échange de clés de la migration post-quantique est largement industrialisée et peut être activée rapidement, tandis que la partie certificats et infrastructure à clé publique demande des mois de test d’interopérabilité avant tout déploiement à grande échelle. Les équipes qui attendent une solution clé en main pour la partie PKI risquent de découvrir l’ampleur du chantier au moment où les délais réglementaires se resserreront.
Tester soi-même la compatibilité post-quantique d’une connexion TLS
Les équipes techniques qui veulent vérifier, dès aujourd’hui, si un serveur négocie déjà un échange de clés hybride post-quantique peuvent s’appuyer sur une version récente d’OpenSSL prenant en charge les groupes ML-KEM. La commande suivante interroge un serveur et affiche le groupe d’échange de clés utilisé pendant la poignée de main :
openssl s_client -connect exemple.fr:443 -groups X25519MLKEM768 -tls1_3 2>/dev/null | grep -i "Server Temp Key\|Negotiated"Si la sortie mentionne X25519MLKEM768, le serveur accepte déjà l’échange de clés hybride post-quantique. L’absence de cette mention ne signifie pas forcément que le serveur est vulnérable dès aujourd’hui : elle indique seulement qu’il n’a pas encore activé cette option, souvent disponible côté serveur mais désactivée par défaut sur de nombreuses configurations encore en 2026.
Cinq évolutions à surveiller d’ici 2027
- Le nombre d’autorités de certification participant à des pilotes d’interopérabilité post-quantique devrait dépasser la dizaine avant la fin de 2026, sous l’effet combiné de la pression CNSA 2.0 et des recommandations européennes d’avril 2026.
- La bascule FIPS 140-2 vers FIPS 140-3, effective depuis le 21 septembre 2026, va probablement pousser plusieurs fournisseurs de modules cryptographiques à accélérer leurs demandes de validation FIPS 140-3 dans les prochains mois pour ne pas perdre l’accès aux marchés fédéraux américains.
- Les Merkle Tree Certificates, actuellement en discussion au sein du groupe de travail IETF PLANTS, ont une feuille de route publique chez Cloudflare qui vise une disponibilité vers la mi-2027 : leur progression sera un indicateur clé de la viabilité d’une alternative plus légère aux certificats ML-DSA classiques pour le web public.
- Le fossé entre l’adoption massive de l’échange de clés hybride ML-KEM, déjà proche d’un tiers du trafic TLS 1.3 mondial début 2026 selon Cloudflare Radar, et l’adoption encore embryonnaire des certificats post-quantiques signés devrait continuer à se creuser avant de se refermer progressivement.
- Les entreprises européennes soumises au Cyber Resilience Act et aux recommandations ANSSI vont vraisemblablement multiplier leurs propres tests internes d’interopérabilité PKI post-quantique au cours du premier semestre 2027, en s’inspirant directement de la méthodologie du pilote Microsoft-DigiCert.
Questions fréquentes
Le pilote TLS post-quantique de Microsoft est-il accessible au grand public ?
Non. Microsoft et DigiCert ont explicitement limité ce pilote à des environnements de test fermés, des applications personnalisées et des bancs d’essai en entreprise. Aucun site web public ne présente aujourd’hui un certificat émis dans le cadre de ce programme, et la hiérarchie de certification créée pour l’occasion sera retirée de la liste de confiance de Microsoft à la fin du test.
Quelle est la différence entre ML-KEM et ML-DSA ?
ML-KEM, standardisé sous FIPS 203, sert à l’échange de clés pendant la négociation d’une connexion TLS, et protège la confidentialité de la session. ML-DSA, standardisé sous FIPS 204, sert à signer des certificats et des documents, et garantit l’authenticité d’un serveur ou d’un émetteur. Un serveur peut utiliser l’un sans l’autre, ce qui explique pourquoi l’échange de clés post-quantique progresse plus vite que les certificats post-quantiques.
Pourquoi les certificats ML-DSA posent-ils problème sur le web public ?
Leur taille, estimée à environ 14 700 octets contre environ 736 octets pour un Merkle Tree Certificate, alourdit considérablement la chaîne de certification. Cela peut provoquer des échecs de poignée de main sur des équipements réseau anciens, une fragmentation TCP supplémentaire, ou dépasser des limites de taille imposées par certaines bibliothèques TLS qui n’ont pas été conçues pour ce volume de données.
Combien d’autorités de certification participent au pilote ?
Sept autorités de certification participent au pilote, DigiCert étant la seule nommée publiquement à ce stade selon les propos rapportés par SiliconANGLE. Les six autres n’ont pas été identifiées dans les communications publiques disponibles fin septembre 2026.
Qu’est-ce que la bascule FIPS 140-2 du 21 septembre 2026 change concrètement ?
Depuis cette date, tous les certificats de validation FIPS 140-2 encore actifs sont passés au statut « Historical » dans le programme de validation cryptographique du NIST. Seuls les modules validés FIPS 140-3 restent éligibles pour de nouveaux achats par les agences fédérales américaines, ce qui pousse les fournisseurs de matériel et de logiciels cryptographiques à accélérer leurs demandes de validation.
Les entreprises européennes doivent-elles se préoccuper de ce pilote ?
Indirectement, oui. Les recommandations du groupe européen de certification en cybersécurité, mises à jour en avril 2026, fixent une fenêtre de migration post-quantique entre 2026 et 2027 pour ML-KEM et ML-DSA. Les résultats du pilote Microsoft-DigiCert, une fois publiés, donneront des indications concrètes sur les difficultés d’interopérabilité que les entreprises européennes devront elles aussi anticiper.
Qu’est-ce qu’un Merkle Tree Certificate et remplace-t-il ML-DSA ?
Il s’agit d’une architecture alternative, développée par Google et Cloudflare et en cours de standardisation au sein du groupe de travail IETF PLANTS, qui remplace les signatures individuelles par certificat par des preuves d’inclusion compactes issues d’un arbre de hachage. Elle ne remplace pas ML-DSA à proprement parler, mais propose une méthode différente, plus légère, pour authentifier des certificats dans un contexte post-quantique, mieux adaptée selon ses concepteurs au volume du web public.
