Cyber Resilience Act :
ce que les fabricants doivent faire et à quelles dates

Le Cyber Resilience Act (CRA), ou règlement (UE) 2024/2847 sur la cyberrésilience, fixe des exigences horizontales de cybersécurité pour les produits comportant des éléments numériques sur le marché de l’Union. Il porte sur la sécurité du produit et le traitement des vulnérabilités. Il ne constitue ni un conseil juridique ni une décision sur un produit particulier.

Quels produits sont concernés ?

Partez du produit effectivement fourni. L’article 2, paragraphe 1, vise les produits dont l’utilisation prévue ou raisonnablement prévisible inclut une connexion de données logique ou physique, directe ou indirecte, à un dispositif ou à un réseau. Une connexion à internet n’est donc pas le seul critère. Des composants logiciels ou matériels commercialisés séparément peuvent aussi entrer dans la définition de l’article 3, point 1).

La définition comprend les solutions de traitement de données à distance répondant aux conditions de l’article 3, point 2) : elles sont conçues par le fabricant ou sous sa responsabilité, et leur absence empêcherait le produit de remplir une de ses fonctions. Examinez le produit avec ses dépendances. La présence d’un service cloud ne tranche pas, à elle seule, la question.

L’article 2 prévoit des exclusions précises : produits relevant des textes médicaux ou automobiles qu’il cite, certains produits aéronautiques, équipements marins, pièces de rechange identiques répondant aux conditions prévues, produits développés ou modifiés exclusivement pour la sécurité nationale ou la défense. Une étiquette sectorielle ne suffit pas. La gratuité ou une licence ouverte impose aussi d’examiner la fourniture et le rôle concerné.

Qui est le fabricant ?

Selon l’article 3, point 13), le fabricant est la personne physique ou morale qui développe ou fabrique le produit, ou le fait concevoir, développer ou fabriquer, et le commercialise sous son nom ou sa marque. La définition couvre la fourniture payante, la monétisation et la fourniture gratuite. Externaliser le développement ne dispense donc pas d’identifier le fabricant responsable.

Identifiez l’entité juridique, le produit et le nom de commercialisation. Distinguez ce rôle de ceux d’importateur, de distributeur et d’intendant de logiciels ouverts. Pour un logiciel ouvert fourni commercialement, la publication du code ne suffit pas à conclure. Le CRA distingue fabricant et intendant de logiciels ouverts ; ses considérants traitent aussi du développement ouvert non commercial. Clarifiez ces limites avant de choisir une procédure de conformité.

Trois dates d’application, aux effets différents

L’article 71, paragraphe 2, fixe les dates suivantes. Elles ne déclenchent pas les mêmes obligations :

• 11 juin 2026 : le chapitre IV, articles 35 à 51, s’applique depuis cette date. Il est relatif à la notification des organismes d’évaluation de la conformité. Ce n’est pas le début général des obligations des fabricants concernant les produits.
• 11 septembre 2026 : les obligations de notification de l’article 14 s’appliquent depuis cette date. Elles concernent les vulnérabilités activement exploitées et les incidents graves affectant la sécurité du produit.
• 11 décembre 2027 : application générale du règlement à compter de cette date, dont les principales obligations des fabricants relatives au produit, au traitement des vulnérabilités et à la conformité.

Une commercialisation antérieure ne dispense pas automatiquement de notifier. L’article 69, paragraphe 3, étend l’article 14 aux produits concernés mis sur le marché avant le 11 décembre 2027. Le paragraphe 2 traite séparément des autres exigences applicables lorsque ces produits subissent une modification substantielle à compter de cette date. Préparez distinctement le processus de notification et l’évaluation des futures versions.

Le développement sécurisé part de l’évaluation des risques

L’article 13, paragraphes 1 à 4, relie conception, développement et production à l’annexe I, partie I. Le fabricant évalue les risques de cybersécurité et en tient compte pendant la planification, la conception, le développement, la production, la livraison et la maintenance. Cette évaluation est documentée et actualisée, si nécessaire, pendant la période d’assistance. Elle considère l’utilisation prévue et prévisible, ses conditions et sa durée attendue.

L’annexe I couvre notamment la configuration sécurisée par défaut, les accès non autorisés, la confidentialité et l’intégrité des données, les surfaces d’attaque et les mises à jour de sécurité. L’applicabilité dépend de l’évaluation des risques et des conditions légales. Toute exigence non applicable doit être clairement justifiée dans la documentation technique. En pratique, reliez chaque exigence applicable aux choix techniques et aux résultats d’essais.

Traiter les vulnérabilités après la livraison

L’article 13, paragraphe 8, exige un traitement efficace des vulnérabilités du produit, composants compris, lors de sa mise sur le marché et pendant la période d’assistance. L’annexe I, partie II, couvre la correction, les essais réguliers, la divulgation coordonnée, une adresse de signalement et la distribution sécurisée des mises à jour. Les composants de fournisseurs restent pertinents pour l’évaluation du fabricant.

La période d’assistance doit refléter l’utilisation attendue et les facteurs de l’article 13, paragraphe 8. Elle dure au moins cinq ans, sauf si l’utilisation attendue est plus courte ; elle correspond alors à cette durée. Prévoyez un responsable des signalements, un moyen d’identifier les versions touchées et un suivi des mesures correctives. Ces conseils pratiques ne remplacent pas les exigences légales.

La nomenclature des logiciels soutient ce travail

L’annexe I, partie II, point 1, impose d’identifier et de documenter les vulnérabilités et composants, notamment par une nomenclature des logiciels dans un format courant et lisible par machine couvrant au moins les dépendances de niveau supérieur. Cette disposition ne désigne pas de norme SBOM obligatoire. L’inventaire doit correspondre au produit évalué, plutôt qu’à un environnement de développement distinct.

Une SBOM ne démontre pas, à elle seule, le respect de toutes les exigences de cybersécurité. Le CRA n’impose pas non plus de publier toutes les SBOM en téléchargement libre. Le guide des exigences SBOM du CRA distingue la création de l’inventaire, son inclusion dans la documentation technique et sa fourniture dans les circonstances prévues par le règlement.

La documentation technique explique les preuves

Avant la mise sur le marché, le fabricant établit la documentation technique prévue à l’article 13, paragraphe 12. L’article 31 et l’annexe VII en précisent le contenu : informations pertinentes sur la manière dont le produit et les processus du fabricant respectent l’annexe I, dont l’évaluation des risques et le traitement des vulnérabilités. Elle doit rester à jour selon l’article 31, paragraphe 2.

Reliez l’identification du produit, les décisions de conception, les informations sur les composants et les rapports d’essais. Signalez les hypothèses encore ouvertes. Un dossier contenant une SBOM et un export d’analyse ne constitue pas, à lui seul, toute la documentation technique décrite par le règlement.

L’article 14 a ses propres déclencheurs et délais

L’article 14 distingue vulnérabilité activement exploitée contenue dans le produit et incident grave affectant sa sécurité. Chaque constat doit être évalué au regard du fait générateur légal. L’alerte précoce et la notification sont dues sans retard injustifié, au plus tard 24 et 72 heures après que le fabricant en a connaissance. L’alerte précoce ne relance pas le délai de 72 heures.

Le rapport final obéit à des événements différents : pour une vulnérabilité, au plus tard 14 jours après la disponibilité d’une mesure de correction ou d’atténuation ; pour un incident, dans le mois suivant la transmission de sa notification. Consultez le guide de l’article 14 avant le calculateur de délais. Le guide de la plateforme ENISA présente les destinataires et la préparation. Un brouillon enregistré n’est pas une notification transmise.

Choisir la procédure selon la catégorie réelle

L’article 32 fixe les procédures d’évaluation de la conformité. Les produits importants de l’annexe III sont répartis en classes I et II ; les produits critiques figurent à l’annexe IV. La classification dépend de la fonctionnalité de base et des conditions légales. Selon l’article 7, paragraphe 1, intégrer un composant important ne rend pas, à lui seul, le produit entier important.

La procédure dépend de la catégorie, des normes ou spécifications applicables et, le cas échéant, de la certification de cybersécurité. Le contrôle interne n’est pas ouvert aux mêmes conditions pour toutes les catégories. Après démonstration de la conformité selon la procédure applicable viennent la déclaration UE de conformité et le marquage CE, conformément à l’article 13, paragraphe 12. Vérifiez les actes d’exécution et délégués en vigueur avant de choisir.

Pour poursuivre

Pour un examen préliminaire du champ d’application et de la catégorie, utilisez l’autoévaluation en anglais, disponible en anglais et en allemand ; ce lien mène à la version anglaise. Le glossaire précise les termes avant une analyse propre au produit. Les ressources gratuites de crAcken réunissent ces outils et les guides détaillés.

Sources et limites

• Règlement (UE) 2024/2847 sur EUR-Lex (s’ouvre dans un nouvel onglet) : texte du Journal officiel, notamment articles 2, 3, 7, 8, 13, 14, 31, 32, 69 et 71 ; annexes I, III, IV et VII.
• ENISA : services de vulnérabilité et plateforme unique de signalement (s’ouvre dans un nouvel onglet) : contexte des notifications et informations sur la plateforme.

Pour votre produit, consultez le texte applicable et les indications officielles actuelles. Cette introduction ne détermine ni le champ d’application, ni la nécessité de notifier un événement, ni la suffisance d’une procédure d’évaluation particulière.