Préparation à l'ère post-quantique pour les fournisseurs d'Software s : le calendrier est désormais établi

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.

What is post-quantum readiness for a software vendor?
It is the ongoing ability to discover, classify, and migrate cryptography to quantum-safe standards. For vendors, it centers on signing pipelines, certificate issuance, and validated modules. It is an operating capability, not a one-time upgrade.

When are the key post-quantum deadlines?
Two dates matter most. FIPS 140-2 validations move to the CMVP Historical list on September 21, 2026, and new NSS acquisitions are expected to be CNSA 2.0-compliant by default from January 1, 2027.  NIST IR 8547, still an initial public draft, proposes deprecation after 2030 and disallowance after 2035. EO 14412 sets December 31, 2030 for key establishment and December 31, 2031 for digital signatures on federal high-value and high-impact systems.

Which post-quantum algorithms did NIST finalize?
NIST finalized three standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for signatures, and FIPS 205 (SLH-DSA) for hash-based signatures.  Of those three, CNSA 2.0 includes ML-KEM and ML-DSA. It also approves LMS and XMSS from SP 800-208 for firmware and software signing, and does not approve SLH-DSA for any use in NSS.

Why is software signing the first priority?
Signatures have long lifetimes and are hard to re-issue once deployed.  CNSA 2.0 approves ML-DSA-87 as well as LMS and XMSS for firmware and software signing. Larger RSA or ECDSA keys satisfy none of these. That makes signing the most concrete near-term obligation.

What is the CMVP bottleneck?
Post-quantum validation overlaps with the ordinary FIPS 140-3 transition, creating one crowded queue. Validations have averaged roughly 18 months, so 18 to 30 months is a realistic planning range. Submitting early is the main way to protect your timeline.

What does harvest-now-decrypt-later mean for my product?
Attackers can capture encrypted data today and decrypt it once quantum computers mature. If your product protects data that must stay confidential beyond 10 to 15 years, that data is already exposed. Waiting to migrate is effectively accepting that risk.

How do I start a post-quantum migration?
Begin with a complete cryptographic inventory across products, pipelines, and dependencies. Classify assets by sensitivity and lifespan against the NIST IR 8547 schedule, then build agility to rotate and reissue at scale. Assess your suppliers, since inherited cryptography becomes your exposure.

How does Keyfactor support post-quantum readiness?
Keyfactor AgileSec handles discovery and quantum-vulnerability assessment, EJBCA issues PQC and hybrid certificates, and Keyfactor Command automates lifecycle at scale. SignServer and Signum support quantum-safe signing, all unified in the Trust Control Plane.