Calendrier CNSA 2.0 : algorithmes et échéances expliqués

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) est l'ensemble d'algorithmes post-quantiques que la NSA impose aux National Security Systems (NSS) américains et aux produits commerciaux qui y sont utilisés. La suite comprend ML-KEM-1024 pour l'établissement de clés, ML-DSA-87 pour les signatures à usage général, LMS et XMSS pour la signature de logiciels et de micrologiciels, AES-256 pour le chiffrement symétrique, et SHA-384 ou SHA-512 pour le hachage. L'usage exclusif est exigé d'ici fin 2030 pour la signature de logiciels et de micrologiciels ainsi que pour les équipements réseau traditionnels, et d'ici fin 2033 pour les navigateurs et serveurs web, les services cloud, les systèmes d'exploitation et les équipements de niche.

À qui s'applique CNSA 2.0

CNSA 2.0 n'est pas une règle générale de cryptographie applicable aux États-Unis, et ce n'est pas une norme internationale. Elle régit les National Security Systems : les systèmes qui traitent des informations classifiées ou qui sont critiques pour les fonctions militaires et de renseignement. Elle concerne trois groupes d'acteurs. D'abord, les organisations qui possèdent et exploitent ces systèmes. Ensuite, les intégrateurs qui les construisent. Enfin, et c'est le groupe le plus souvent pris au dépourvu, les éditeurs et fabricants commerciaux dont les produits sont achetés pour ces systèmes.

Les agences fédérales civiles suivent une autre trajectoire. Leurs obligations découlent de l'Executive Order 14412 (22 juin 2026) et du mémorandum OMB M-26-15 (24 juin 2026), résumés sur notre page consacrée au post-quantique fédéral américain : inventaire cryptographique automatisé, plans de migration des agences attendus pour le 22 octobre 2026, TLS 1.3 exigé d'ici le 2 janvier 2030, systèmes à haute valeur en établissement de clés post-quantique d'ici fin 2030 et en signatures post-quantiques d'ici fin 2031, migration complète d'ici 2035 au titre de NSM-10. Les deux trajectoires vont dans le même sens, mais les dates et le périmètre diffèrent. Référez-vous à celle qui s'applique au contrat que vous avez sous les yeux. Les jalons datés de CNSA 2.0 sont rassemblés sur notre page de référence CNSA 2.0.

Cet article est fourni à titre d'information et ne constitue pas un conseil juridique. Les clauses d'achat d'un contrat donné prévalent toujours sur un résumé général.

La suite d'algorithmes

CNSA 2.0 ne se contente pas de dire post-quantique. Elle désigne des jeux de paramètres, et elle désigne les plus élevés.

Trois points méritent votre attention. ML-KEM est la forme normalisée de CRYSTALS-Kyber, publiée par le NIST sous la référence FIPS 203 le 13 août 2024, en même temps que FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA). Les groupes Kyber antérieurs à la norme, comme X25519Kyber768Draft00, sont obsolètes et ne satisfont aucune exigence. Ensuite, CNSA 2.0 demande les jeux de paramètres les plus élevés, ML-KEM-1024 et ML-DSA-87, et non le ML-KEM-768 que les navigateurs négocient aujourd'hui par défaut. Un produit qui ne prend en charge que X25519MLKEM768 est post-quantique, mais il n'est pas conforme à CNSA 2.0. Enfin, la suite renvoie à LMS et XMSS, définis dans SP 800-208, pour la signature des logiciels et des micrologiciels. Ces schémas sont à état : la clé de signature ne doit jamais réutiliser un index de clé à usage unique, si bien que l'infrastructure de signature doit garantir la persistance de l'état. SLH-DSA (FIPS 205) est sans état et ne figure pas dans la suite décrite ci-dessus.

AES-256 et la famille SHA-2 font partie de la suite parce que l'algorithme de Shor ne les casse pas. L'algorithme de Grover explique pourquoi AES-256 est préféré à AES-128 pour une protection à long terme, et pourquoi les tailles de hachage sont de 384 bits et plus.

Les échéances, catégorie par catégorie

CNSA 2.0 fixe des dates d'usage exclusif, ce qui est plus strict que la simple prise en charge. L'usage exclusif signifie que les algorithmes CNSA 2.0 sont les seuls utilisés pour la fonction concernée : RSA, ECDSA et ECDH disparaissent, ils ne sont pas simplement relégués au second plan. La prise en charge doit donc arriver bien avant l'échéance, car l'ensemble du parc doit être entièrement converti à cette date.

Ces dates proviennent de la FAQ CNSA 2.0 version 2.1 (décembre 2024) et de l'avis CNSA 2.0 Algorithms du 30 mai 2025. L'ordre est délibéré. La signature passe en premier parce qu'une racine de signature a une longue durée de vie : un micrologiciel signé aujourd'hui avec une clé ECDSA pourra encore être vérifié par des équipements sur le terrain dans dix ans, et la réémission d'une ancre de confiance sur un parc déployé est lente. Les équipements réseau passent en premier parce qu'ils terminent les tunnels chiffrés de longue durée, cible la plus attractive pour les attaques de type « récolter maintenant, déchiffrer plus tard » : le trafic enregistré n'est protégé que par l'échange de clés qui a produit ses clés de session, de sorte qu'une capture réalisée aujourd'hui peut devenir du texte en clair demain. Les navigateurs, serveurs, plateformes cloud et systèmes d'exploitation disposent d'un délai jusqu'en 2033 parce que la chaîne de dépendances sous-jacente (bibliothèques, modules matériels de sécurité, autorités de certification, piles protocolaires) est plus profonde.

Pourquoi les fournisseurs hors des États-Unis sont concernés

Trois raisons, aucune n'est théorique.

• Les clauses d'achat se propagent. Les exigences CNSA 2.0 sont inscrites dans les contrats et dans les appels d'offres. Un fournisseur de composants situé deux ou trois rangs plus bas dans une chaîne d'approvisionnement de défense en hérite par l'intermédiaire de son client, et non de son propre régulateur.
• Les jeux de paramètres élevés relèvent d'une décision produit, pas d'une option de configuration. ML-KEM-1024 et ML-DSA-87 modifient la taille des clés et des signatures, la taille des handshakes, la taille des images de micrologiciel et les exigences imposées aux modules matériels de sécurité. Une feuille de route qui s'arrête à ML-KEM-768 nécessitera un second passage.
• Les exigences européennes ne sont pas identiques. L'ANSSI rend l'hybridation obligatoire dans son périmètre réglementé (qualification de produits, procédures liées à la défense, opérateurs d'importance vitale) et précise que ses autres recommandations post-quantiques ne constituent pas encore des obligations réglementaires. La BSI TR-02102-1 (version 2026-01) est une directive technique qui recommande un accord de clés post-quantique hybride et ne considère l'accord de clés classique utilisé seul comme acceptable que jusqu'à fin 2031, ou fin 2030 pour les besoins de protection très élevés. Un produit vendu sur les deux marchés doit pouvoir négocier un groupe hybride et un jeu de paramètres CNSA 2.0, ce qui plaide pour une crypto-agilité dans le code plutôt que pour un choix unique codé en dur.

Si vous souhaitez voir toutes les échéances officielles côte à côte, notre synthèse des échéances de migration post-quantique met en regard CNSA 2.0, la feuille de route européenne, les dates du NCSC britannique et la trajectoire fédérale américaine.

Ce qu'il faut vérifier ce trimestre

Commencez en lecture seule, en préproduction, et conservez une solution de repli classique jusqu'à ce que l'échéance qui vous concerne soit proche.

Vérifiez quels groupes votre pile TLS peut réellement proposer. Les groupes ML-KEM nécessitent OpenSSL 3.5 ou une version ultérieure :

openssl version
openssl list -tls-groups

Recherchez MLKEM1024 et SecP384r1MLKEM1024, ainsi que le groupe largement déployé X25519MLKEM768. Les codepoints IANA sont publiés dans le registre des paramètres TLS, et le mécanisme hybride lui-même est spécifié dans la RFC 10024 (août 2026).

Testez ensuite ce qu'un serveur négocie, un groupe à la fois, sur un hôte de préproduction :

openssl s_client -connect staging.example.com:443 -groups MLKEM1024 </dev/null 2>&1 | grep -i -E "negotiated|group"
openssl s_client -connect staging.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i -E "negotiated|group"

Côté signature, générez une paire de clés ML-DSA-87 de test et mesurez l'effet des signatures plus volumineuses sur la taille de vos artefacts, votre canal de mise à jour et vos chemins de code de vérification :

openssl genpkey -algorithm ML-DSA-87 -out mldsa87-test.key

Tenez la clé de test à l'écart de tout magasin de confiance de production. Le travail le plus difficile est organisationnel : inventorier chaque racine de signature et sa date d'expiration, identifier les modules matériels de sécurité qui doivent prendre en charge ML-DSA-87 ou la signature à base de hachage avec état, et planifier la gestion d'état qu'exigent LMS et XMSS. Notre guide pour migrer la signature de code vers ML-DSA détaille l'enchaînement des étapes, y compris la double signature pendant la transition.

Étape suivante : mesurez ce que vous exposez aujourd'hui

Les échéances CNSA 2.0 portent sur ce que vos produits et services négocient réellement, et non sur ce que promet votre feuille de route. Commencez par la couche visible de l'extérieur : analysez votre domaine avec PQC Status pour voir quels groupes d'échange de clés, quelles versions de TLS et quels algorithmes de certificat vos points de terminaison proposent dès maintenant. Utilisez le résultat comme première ligne d'une liste d'écarts : points de terminaison sans aucun groupe ML-KEM, points de terminaison qui ne proposent que ML-KEM-768 alors qu'un contrat CNSA 2.0 exigera ML-KEM-1024, et chaînes de certificats encore signées en RSA ou ECDSA. Une analyse décrit une configuration TLS visible de l'extérieur. Ce n'est ni une certification ni une attestation de conformité : associez-la donc à votre inventaire interne des clés de signature, des images de micrologiciel et des bibliothèques embarquées.