Cyber Resilience Act : tous les outils et articles
Règlement (UE) 2024/2847, annexe I · ISO/IEC 27001:2022, annexe A
Les exigences essentielles du CRA, mises en correspondance avec ISO 27001
Un fabricant dont le SMSI est certifié pose d'abord une question : quelle part de la documentation technique ai-je déjà ? La réponse a trois parties. Pour les 14 exigences de la partie I, les propriétés du produit, le SMSI fait tourner le processus et le produit fournit la preuve. Pour 3 des 8 exigences de gestion des vulnérabilités de la partie II, l'enregistrement du SMSI est la preuve. Et pour 4 des 22, rien dans l'annexe A ne produit ce que le règlement demande.
Un système de management n'est pas un produit
ISO 27001 certifie la manière dont une organisation gère la sécurité de l'information. Le Cyber Resilience Act réglemente un produit : ce qu'il fait, comment il est construit et comment ses vulnérabilités sont gérées pendant sa période d'assistance. Les deux se rejoignent dans les mesures de développement de l'annexe A, qui régissent la façon dont le produit est construit, et dans les mesures de gestion des vulnérabilités, qui régissent ce qui se passe après la mise sur le marché. Ils ne se rejoignent pas dans les propriétés du produit lui-même : aucun enregistrement du SMSI ne montre qu'un produit est livré avec une configuration sécurisée par défaut. La documentation et les essais du produit le montrent.
Trois réponses, pas un score
- L'enregistrement du SMSI est la preuve
- 3
- L'enregistrement que la mesure produit est ce que la documentation technique cite : le registre des vulnérabilités, le journal des corrections, les rapports d'essai.
- Le SMSI fait tourner le processus, le produit fournit la preuve
- 15
- La mesure fixe l'exigence, le principe, la règle de codage ou l'essai ; la preuve que le produit y satisfait est celle du produit, par version.
- Pas produit par l'annexe A
- 4
- Rien dans l'annexe A ne publie quoi que ce soit, ne dresse une nomenclature d'un produit ni ne s'engage à des mises à jour gratuites. Cela s'écrit pour le règlement.
Partie I : les propriétés du produit
Le point 1 est l'obligation générale, fondée sur l'évaluation des risques. Le point 2 énumère treize propriétés, chacune applicable sur la base de cette évaluation, de sorte qu'une propriété jugée non applicable est exclue avec une justification dans la documentation. Pour toutes, le SMSI fournit le processus : les exigences de sécurité que le produit doit satisfaire, les principes selon lesquels il est conçu, les règles de codage, les essais avant la mise sur le marché. La preuve de chaque propriété est celle du produit.
I.1 Niveau de cybersécurité approprié dès la conception
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- Article 6.1.2
- A.5.8
- A.8.25
Ce que la documentation exige encore : Une évaluation des risques de cybersécurité pour le produit lui-même (article 13, paragraphes 2 et 3), conservée dans la documentation technique au titre de l'annexe VII, point 3. Le SMSI évalue les risques de l'organisation ; ceux du produit sont un enregistrement distinct.
Dans le pack de documentation technique : Cybersecurity risk assessment
I.2.a Aucune vulnérabilité exploitable connue à la mise sur le marché
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.8
- A.8.29
Ce que la documentation exige encore : La vérification se fait par version et par composant livré, et son résultat reste attaché à cette version. Une analyse des propres systèmes de l'organisation est un autre enregistrement.
Dans le pack de documentation technique : Standards applied and test evidence
I.2.b Configuration sécurisée par défaut
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.9
- A.8.26
Ce que la documentation exige encore : La configuration sécurisée par défaut et la réinitialisation vers celle-ci sont des propriétés du produit, montrées par sa documentation et ses essais, non par une configuration de référence des systèmes de l'organisation.
Dans le pack de documentation technique : Standards applied and test evidence
I.2.c Mises à jour de sécurité
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.8
- A.8.32
Ce que la documentation exige encore : Un mécanisme de mise à jour dans le produit, automatique par défaut avec une possibilité de refus pour l'utilisateur, et une notification aux utilisateurs quand une mise à jour est disponible : une fonctionnalité, pas un processus.
Dans le pack de documentation technique : Standards applied and test evidence
I.2.d Protection contre l'accès non autorisé
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.26
- A.8.5
- A.5.15
- A.5.16
- A.5.17
Dans le pack de documentation technique : Standards applied and test evidence
I.2.e Confidentialité des données
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.26
- A.8.24
Dans le pack de documentation technique : Standards applied and test evidence
I.2.f Intégrité des données, des commandes et de la configuration
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.26
- A.8.24
- A.8.9
Dans le pack de documentation technique : Standards applied and test evidence
I.2.g Minimisation des données
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.26
- A.5.34
Dans le pack de documentation technique : Standards applied and test evidence
I.2.h Disponibilité des fonctions essentielles et de base
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.26
- A.8.6
- A.8.14
Dans le pack de documentation technique : Standards applied and test evidence
I.2.i Pas d'incidence négative sur d'autres appareils et réseaux
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.27
- A.8.20
Dans le pack de documentation technique : Standards applied and test evidence
I.2.j Surfaces d'attaque limitées
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.27
- A.8.9
Dans le pack de documentation technique : Standards applied and test evidence
I.2.k Incidence réduite des incidents
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.27
- A.8.28
Dans le pack de documentation technique : Standards applied and test evidence
I.2.l Journalisation et surveillance de sécurité
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.26
- A.8.15
- A.8.16
Dans le pack de documentation technique : Standards applied and test evidence
I.2.m Suppression sûre et facile des données et des paramètres
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.26
- A.8.10
Dans le pack de documentation technique : Standards applied and test evidence
Partie II : la gestion des vulnérabilités pendant la période d'assistance
Huit exigences imposées au fabricant, dont aucune ne peut être exclue. C'est là qu'un SMSI est le plus proche du règlement, et là que se trouvent les lacunes précises : la nomenclature, la divulgation publique, la politique, l'adresse de contact et les mises à jour gratuites.
II.1 Recenser et documenter les vulnérabilités et les composants, avec une SBOM
L'enregistrement du SMSI est la preuve
Le processus, dans l'annexe A
- A.8.8
- A.5.9
Ce que la documentation exige encore : Une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau du produit. Aucune mesure de l'annexe A ne demande une nomenclature d'un produit.
Dans le pack de documentation technique : Software bill of materials procedure
II.2 Corriger les vulnérabilités sans retard
L'enregistrement du SMSI est la preuve
Le processus, dans l'annexe A
- A.8.8
- A.8.32
Ce que la documentation exige encore : Des mises à jour de sécurité fournies séparément des mises à jour fonctionnelles lorsque c'est techniquement possible : une pratique de livraison que l'annexe A ne nomme pas.
Dans le pack de documentation technique : Security updates and support statement
II.3 Essais et examens réguliers
L'enregistrement du SMSI est la preuve
Le processus, dans l'annexe A
- A.8.29
- A.8.8
- A.5.35
Dans le pack de documentation technique : Vulnerability handling process
II.4 Divulguer les vulnérabilités corrigées
Pas produit par l'annexe A
Ce que la documentation exige encore : La divulgation publique de chaque vulnérabilité corrigée une fois la mise à jour disponible : description, produits concernés, incidences, gravité et façon dont les utilisateurs y remédient. L'annexe A n'a aucune mesure qui publie quoi que ce soit.
Dans le pack de documentation technique : Vulnerability handling process
II.5 Politique de divulgation coordonnée des vulnérabilités
Pas produit par l'annexe A
Ce que la documentation exige encore : Une politique de divulgation coordonnée des vulnérabilités, mise en place et appliquée. L'annexe A exige un processus de gestion des incidents, pas une politique publiée à l'intention des déclarants extérieurs.
Dans le pack de documentation technique : Coordinated vulnerability disclosure policy
II.6 Un contact pour signaler les vulnérabilités
Pas produit par l'annexe A
Ce que la documentation exige encore : Une adresse de contact publiée pour les signalements de vulnérabilités dans le produit et dans ses composants tiers, et un moyen de les recevoir.
Dans le pack de documentation technique : Coordinated vulnerability disclosure policy
II.7 Distribution sûre et rapide des mises à jour
Le SMSI fait tourner le processus, le produit fournit la preuve
Le processus, dans l'annexe A
- A.8.24
- A.8.32
Ce que la documentation exige encore : Le mécanisme de distribution est celui du produit : mises à jour signées, livrées de façon sûre et à temps, automatiquement le cas échéant.
Dans le pack de documentation technique : Security updates and support statement
II.8 Correctifs de sécurité gratuits, avec avis
Pas produit par l'annexe A
Ce que la documentation exige encore : Des mises à jour de sécurité gratuites pendant la période d'assistance, sans retard, avec un avis aux utilisateurs. Un engagement commercial et une publication, dont l'annexe A ne nomme ni l'un ni l'autre.
Dans le pack de documentation technique : Security updates and support statement
4 choses que l'annexe A ne produit pas
Écrites en toutes lettres, pour qu'un fabricant certifié sache quoi rédiger, et pas seulement quoi citer. Chacune des 4 aboutit dans l'un des 3 documents du pack de documentation technique, et ces documents sont rédigés à partir de la fiche produit, non du SMSI.
II.4 Divulguer les vulnérabilités corrigées
La divulgation publique de chaque vulnérabilité corrigée une fois la mise à jour disponible : description, produits concernés, incidences, gravité et façon dont les utilisateurs y remédient. L'annexe A n'a aucune mesure qui publie quoi que ce soit.
II.5 Politique de divulgation coordonnée des vulnérabilités
Une politique de divulgation coordonnée des vulnérabilités, mise en place et appliquée. L'annexe A exige un processus de gestion des incidents, pas une politique publiée à l'intention des déclarants extérieurs.
II.6 Un contact pour signaler les vulnérabilités
Une adresse de contact publiée pour les signalements de vulnérabilités dans le produit et dans ses composants tiers, et un moyen de les recevoir.
II.8 Correctifs de sécurité gratuits, avec avis
Des mises à jour de sécurité gratuites pendant la période d'assistance, sans retard, avec un avis aux utilisateurs. Un engagement commercial et une publication, dont l'annexe A ne nomme ni l'un ni l'autre.
Ce que cette page n'est pas
Pas un taux de couverture. Aucun pourcentage n'est calculé ici et aucun ne devrait l'être. Une exigence dont le processus est dans le SMSI et dont la preuve n'est pas encore dans la documentation n'est pas une fraction couverte ; c'est un document à rédiger.
Pas une présomption de conformité. Seule une norme harmonisée citée au Journal officiel en donne une (article 27), et ISO 27001 n'est pas, et ne sera pas, cette norme. Où en sont les normes harmonisées, et ce que leur absence signifie pour chaque catégorie
Pas la correspondance NIS2. NIS2 réglemente l'organisation et ses mesures sont écrites à partir d'ISO 27001, ce qui rend cette correspondance-là plus proche. Le règlement d'exécution NIS2 mis en correspondance avec ISO 27001
À lire ensuite
CRA annexe I : les 22 exigences essentielles, en liste de contrôle
L'annexe I du règlement sur la cyberrésilience est ce que votre produit doit respecter à partir du 11 décembre 2027 et ce que le dossier technique doit démontrer. La partie I compte 14 exigences sur le produit, dont 13 « le cas échéant » sur la base de votre évaluation des risques ; la partie II compte 8 exigences de gestion des vulnérabilités qui s'appliquent toujours. Les voici en un seul tableau, avec ce que chacune demande et si vous pouvez l'exclure.
Ce que contient le dossier technique du CRA : l'annexe VII, point par point
À partir du 11 décembre 2027, tout produit comportant des éléments numériques mis sur le marché de l'UE a besoin d'une documentation technique avant sa mise sur le marché, conservée dix ans ou pendant la période d'assistance, la plus longue des deux. L'annexe VII dit ce qu'elle contient en huit points. Les voici, ce que chacun demande réellement, les quatre documents que la partie II de l'annexe I présuppose, et combien de temps vous la gardez.
Normes harmonisées pour le CRA : ce que demande la demande de normalisation M/606, pour quand, et ce dont un fabricant dispose aujourd'hui
L'article 27 donne une présomption de conformité aux produits qui suivent des normes harmonisées citées au Journal officiel. Le 3 février 2025, la Commission en a demandé 41 au CEN, au CENELEC et à l'ETSI, avec des délais du 30 août 2026 au 30 octobre 2027 ; les trois ont accepté le 3 avril 2025. Le 12 septembre 2026, l'index des normes harmonisées de la Commission n'a toujours aucune entrée pour le règlement, ce qui, pour un produit de classe I, signifie aucune voie d'auto-évaluation au titre de l'article 32(2). Ce qui a été demandé, les dates, et contre quoi construire d'ici là.
L'auto-évaluation au titre du CRA : ce que le module A exige vraiment, d'après l'annexe VIII et la FAQ de la Commission
La plupart des produits logiciels ne verront jamais un organisme notifié. Ils utilisent le module A, la procédure de contrôle interne de l'annexe VIII, et « auto-évaluation » est le mot que tout le monde emploie sans dire ce qu'il contient. L'annexe VIII, partie I, tient en cinq points ; la FAQ de la Commission ajoute la liste des activités, le fait qu'aucune méthodologie d'essai n'est imposée, l'endroit où un produit logiciel porte son marquage CE, les deux formes de la déclaration de conformité, et le calendrier des normes harmonisées qui décide quand l'auto-évaluation cesse de vouloir dire « directement contre l'annexe I ».
L'évaluation des risques de cybersécurité du CRA : ce que l'article 13 exige vraiment, et le seul résultat qu'elle doit produire
L'article 13, paragraphes 2 à 4, du règlement sur la cyberrésilience fait de l'évaluation des risques le document dont dépend toute autre obligation du CRA. Elle doit analyser les risques d'après la finalité, l'utilisation prévisible et les conditions d'utilisation sur la durée d'utilisation attendue ; dire si et comment chaque exigence du point 2 de la partie I s'applique ; dire comment le point 1 de la partie I et la partie II sont appliqués ; être documentée, tenue à jour sur la période d'assistance et incluse dans le dossier technique, avec une justification claire pour chaque exigence écartée. Les quatre paragraphes, et une structure d'une page qui y satisfait.
Le CRA exige-t-il une SBOM ? Oui, et voici exactement ce qu'il dit
L'annexe I, partie II, point 1 du règlement sur la cyberrésilience exige une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau. Elle va dans le dossier technique, n'est pas publiée, et une autorité de surveillance du marché peut la demander sur demande motivée. Les trois phrases qui tranchent, et ce qu'elles laissent ouvert.
La politique de divulgation coordonnée des vulnérabilités exigée par le CRA : trois dispositions, et une politique d'une page qui y répond
L'annexe I, partie II, point 5 du règlement sur la cyberrésilience exige de tout fabricant dans le champ qu'il mette en place et applique une politique de divulgation coordonnée des vulnérabilités. L'article 13, paragraphe 17, exige un point de contact unique pour les signalements, facile à trouver et non limité à des outils automatisés ; l'annexe II, point 2, exige le contact et l'emplacement de la politique dans les informations utilisateur ; l'annexe VII, point 2 b), met les deux dans le dossier technique. Ce que chaque disposition demande, ce qu'une politique doit dire, et ce qu'elle ne doit pas promettre.
Le règlement sur la cyberrésilience pour un petit fabricant de logiciels, en douze étapes
Tout ce qu'une entreprise de dix personnes qui livre un logiciel installé ou un appareil doit faire au titre du CRA, dans l'ordre où le faire : la détermination du champ d'application, le palier, le CSIRT et l'autorité d'application, la procédure de notification en vigueur depuis le 11 septembre 2026, puis le dossier technique, les 22 exigences, la SBOM, la période d'assistance, le marquage CE et la déclaration dus pour le 11 décembre 2027. Chaque étape avec son article et le texte qui l'explique.
Les 4 lacunes sont 3 des 11 documents de la documentation
StandardOS tient les enregistrements du SMSI que produisent les 23 mesures mises en correspondance, et le pack de documentation technique rédige les 11 documents de l'annexe VII à partir de la fiche produit, dont la politique de divulgation, la déclaration sur les mises à jour et la procédure SBOM. La correspondance de cette page est la jonction entre les deux.
L'annexe I s'applique à partir du 11 décembre 2027. Les mesures sont les 93 de l'annexe A d'ISO/IEC 27001:2022, citées par référence ; la correspondance est la nôtre, pas celle de l'ISO ni de la Commission. Ceci n'est pas un avis juridique, et le règlement est le texte à lire : Règlement (UE) 2024/2847.