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.
- À qui cela s'applique
- Un fabricant doté d'un système de management de la sécurité de l'information certifié, qui demande quelle part du dossier technique il détient déjà.
- Les dates
- Avant de commencer le dossier, car la réponse décide de ce que vous écrivez et de ce que vous citez.
- La seule chose à faire
- Lisez la correspondance ligne à ligne : ce que votre système prouve déjà, ce qu'il couvre à moitié, et ce qu'aucune mesure de sécurité ne produit.
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
| Base | Exigences | Ce que cela signifie |
|---|---|---|
| L'enregistrement du SMSI est la preuve 3 | 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 | 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 | 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 1 : les 22 exigences essentielles en liste de contrôle, 14 exigences produit et 8 de gestion des vulnérabilités
Ce que votre produit doit respecter à partir du 11 décembre 2027 et que le dossier technique doit montrer : partie I, 14 exigences produit, dont 13 « le cas échéant » sur la base de votre évaluation des risques ; partie II, 8 exigences de gestion des vulnérabilités qui s'appliquent toujours.
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.
Normes harmonisées pour le CRA : aucune citée encore, 41 demandées, les deux premières étaient dues le 30 août 2026
La demande M/606 du 3 février 2025 commande au CEN, au CENELEC et à l'ETSI 41 normes : deux horizontales pour le 30 août 2026, les verticales pour les produits des annexes III et IV pour le 30 octobre 2026, les exigences génériques pour le 30 octobre 2027.
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é.
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.
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.
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.
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.
Ensuite : la documentation technique, onze documents, rédigée dans votre organisation.
Documents par e-mail ; ajoutez-les à un espace gratuit quand vous voulez.
Ou commencer gratuitement et enregistrer un produit
Ou le faire avec vous : Préparation au CRA, 1 500 €, 10 jours ouvrés
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.