Comment nous tenons cette page à jour
- Sources primaires uniquement. Chaque ligne renvoie à l’éditeur du texte : NIST, IETF ou RFC Editor, Commission européenne, ENISA, ETSI ou agence nationale. Nous ne citons ni blogs d’éditeurs ni articles de presse.
- Un projet n’est pas un texte définitif. Un projet du NIST, un Internet-Draft ou une proposition de la Commission peuvent encore évoluer. Nous les signalons comme tels, sans les présenter comme des exigences.
- Statuts : Final = norme ou spécification publiée ; Approuvé, RFC à paraître = approuvé par l’IESG, en attente d’un numéro de RFC ; Projet = publié pour commentaires ; Sélectionné = algorithme retenu, sans projet publié ; En cours d’élaboration = aucun projet public ; Avis / guide = recommandation, position ou rapport officiel, qui n’est pas une norme ; Proposition = proposition législative, pas encore du droit.
- La colonne « Ce que cela implique » reflète notre lecture pour une organisation européenne réglementée ; ce n’est pas un avis juridique. Quand une source évolue, nous mettons à jour la ligne et la date de vérification.
Sur petit écran, les tableaux défilent horizontalement.
NIST (États-Unis) : normes d’algorithmes et guides de transition8 entrées
| Publication | Contenu | Statut | Date | Ce que cela implique pour une entreprise européenne | Source primaire |
|---|---|---|---|---|---|
| FIPS 203 : ML-KEMNIST | Mécanisme d’encapsulation de clés sur réseaux euclidiens modulaires (issu de CRYSTALS-Kyber), pour l’établissement de clés. | Final | Le KEM post-quantique de référence. Les agences européennes l’attendent en mode hybride, avec un algorithme classique, pendant la transition.Notre guide ML-KEM (en anglais) → | csrc.nist.gov | |
| FIPS 204 : ML-DSANIST | Signature numérique sur réseaux euclidiens modulaires (issue de CRYSTALS-Dilithium), à usage général. | Final | La signature post-quantique par défaut pour les certificats, la signature de code et de documents. C’est autour d’elle que se prépare l’évolution des PKI.Notre guide ML-DSA (en anglais) → | csrc.nist.gov | |
| FIPS 205 : SLH-DSANIST | Signature numérique fondée sur le hachage, sans état (issue de SPHINCS+). | Final | Une signature prudente mais volumineuse, adaptée aux racines de confiance et micrologiciels à longue durée de vie plutôt qu’au TLS à fort volume.Notre guide SLH-DSA (en anglais) → | csrc.nist.gov | |
| FIPS 206 : FN-DSA (Falcon)NIST | Signature sur réseaux euclidiens, plus compacte que ML-DSA, dérivée de Falcon. | En cours d’élaborationProjet initial pas encore publié. Le NIST a annoncé un plan révisé (arithmétique en virgule fixe, une seule procédure de signature) le 28 sept. 2026. | Pas encore utilisable pour la conformité. Ne pas bâtir de conception sur FN-DSA : utiliser ML-DSA et garder le choix d’algorithme paramétrable. | csrc.nist.gov NIST pqc-forum |
|
| HQC (future norme FIPS)NIST | KEM fondé sur les codes correcteurs, retenu comme solution de secours à ML-KEM, sur une base mathématique différente. | SélectionnéRetenu le 11 mars 2025. Aucun projet de norme soumis à commentaires à ce jour ; le NIST vise une norme finale en 2027. | Rien à déployer. C’est un argument de plus pour rester crypto-agile, afin de pouvoir ajouter un second KEM plus tard.Notre guide crypto-agilité → | nist.gov | |
| SP 800-227 : recommandations pour les KEMNIST | Mise en œuvre et usage sûrs des mécanismes d’encapsulation de clés, avec des indications sur l’établissement de clés hybride. | Final | Une référence technique utile pour examiner l’implémentation ML-KEM ou hybride d’un fournisseur. | csrc.nist.gov | |
| IR 8547 : transition vers les normes PQCNIST | Calendrier américain proposé : algorithmes vulnérables au quantique de niveau 112 bits dépréciés après 2030 ; tous les algorithmes à clé publique vulnérables interdits après 2035. | ProjetProjet initial uniquement ; aucune version finale publiée. | Les dates 2030/2035 rejoignent la feuille de route de l’UE, mais restent des propositions. À citer comme projet, pas comme exigence du NIST.Notre guide de migration FIPS 203/204/205 (en anglais) → | csrc.nist.gov | |
| Signatures supplémentaires (« on-ramp »)NIST | Seconde compétition du NIST pour des signatures non fondées sur des réseaux structurés. | En cours d’élaborationCandidats du 3e tour annoncés le 14 mai 2026. | Aucune action à ce stade : une norme n’est pas attendue avant plusieurs années. | csrc.nist.gov |
IETF : protocoles et formats de certificats (TLS, X.509, CMS, IKEv2)10 entrées
| Publication | Contenu | Statut | Date | Ce que cela implique pour une entreprise européenne | Source primaire |
|---|---|---|---|---|---|
| RFC 10024 : accord de clés hybride ECDHE-MLKEM pour TLS 1.3IETF (groupe TLS) | Définit les groupes hybrides X25519MLKEM768 (recommandé), SecP256r1MLKEM768 et SecP384r1MLKEM1024. Proposed Standard. | Final | L’échange de clés TLS hybride à exiger des navigateurs, répartiteurs de charge, CDN et bibliothèques. Conforme aux attentes de l’ANSSI et du BSI sur l’hybridation.Notre guide ML-KEM (en anglais) → | rfc-editor.org | |
| RFC 9954 : échange de clés hybride dans TLS 1.3IETF (groupe TLS) | Le principe général de combinaison de deux échanges de clés dans TLS 1.3. Informational. | Final | Contexte de la RFC 10024 : utile pour comprendre le TLS hybride, pas comme objectif de conformité. | rfc-editor.org | |
| Accord de clés ML-KEM seul pour TLS 1.3 (draft-ietf-tls-mlkem)IETF (groupe TLS) | Groupes ML-KEM purement post-quantiques pour TLS 1.3, sans composante classique. Statut visé : Informational. | Approuvé, RFC à paraîtreApprouvé par l’IESG ; dans la file de l’éditeur des RFC. Pas encore de numéro. | L’ANSSI et le BSI recommandent aujourd’hui l’hybride, pas ML-KEM seul. En Europe, préférer les groupes hybrides de la RFC 10024. | IETF Datatracker | |
| RFC 9881 : ML-DSA dans X.509IETF (groupe LAMPS) | Identifiants d’algorithme pour les clés et signatures ML-DSA dans les certificats X.509 et les CRL. Proposed Standard. | Final | Les certificats post-quantiques ont désormais un format stable. Demander à vos fournisseurs de PKI et de HSM leurs dates de prise en charge.Notre guide ML-DSA (en anglais) → | rfc-editor.org | |
| RFC 9935 : ML-KEM dans X.509IETF (groupe LAMPS) | Identifiants d’algorithme pour les clés publiques ML-KEM dans les certificats X.509. Proposed Standard. | Final | Utile lorsque les certificats portent des clés de chiffrement (par exemple S/MIME). Moins concerné : les certificats de serveurs TLS. | rfc-editor.org | |
| RFC 9909 : SLH-DSA dans X.509IETF (groupe LAMPS) | Identifiants d’algorithme pour SLH-DSA dans les certificats X.509 et les CRL. Proposed Standard. | Final | Concerne surtout les AC racines à longue durée de vie qui choisissent des signatures fondées sur le hachage.Notre guide SLH-DSA (en anglais) → | rfc-editor.org | |
| ML-DSA composite pour X.509 (draft-ietf-lamps-pq-composite-sigs)IETF (groupe LAMPS) | Une clé et une signature combinant ML-DSA et un algorithme classique (RSA, ECDSA ou EdDSA). Statut visé : Proposed Standard. | Approuvé, RFC à paraîtreApprouvé par l’IESG ; dans la file de l’éditeur des RFC. Pas encore de numéro. | La principale voie vers des certificats hybrides, importante là où l’ANSSI ou le BSI attendent des signatures hybrides. À suivre jusqu’à la RFC avant tout achat.Notre guide ML-DSA (en anglais) → | IETF Datatracker | |
| ML-KEM composite pour X.509 (draft-ietf-lamps-pq-composite-kem)IETF (groupe LAMPS) | Clés KEM hybrides combinant ML-KEM et un algorithme classique dans un même certificat. Statut visé : Proposed Standard. | Approuvé, RFC à paraîtreApprouvé par l’IESG ; dans la file de l’éditeur des RFC. Pas encore de numéro. | Concerne la messagerie chiffrée hybride. À suivre, sans construire sur le texte du projet. | IETF Datatracker | |
| CMS : RFC 9629, RFC 9814, RFC 9882, RFC 9936IETF (groupe LAMPS) | KEM dans CMS (9629, août 2024) ; SLH-DSA dans CMS (9814, juil. 2025) ; ML-DSA dans CMS (9882, oct. 2025) ; ML-KEM dans CMS (9936, mars 2026). Toutes Proposed Standard. | Final | Concerne S/MIME, les documents signés et les paquets de micrologiciels. Vérifier la prise en charge par vos outils de signature et d’archivage. | RFC 9629 RFC 9814 RFC 9882 RFC 9936 |
|
| ML-KEM dans IKEv2 (draft-ietf-ipsecme-ikev2-mlkem)IETF (groupe IPsecME) | Échange de clés post-quantique ML-KEM pour les VPN IPsec (IKEv2). Statut visé : Proposed Standard. | Approuvé, RFC à paraîtreApprouvé par l’IESG ; dans la file de l’éditeur des RFC. Pas encore de numéro. | Les VPN inter-sites sont un cas d’usage typiquement à haut risque. Demander leur feuille de route aux fournisseurs ; l’ANSSI publie une fiche dédiée à IPsec. | IETF Datatracker |
Union européenne, ENISA et ETSI9 entrées
| Publication | Contenu | Statut | Date | Ce que cela implique pour une entreprise européenne | Source primaire |
|---|---|---|---|---|---|
| Recommandation (UE) 2024/1101 sur une feuille de route PQC coordonnéeCommission européenne | Demande aux États membres de coordonner la transition vers la PQC et d’élaborer une feuille de route commune. | Avis / guideRecommandation de la Commission (non contraignante). | Le fondement politique du calendrier européen ci-dessous.Notre guide feuille de route UE → | digital-strategy.ec.europa.eu | |
| Feuille de route coordonnée pour la transition vers la PQCGroupe de coopération NIS, avec la Commission européenne | Jalons : au 31 déc. 2026, premières étapes, feuilles de route nationales et pilotes ; au 31 déc. 2030, cas d’usage à haut risque migrés ; au 31 déc. 2035, risque moyen terminé et risque faible autant que possible. | Avis / guideVersion 1.1 ; non contraignante. | Le calendrier de référence de l’UE. Les autorités nationales et superviseurs devraient s’aligner sur 2026, 2030 et 2035.Notre guide feuille de route UE → | digital-strategy.ec.europa.eu | |
| Feuille de route PQC de l’UE : retours d’enquête et FAQGroupe de coopération NIS | Résultats de l’enquête 2025 auprès des parties prenantes (97 contributions) et FAQ sur l’estimation du risque, les jalons, la priorisation et l’hybridation. | Avis / guide | Précise la feuille de route sans en modifier les dates. | digital-strategy.ec.europa.eu | |
| Proposition de modification de NIS2 : COM(2026) 13Commission européenne | Ajouterait un article 7(2)(k) : les stratégies nationales de cybersécurité devraient inclure des politiques de transition vers la PQC, conformes aux calendriers de l’Union. | PropositionProposition de la Commission en cours de procédure législative ; non adoptée lors de notre dernière vérification. | Vise les États membres et non directement les entreprises, mais ferait des politiques nationales PQC une exigence NIS2.Notre guide NIS2 article 21 → | digital-strategy.ec.europa.eu | |
| ECCG Agreed Cryptographic Mechanisms v2 (EUCC)Sous-groupe cryptographie de l’ECCG, publié par l’ENISA | Algorithmes agréés pour la certification européenne de cybersécurité, dont ML-KEM, FrodoKEM, ML-DSA et SLH-DSA. Les schémas sur réseaux euclidiens ne devraient pas être utilisés seuls. | FinalApplicable dans le cadre d’EUCC depuis le 6 mai 2025. | La liste d’algorithmes de niveau UE pour les produits certifiés (cartes à puce, HSM). L’hybridation est attendue pour les KEM et signatures sur réseaux euclidiens. | certification.enisa.europa.eu | |
| ECCG Agreed Cryptographic Mechanisms v3Sous-groupe cryptographie de l’ECCG, publié par l’ENISA | Version révisée des mécanismes agréés, publiée avec un journal des modifications pour consultation publique. | ProjetProjet soumis à consultation publique (jusqu’à fin juillet 2026). | La version 2 reste applicable. Lire le journal des modifications avant tout projet de certification. | certification.enisa.europa.eu | |
| Hybridation des mécanismes cryptographiques traditionnels avec la PQC : état de la normalisationENISA | Met en regard les travaux IETF sur l’accord de clés et les signatures hybrides et l’ACM v2. L’ENISA précise qu’il ne s’agit pas d’une recommandation. | Avis / guideRapport (pas une recommandation). | Une bonne cartographie des constructions hybrides normalisées, pour les architectes qui doivent choisir. | certification.enisa.europa.eu | |
| Études post-quantiques de l’ENISAENISA | « Current state and quantum mitigation » (mai 2021) et « Integration study » (oct. 2022). | Avis / guideRapports. | Lecture de fond ; antérieures aux normes du NIST. | enisa.europa.eu (2021) enisa.europa.eu (2022) |
|
| ETSI TS 103 744 V1.2.2 : établissement de clés hybride résistant au quantiqueETSI TC CYBER (QSC) | Méthodes (CatKDF, CasKDF) pour dériver des clés à partir d’un secret ECDH classique et d’un secret KEM post-quantique. | FinalSpécification technique. | Une référence européenne pour les combinateurs de clés hybrides, utile pour les protocoles hors TLS et IKEv2. | etsi.org |
Agences nationales : ANSSI, BSI, NCSC, NSA (et déclarations communes)8 entrées
| Publication | Contenu | Statut | Date | Ce que cela implique pour une entreprise européenne | Source primaire |
|---|---|---|---|---|---|
| Position de l’ANSSI sur la transition post-quantiqueANSSI (France) | Avis de 2022 et suivi de 2023 : hybridation requise pendant la transition ; exigences PQC pour la qualification de produits dès 2027 ; acheter des produits sans PQC après 2030 « pas raisonnable ». | Avis / guide | Pour les OIV, OSE et entités NIS2 françaises, faire dès maintenant du PQC hybride un critère d’achat, notamment pour les VPN, HSM et PKI.Notre guide ANSSI → | cyber.gouv.fr | |
| Fiches techniques ANSSI : transition post-quantique de TLS 1.3, SSHv2 et IPsecANSSI (France) | ANSSI-FT-115 (TLS 1.3), FT-116 (SSHv2) et FT-117 (IPsec) : comment apporter une sécurité post-quantique à chaque protocole, l’hybridation étant la méthode privilégiée. | Avis / guideVersion 1.0. | Des recommandations concrètes, protocole par protocole, pour les équipes réseau et sécurité.Notre guide ANSSI → | TLS 1.3 SSHv2 IPsec |
|
| Avis de l’ANSSI sur la crypto-agilitéANSSI (France) | La position de l’ANSSI sur la conception de systèmes dont les algorithmes peuvent être changés. | Avis / guide | Justifie de demander aux fournisseurs en combien de temps ils peuvent changer d’algorithme, et pas seulement s’ils prennent en charge ML-KEM aujourd’hui.Notre guide crypto-agilité → | cyber.gouv.fr | |
| BSI TR-02102-1, version 2026-01BSI (Allemagne) | Mécanismes et tailles de clés recommandés. PQC en mode hybride ; accord de clés purement classique recommandé seulement jusqu’à fin 2031 (fin 2030 pour les besoins de protection très élevés) ; signatures classiques jusqu’à fin 2035. | FinalDirective technique, mise à jour chaque année. | Les dates nationales les plus précises de l’UE. Une bonne référence de politique, même hors d’Allemagne.Notre comparatif BSI, ENISA, NCSC, ANSSI (en anglais) → | bsi.bund.de | |
| Déclaration commune « Securing Tomorrow, Today »BSI, ANSSI, NLNCSA et agences partenaires | Protéger les cas d’usage les plus sensibles au plus tard fin 2030 ; utiliser la PQC en mode hybride. Publiée en nov. 2024 (18 États membres) ; mise à jour le 27 juin 2025 (21 États européens). | Avis / guide | L’origine de l’échéance 2030 pour les cas à haut risque, reprise par la feuille de route de l’UE.Notre guide feuille de route UE → | bsi.bund.de | |
| Calendrier du NCSC pour la migration vers la PQCNCSC (Royaume-Uni) | D’ici 2028 : objectifs, inventaire complet et plan initial. D’ici 2031 : migrations prioritaires réalisées, plan affiné. D’ici 2035 : migration terminée. | Avis / guide | À suivre pour les activités et fournisseurs au Royaume-Uni. Son jalon d’inventaire en 2028 est plus tardif que le démarrage UE fin 2026.Notre comparatif BSI, ENISA, NCSC, ANSSI (en anglais) → | ncsc.gov.uk | |
| CNSA 2.0NSA (États-Unis) | Algorithmes des systèmes de sécurité nationale américains (ML-KEM-1024, ML-DSA-87, LMS/XMSS). Usage exclusif d’ici 2030 pour la signature logicielle et les équipements réseau, d’ici 2033 pour navigateurs, cloud et systèmes d’exploitation ; nouvelles acquisitions conformes dès le 1er janv. 2027. | FinalAvis (sept. 2022) et FAQ v2.1 (déc. 2024). Contraignant uniquement pour les systèmes de sécurité nationale américains. | Pas une exigence européenne. Concerne les fournisseurs de clients de défense américains, et oriente souvent les feuilles de route des éditeurs. | media.defense.gov | |
| Preparing for the Post-Quantum Era: A Call to ActionGroupe de travail cybersécurité du G7 (publié par l’ANSSI) | Appelle les organisations à commencer dès maintenant : plans progressifs fondés sur le risque, inventaires cryptographiques, cartographie des dépendances et achat de produits compatibles PQC. | Avis / guidePas de nouvelle échéance ; renvoie aux calendriers nationaux. | Confirme que l’inventaire et la planification sont les premières étapes attendues dans les pays du G7. | cyber.gouv.fr |
Guides associés
Lesquels de ces textes concernent vos systèmes ? Un inventaire cryptographique montre où RSA et les courbes elliptiques sont utilisés aujourd’hui, et vers quelle norme chaque usage doit migrer.
Demander une démo → Auto-évaluation gratuite