Pendant des années, le risque quantique relevait du futur. Le message adressé aux équipes de sécurité était le suivant : « Le quantique arrivera un jour », mais ce « jour » ne figurait jamais sur aucun calendrier. La donne a changé. La préparation à l’ère post-quantique n’est plus un simple diaporama stratégique évoquant une menace lointaine. Il s’agit désormais d’un ensemble d’obligations assorties de dates butoirs, et pour les fournisseurs de services d’ software s et de technologies de l’information, ces échéances se profilent désormais simultanément de deux côtés.
Trois étapes clés viennent concrétiser cette évolution. Le 21 septembre 2026, le régime de validation FIPS 140-2 arrivera à échéance. Le 1er janvier 2027, l’Agence nationale de sécurité (NSA) prévoit que les nouvelles acquisitions relevant du Système de sécurité nationale (NSS) soient, par défaut, conformes à la norme CNSA 2.0. Enfin, le 22 juin 2026, le décret 14412 a fixé au 31 décembre 2030 la mise en place de clés post-quantiques et au 31 décembre 2031 celle des signatures post-quantiques sur les systèmes fédéraux à haute valeur et à fort impact, et a imposé une règle du FAR exigeant que les sous-traitants concernés se conforment aux normes FIPS intégrant la PQC d’ici le 31 décembre 2030. Si vous développez, signez ou fournissez des solutions de gestion de clés ( software), ces deux dates s’inscrivent dans votre feuille de route. La question n’est plus de savoir s’il faut agir, mais si vous allez vous y mettre avant que les échéances ne vous y obligent.
Les deux calendriers que tous les fournisseurs d’ software s doivent désormais respecter
La migration post-quantique est souvent décrite comme une transition unique. Dans la pratique, les fournisseurs d’ software s se retrouvent confrontés à deux voies distinctes, avec des responsables, des algorithmes et des échéances différents. L’une relève du domaine civil et a une portée générale. L’autre concerne la sécurité nationale et est menée de manière proactive. Comprendre ces deux aspects constitue la première étape vers l’élaboration d’un plan défendable.
Le volet civil : NIST IR 8547 et les normes définitives
La voie civile passe par le NIST. En août 2024, le NIST a finalisé ses premières normes post-quantiques : la norme FIPS 203 (ML-KEM) pour l'établissement de clés, la norme FIPS 204 (ML-DSA) pour les signatures à usage général et la norme FIPS 205 (SLH-DSA) pour les signatures basées sur des fonctions de hachage. Il s'agit d'algorithmes prêts à être mis en production, et non de propositions de recherche.
Ces dates proviennent d’un document d’accompagnement. Le document NIST IR 8547, intitulé « Transition vers les normes de cryptographie post-quantique », définit le calendrier de retrait des algorithmes à clé publique actuels. Conformément à ce plan, les algorithmes RSA, ECDSA, EdDSA, ainsi que les algorithmes de Diffie-Hellman sur corps fini et sur courbe elliptique au niveau de sécurité de 112 bits seront dépréciés après 2030, puis interdits en 2035. Ce calendrier s’applique de manière générale à l’ensemble des systèmes fédéraux et aux fournisseurs qui les desservent. Le décret présidentiel n° 14412 et le mémorandum M-26-15 de l’OMB précisent désormais les dates d’entrée en vigueur pour le secteur civil. Le mémorandum M-26-15 définit un calendrier de migration en cinq phases s’étalant de 2026 à 2035 et exige que les agences élaborent des plans de migration.
Le volet « sécurité nationale » : CNSA 2.0
Le parcours en matière de sécurité nationale est plus exigeant. La suite d’algorithmes commerciaux de sécurité nationale 2.0 (CNSA 2.0) de la NSA, dont la version 2.1 a été publiée en décembre 2024, fixe des échéances catégorie par catégorie pour le NSS. La date la plus importante pour les fournisseurs est le 1er janvier 2027, date à laquelle les nouvelles acquisitions NSS devront, par défaut, être conformes à la norme CNSA 2.0. La norme CNSSP 15 définit cette exigence d’acquisition au 1er janvier 2027. Les équipements et services non compatibles avec la CNSA 2.0 devront être progressivement retirés d’ici le 31 décembre 2030, et l’utilisation des algorithmes de la CNSA 2.0 sera obligatoire à compter du 31 décembre 2031.
La norme CNSA 2.0 est également plus restrictive quant aux solutions qu’elle approuve. Elle autorise les solutions ML-KEM et ML-DSA, mais la solution SLH-DSA n’est approuvée pour aucune utilisation dans les systèmes de sécurité nationale. La norme CNSSP 15 a été mise à jour pour intégrer la norme CNSA 2.0 ; le NIAP valide les produits par rapport aux profils de protection publiés, et les solutions CSfC sont enregistrées conformément aux « Capability Packages » de la NSA. Si vous vendez vos produits à des agences fédérales ou à la base industrielle de défense, cette voie définit vos exigences à court terme.
La tâche la plus concrète à court terme : votre pipeline de signatures
Pour les fournisseurs d’ software s, l’obligation de signature constitue l’engagement à court terme le plus concret. Les signatures de micrologiciels et d’ software s ont une longue durée de vie, sont difficiles à réémettre sur le terrain et constituent précisément ce qu’un attaquant chercherait à falsifier. C’est donc par là que commence concrètement la préparation à l’ère post-quantique.
La signature nécessite également la prise en charge de nouveaux algorithmes, et pas seulement des clés plus longues. La norme CNSA 2.0 spécifie des schémas basés sur des fonctions de hachage avec état, LMS ou XMSS tels que définis dans la spécification NIST SP 800-208, pour la signature d’ software s et de micrologiciels. Ceux-ci se distinguent du ML-DSA à usage général et comportent leurs propres exigences en matière de gestion d’état. Un pipeline de signature reposant uniquement sur des clés RSA ou ECDSA plus longues ne satisfait pas à cette exigence. Il nécessite des algorithmes résistants à l'informatique quantique, correctement implémentés.
Le goulot d'étranglement du CMVP : deux barres, une file d'attente
Derrière le problème algorithmique se cache un problème logistique. La validation post-quantique n'arrive pas sur une piste déserte. Elle entre en conflit avec le passage habituel de la norme FIPS 140-2 à la norme FIPS 140-3 ; ainsi, une file d'attente de validation déjà surchargée doit désormais franchir deux étapes en même temps.
Les délais sont impitoyables. Les validations FIPS 140-3 ont duré en moyenne environ 18 mois, et la file d’attente s’est allongée depuis ; il faut donc prévoir un délai réaliste compris entre 18 et 30 mois. En août 2026, les modules PQC se trouvaient dans la file d’attente du CMVP, plusieurs fournisseurs visant l’obtention de leurs certificats à partir de fin 2026.
La fin de validité de la norme FIPS 140-2 accentue la pression. Le 21 septembre 2026, les certificats FIPS 140-2 encore en vigueur seront transférés vers la liste historique du CMVP. Les déploiements existants pourront continuer à fonctionner, mais les agences fédérales ne devront plus inclure de modules historiques dans leurs nouveaux marchés publics. Une même demande doit souvent satisfaire aux deux critères, c’est pourquoi il est plus important qu’il n’y paraît de s’inscrire tôt dans la file d’attente.
Récolter maintenant, décrypter plus tard : pourquoi attendre, c'est déjà prendre une décision
L'argument le plus convaincant en faveur d'une action immédiate n'a rien à voir avec la date à laquelle un ordinateur quantique opérationnel verra le jour. Il s'agit du problème dit « récolter maintenant, décrypter plus tard ». Un adversaire peut intercepter aujourd'hui du trafic chiffré et le stocker, puis le décrypter dès qu'un ordinateur quantique suffisamment puissant sur le plan cryptographique existera.
Cela recadre le délai en fonction de la sensibilité des données, et non de l’ hardware. Si votre produit protège des informations qui doivent rester confidentielles pendant plus de 10 à 15 ans, ces données peuvent être considérées comme déjà exposées. Attendre n’est pas une position neutre. C’est une décision d’accepter cette exposition, et vos clients vous demanderont de plus en plus souvent de la justifier.
Ce qu'implique réellement une migration contrôlée
Une migration pilotée repose sur quatre capacités qu’un fournisseur de services « software » doit mettre en place. Répondre à chacune de ces questions de préparation nécessite un contrôle opérationnel, et non un projet ponctuel. Voici ce qu’exige chacune d’entre elles.
Établir un inventaire cryptographique complet
On ne peut pas migrer ce qu’on ne voit pas. Un inventaire complet recense tous les certificats, clés, algorithmes et bibliothèques présents dans vos produits, vos pipelines de compilation et vos environnements cloud. Il est essentiel qu’il inclue les dépendances héritées open-source , car la cryptographie que vous n’avez pas écrite n’en reste pas moins de la cryptographie que vous distribuez.
Claser les actifs vulnérables aux attaques quantiques en fonction de leur sensibilité et de leur durée de vie
Tous les actifs ne présentent pas le même degré d'urgence. Une fois identifiés, les actifs vulnérables aux attaques quantiques doivent être classés selon le calendrier de mise hors service défini par la norme NIST IR 8547 et en fonction de la durée de conservation requise pour leurs données ou leur niveau de confiance. Cette classification permet de transformer une simple liste en un ordre de migration hiérarchisé.
Assurer la flexibilité des certificats et des clés à l'échelle du parc
La migration ne se résume pas à une simple bascule. Vous devez pouvoir effectuer des rotations, réémettre et régénérer des clés à grande échelle, mais aussi délivrer des certificats compatibles PQC et hybrides pour une transition progressive. C'est grâce à cette agilité cryptographique que vous pouvez évoluer sans interrompre la production, puis vous adapter à nouveau lorsque les normes évoluent.
Évaluer la situation des fournisseurs et des dépendances
Votre vulnérabilité ne se limite pas à votre propre code. Il est important d'évaluer la posture des fournisseurs et des dépendances en matière de cryptographie post-quantique (PQC), car la cryptographie héritée devient votre vulnérabilité dès que vous l'intégrez. Un fournisseur qui néglige sa chaîne d'approvisionnement hérite de toutes les failles qui s'y trouvent.
Comment Keyfactor vous aider
Ces quatre capacités correspondent directement à la plateforme Keyfactor ; ainsi, les questions de préparation évoquées ci-dessus se transforment en contrôles opérationnels plutôt qu’en risques potentiels.
- Inventaire cryptographique et évaluation des vulnérabilités. Keyfactor AgileSec recense les ressources cryptographiques présentes dans les produits, les pipelines de compilation et l'infrastructure cloud, puis facilite l'évaluation des vulnérabilités quantiques afin que vous puissiez établir vos priorités.
- Émission de certificats compatibles PQC et hybrides. EJBCA Émet des certificats à l'aide d'algorithmes PQC normalisés par le NIST, y compris des certificats hybrides prenant en charge une migration progressive.
- Agilité cryptographique à l'échelle d'un parc informatique. Keyfactor Command Automatise la gestion du cycle de vie des certificats et des clés, permettant ainsi la rotation et le renouvellement des clés à grande échelle sans intervention manuelle sur chaque terminal.
- Signature résistante à l'informatique quantique. Keyfactor SignServer et Keyfactor Signum prise en charge de la signature d’ software s et de micrologiciels, y compris les schémas LMS et XMSS requis par CNSA 2.0.
Ensemble, ces produits constituent le « Trust Control Plane » d’ Keyfactor: un système de référence unique qui surveille, analyse, provisionne, orchestre et gère les actifs cryptographiques. Plutôt que de devoir rechercher des certificats dans des outils disparates, les équipes de sécurité gèrent la confiance comme une opération unique et continue. C’est précisément ce qu’exige le suivi de la validation FIPS 140-3 des algorithmes PQC, ainsi que de tous les autres éléments figurant sur ces calendriers.
La préparation à l'ère post-quantique est un programme, et non un projet
Ces deux échéances sont fixes, mais le travail qui les sous-tend ne s'arrête pas une fois la date passée. Les normes évolueront, des algorithmes seront ajoutés puis retirés, et votre empreinte cryptographique ne cessera de changer. La préparation à l'ère post-quantique est une capacité opérationnelle que vous devez maintenir en permanence, et non une étape que l'on peut simplement cocher comme accomplie.
Concrètement, il convient de commencer dès maintenant par les deux tâches qui prennent le plus de temps. Dressez l'inventaire de vos éléments cryptographiques afin de savoir exactement ce que vous migrez, et inscrivez vos modules dès que possible dans la file d'attente de validation pour éviter que le goulot d'étranglement lié au CMVP ne détermine votre date de livraison. Les fournisseurs qui agiront en amont des échéances les considéreront comme une simple formalité. Ceux qui attendront les verront comme des situations d'urgence.
Prêt à faire le point sur votre situation ? Demander une démo pour dresser l'inventaire de vos solutions cryptographiques et définir votre parcours vers la sécurité quantique.
Vous vous posez des questions sur la préparation à l'ère post-quantique ? Nous avons les réponses.
Qu'entend-on par « préparation à l'ère post-quantique » pour un fournisseur de solutions « software » ?
Il s'agit de la capacité permanente à identifier, classer et faire évoluer les systèmes cryptographiques vers des normes résistantes à l'attaque quantique. Pour les fournisseurs, cela concerne principalement les pipelines de signature, l'émission de certificats et les modules validés. Il s'agit d'une capacité opérationnelle, et non d'une mise à niveau ponctuelle.
Quelles sont les principales échéances en matière de sécurité post-quantique ?
Deux dates sont particulièrement importantes. Les validations FIPS 140-2 seront transférées vers la liste historique du CMVP le 21 septembre 2026, et les nouvelles acquisitions NSS devront être conformes à la norme CNSA 2.0 par défaut à compter du 1er janvier 2027. Le document NIST IR 8547, qui n’en est encore qu’à l’état d’avant-projet public, propose la dépréciation après 2030 et l’interdiction après 2035. Le décret présidentiel (EO) 14412 fixe au 31 décembre 2030 la date limite pour l’établissement des clés et au 31 décembre 2031 celle pour les signatures numériques sur les systèmes fédéraux à forte valeur et à fort impact.
Quels algorithmes post-quantiques le NIST a-t-il validés ?
Le NIST a validé trois normes en août 2024 : la norme FIPS 203 (ML-KEM) pour l'établissement de clés, la norme FIPS 204 (ML-DSA) pour les signatures et la norme FIPS 205 (SLH-DSA) pour les signatures basées sur des fonctions de hachage. Parmi ces trois normes, la CNSA 2.0 inclut ML-KEM et ML-DSA. Elle approuve également les algorithmes LMS et XMSS issus de la spécification SP 800-208 pour la signature des micrologiciels et des fichiers « software », mais n’approuve pas l’utilisation de SLH-DSA dans le cadre du NSS.
Pourquoi la signature « software » est-elle la priorité numéro un ?
Les signatures ont une longue durée de vie et sont difficiles à réémettre une fois déployées. La norme CNSA 2.0 valide les normes ML-DSA-87, LMS et XMSS pour la signature des micrologiciels et des fichiers « software ». Les clés RSA ou ECDSA plus longues ne répondent à aucune de ces exigences. La signature constitue donc l'obligation la plus concrète à court terme.
En quoi consiste le goulot d'étranglement du CMVP ?
La validation post-quantique chevauche la transition habituelle vers la norme FIPS 140-3, ce qui engendre une file d'attente très chargée. La durée moyenne des validations est d'environ 18 mois ; il est donc réaliste de prévoir un délai compris entre 18 et 30 mois. Pour respecter votre calendrier, le mieux est de déposer votre demande le plus tôt possible.
Que signifie « harvest-now-decrypt-later » pour mon produit ?
Les pirates peuvent capturer aujourd’hui des données chiffrées et les déchiffrer dès que les ordinateurs quantiques auront atteint leur maturité. Si votre produit protège des données qui doivent rester confidentielles pendant plus de 10 à 15 ans, ces données sont déjà exposées. Attendre pour migrer revient en fait à accepter ce risque.
Comment lancer une migration post-quantique ?
Commencez par dresserun inventaire cryptographique complet de l'ensemble de vos produits, pipelines et dépendances. Classez les actifs en fonction de leur niveau de sensibilité et de leur durée de vie selon le barème NIST IR 8547, puis mettez en place les moyens nécessaires pour assurer une rotation et un renouvellement à grande échelle. Évaluez vos fournisseurs, car la cryptographie héritée devient un facteur de risque pour votre entreprise.
Comment Keyfactor contribue-t-il à la préparation à l'ère post-quantique ?
Keyfactor AgileSec gère la découverte et l'évaluation des vulnérabilités quantiques, EJBCA émet des certificats PQC et hybrides, et Keyfactor Command automatise le cycle de vie à grande échelle. SignServer et Signum prennent en charge la signature résistante à l'attaque quantique, le tout unifié au sein du Trust Control Plane.
