Skip to main content

Table of Contents

À la recherche d’un guide de conformité au Cyber Resilience Act (CRA) ? Ne cherchez plus : voici un plan d’action en 15 étapes pour vous préparer à la plus importante réglementation européenne en matière de cybersécurité pour les produits intégrant des éléments numériques.

Ce guide a été élaboré pour accompagner les entités dont les produits sont concernés par les obligations du CRA dans leur parcours de mise en conformité, en leur fournissant une ressource claire et pratique pour naviguer à travers les exigences complexes de la réglementation. Vous y trouverez des leviers d’action concrets, qui seront à chaque fois mis en relation avec le texte officiel du Cyber Resilience Act, qui sera donc cité à maintes reprises.

Ce guide de conformité s’adresse en premier lieu aux personnes directement impliquées dans la sécurité des produits numériques, telles que les responsables de la sécurité, les Chief Technology Officers (CTO) et autres Chief Product Officers (CPO), les architectes et les équipes produits, mais aussi aux équipes juridiques et aux responsables de la GRC (Gouvernance, Risque et Conformité).

Bref, toutes les personnes qui, dans le cadre de leur travail, sont garantes, à un moment ou à un autre, de la sécurité numérique des produits réglementés mis sur le marché européen.

Vous pouvez continuer à lire ce guide en tant qu’article, ou télécharger ci-dessous une version améliorée au format PDF pour une lecture plus aisée.

Cyber Resilience Act (CRA) : Guide de conformité étape par étape

Un guide de conformité de 80 pages pour guider les gestionnaires de la sécurité et les services juridiques à travers les 21 exigences essentielles du CRA. Un ouvrage complet, sans bla-bla.

TÉLÉCHARGEZ L'E-BOOK !

Un guide de conformité qui se veut actuel et durable

Ce guide a également pour but de fournir une lecture actualisée du CRA, aussi proche que possible du texte final. En effet, le Cyber Resilience Act a fait l’objet de nombreuses révisions au cours de son parcours législatif, et la multitude de ressources disponibles sur le sujet, dont les plus anciennes sont souvent obsolètes, peut rendre difficile la compréhension et l’application de la loi.

Cet ouvrage repose donc sur la version la plus récente du CRA à ce jour, à savoir le texte adopté en première lecture par le Parlement européen le 12 mars 2024. Il est disponible sur le site du Parlement européen, et ici en français au format PDF.

Nous avons jugé ce document comme étant un matériau fiable, car il est très peu probable que des changements majeurs – si changements il y a – soient apportés au règlement avant qu’il ne soit officiellement adopté. Nous espérons ainsi proposer un guide aussi utile et durable que possible.

Par ailleurs, il convient de souligner que ce document est le résultat d’un travail personnel, qui ne saurait se substituer aux nécessaires diligences de chacun, ni aux éclairages d’un spécialiste du droit. En d’autres termes, il appartient à chacun de veiller à sa conformité, et ce document n’est pas à considérer pour plus que ce qu’il est : un guide exhaustif et rigoureux, mais sans valeur juridique aucune.

Au cours des premiers chapitres, nous aborderons quelques aspects généraux, tels que la nature et les objectifs du Cyber Resilience Act, sa date d’entrée en vigueur ou encore les amendes encourues par les contrevenants. Si ces points vous sont déjà familiers, vous pouvez passer directement au Chapitre 1. (Vous pouvez utiliser la barre de navigation à droite)

Qu’est-ce que le Cyber Resilience Act (CRA) ?

Commençons par une piqûre de rappel, qui ne peut pas faire de mal. Le Cyber Resilience Act (CRA), aussi connu sous le doux nom de Règlement (UE) 2022/0272, ou encore Loi sur la cyber-résilience en bon français, est un texte législatif de l’Union européenne qui encadre la cybersécurité des produits embarquant des éléments numériques distribués sur son territoire.

Il s’agit d’un texte majeur en matière de résilience numérique européenne, qui vient directement compléter d’autres fers de lance législatifs tels que l’IA Act (Loi européenne sur l’intelligence artificielle), mais aussi et surtout la Directive NIS2 – pour laquelle nous avons également rédigé un guide de conformité complet.


Directive NIS2 : Guide de conformité étape par étape

Un guide de 40 pages pour accompagner les RSSI, les DPO et les services juridiques dans l'application de la directive. Aucun blabla, rien que des conseils pratiques et des analyses exploitables.

TÉLÉCHARGEZ L'E-BOOK !

Le CRA constitue un tournant majeur, dans la mesure où il officialise la responsabilité des fabricants, et dans certains cas des importateurs et des distributeurs, quant au niveau de sécurité numérique des produits qu’ils mettent sur le marché. Ces derniers n’ont désormais d’autre choix que de penser et de garantir la sécurité numérique de leurs produits tout au long de leur cycle de vie, depuis les prémices de la conception jusqu’à la fin de la période de support.

Les objectifs du CRA

L’objectif du CRA est évidemment de protéger les consommateurs, mais aussi de renforcer le niveau global de résilience de l’Union. Rendre les produits numériques plus sûrs, c’est aussi réduire les risques pour tous les utilisateurs de ces produits, qu’il s’agisse de particuliers ou d’entités de première importance telles que celles réglementées par NIS2 – hôpitaux, banques, usines de production d’eau potable, services postaux, etc.

À cette fin, le Cyber Resilience Act établit :

  1. Des règles pour la mise à disposition sur le marché des produits comportant des éléments numériques afin de garantir leur cybersécurité ;
  2. Des exigences essentielles pour la conception, le développement et la production de ces produits ;
  3. Des exigences essentielles en ce qui concerne les processus de gestion des vulnérabilités mis en place par les fabricants ;
  4. Des règles et des dispositions relatives à la surveillance du marché et à son application.

Le CRA est bien entendu obligatoire, et son respect est une condition préalable au marquage CE des produits réglementés, ainsi qu’à leur distribution sur le marché européen. Il convient également de souligner que le CRA n’est pas un règlement inoffensif, mais qu’il se donne les moyens de se faire respecter, notamment par des mesures coercitives telles que des amendes, qui sont pour le moins salées.

Une vision défensive de la cybersécurité, calquée sur le Cybersecurity Act

Avant d’aller plus loin, il nous semble important de faire un point sur la notion de “cybersécurité” au sens où elle est entendue par le CRA.

L’Article 3 du Cyber Resilience Act précise que le terme “cybersécurité” est entendu au même sens que celui donné à l’Article 2 du Règlement 2019/881, qui n’est autre que le Cybersecurity Act (CSA), à savoir :

“La ‘cybersécurité’ désigne les activités nécessaires pour protéger les réseaux et les systèmes d’information, les utilisateurs de ces systèmes et les autres personnes concernées par les cybermenaces.” – Cybersecurity Act, Article 2

Le CRA adopte donc une définition défensive de la cybersécurité : il est question de défendre les produits, de les protéger des éventuelles menaces. Gardez donc en tête que “cybersécurité” sera par la suite synonyme de posture défensive – même si les approches offensives comme les tests d’intrusion y trouveront leur place, notamment pour évaluer la sécurité des produits et l’efficacité des mesures défensives.

Et la résilience numérique dans tout ça ?

Certains pourraient s’étonner de ce choix sémantique, à l’heure où le terme “résilience numérique” fleurit dans les différentes législations européennes, de l’intitulé du Cyber Resilience Act (CRA) au Digital Operational Resilience Act (DORA) qui régit le secteur financier.

En effet, la résilience est une notion qui va bien au-delà de la simple protection des actifs. Elle ne se cantonne pas à la simple défense, mais vise la résistance, la continuité des activités même sous un feu nourri. Mais il est important de comprendre que, contrairement à NIS2 ou DORA, le CRA réglemente des produits et non des entités. Cette distinction est fondamentale.

On peut attendre d’une banque ou d’une centrale nucléaire qu’elle soit résiliente, c’est-à-dire capable d’assurer la continuité de ses activités et de ses services même en cas d’attaque – de là à parler de PRA et PCA , il n’y a qu’un pas – afin d’épargner à l’Union européenne des effets systémiques désastreux. Mais on ne peut raisonnablement pas attendre la même chose d’une montre connectée ou d’un babyphone.

En revanche, on peut attendre d’un produit IoT qu’il soit opérationnel de manière à remplir sa fonction, et qu’il ne soit pas compromis afin de ne pas mettre en danger ses utilisateurs. En effet, du point de vue de l’attaquant, la compromission d’un produit connecté n’est jamais une fin en soi, mais toujours un moyen d’atteindre sa cible : l’utilisateur, qu’il s’agisse d’un particulier ou d’une organisation sensible.

En améliorant la sécurité des produits embarquant du numérique, le CRA contribue de fait à renforcer la résilience numérique de tous les utilisateurs, et par là même de l’ensemble de l’écosystème européen. Avec le Cyber Resilience Act, la cybersécurité défensive est au service de la résilience numérique.

Quand le CRA entrera-t-il en application ?

Ici, il faut se référer à l’Article 71 du règlement pour trouver la réponse. Le Cyber Resilience Act entrera en application 3 ans (36 mois) après sa publication au Journal officiel de l’Union européenne.

L’adoption et la publication du CRA sont attendues dans le courant de l’année 2024, ce qui amène à une date butoir de mise en conformité en 2027 pour les produits réglementés. Il convient de rappeler que le CRA est un règlement européen et qu’à ce titre, il sera applicable en l’état dans tous les pays membres de l’UE (à l’inverse d’une directive, comme NIS2, qui doit être transposée dans le droit national de chaque pays).

Une obligation de signaler les incidents et les vulnérabilités exploitées dès 2026

Il existe deux exceptions à ce délai de trois ans, clairement énoncées à l’Article 71 et au considérant 127.

Tout d’abord, la date d’application est fixée à 21 mois pour les obligations de signalement des incidents graves et des vulnérabilités activement exploitées – deux notions sur lesquelles nous reviendrons – à l’ENISA (Agence de l’Union européenne pour la cybersécurité) et aux CSIRT (Computer Security Incident Response Team) nationaux. Le CRA étant prévu pour 2024, les notifications aux autorités seront obligatoires dès 2026.

La deuxième exception porte sur les dispositions relatives à la notification des organismes d’évaluation de la conformité, qui seront effectives 18 mois après la publication du CRA. Nous ne nous attarderons pas sur ce point, car il concerne davantage les auditeurs que les fabricants.

Les sanctions et amendes prévues par le Cyber Resilience Act

Le Cyber Resilience Act entend bien se faire respecter, et il s’accompagne donc de sanctions pour les mauvais élèves. Et comme souvent, le meilleur moyen de dissuasion est de frapper là où ça fait mal : au portefeuille. L’Article 64 du CRA prévoit un certain nombre d’amendes administratives, qui peuvent s’ajouter à toute autre mesure corrective ou restrictive décidée par les autorités de surveillance du marché. Ces dernières peuvent également ordonner le retrait d’un produit du marché si des raisons de sécurité l’exigent.

Jusqu’à 15 M€ ou 2,5% du chiffre d’affaires mondial

Le montant de l’amende dépend principalement de deux facteurs : la structure en tort et l’objet de la non-conformité. Une start-up ne sera pas pénalisée de la même manière qu’une multinationale, et une faute portant sur la sécurité des produits sera plus lourdement sanctionnée qu’un manquement administratif. C’est somme toute assez logique.

Tous les éléments de conformité ci-dessous peuvent sembler assez vagues si vous n’êtes pas (encore) familiarisé avec le règlement, mais rassurez-vous, nous les expliquerons tout au long de ce guide.

En cas de non-respect des exigences essentielles du règlement, des obligations de notification des incidents et des vulnérabilités ou des autres obligations qui leur incombent, les fabricants sont passibles d’une amende pouvant aller jusqu’à 15 millions d’euros ou 2,5% du chiffre d’affaires annuel mondial total de l’exercice précédent, le montant le plus élevé étant retenu.

Pour leur part, les mandataires, les importateurs, les distributeurs, les organismes d’évaluation et leurs sous-traitants qui contreviennent à leurs obligations encourent des amendes pouvant aller jusqu’à 10 millions d’euros ou 2% du chiffre d’affaires annuel mondial total, là encore le montant le plus élevé étant retenu.

Ce deuxième barème s’applique également à tous les acteurs lorsque la non-conformité concerne des obligations relatives à la déclaration UE de conformité, à la documentation technique, aux règles d’apposition du marquage CE, à l’évaluation de la conformité ou à l’accès aux données et à la documentation.

Enfin, la fourniture d’informations inexactes, incomplètes ou trompeuses aux organismes notifiés ou aux autorités de surveillance du marché peut faire l’objet d’une amende pouvant aller jusqu’à 5 millions d’euros ou 1% du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu.

Les exceptions : logiciels open-source, micro-entreprises et PME

L’Article 64.10 du Cyber Resilience Act prend soin de noter deux exceptions à ces régimes de sanction.

Premièrement, les fabricants considérés comme des micro ou petites entreprises ne peuvent pas être sanctionnées financièrement en cas de manquement aux délais de signalement des incidents graves et des vulnérabilités activement exploitées (voir Chapitre 10).

Deuxièmement, les administrateurs de logiciels open-source ne peuvent pas faire l’objet de sanctions financières, quelle que soit la violation du Cyber Resilience Act.

Tout ceci étant dit, nous pouvons désormais passer au cœur de ce guide, à savoir les différentes démarches à entreprendre pour se mettre en conformité.

1. Vérifiez si vos produits sont réglementés par le Cyber Resilience Act

En tant que fabricant, la première chose à faire est de savoir quels sont les produits réglementés par le Cyber Resilience Act. À cet égard, l’Article 2 est on ne peut plus clair :

Le présent règlement s’applique aux produits comportant des éléments numériques mis à disposition sur le marché, dont l’usage prévu ou raisonnablement prévisible inclut une connexion logique ou physique, directe ou indirecte, à un dispositif ou à un réseau.– CRA, Article 2.1

Oui, le CRA concerne donc énormément de produits ; c’est précisément pour cette raison qu’il est un texte législatif incontournable en matière de cybersécurité. Et pour peu que vous ayiez encore un peu d’espoir de lui échapper, l’Article 3 précise la définition de “produits comportant des éléments numériques” – que l’on abrègera le plus souvent par “produits” dans la suite de ce guide.

“‘Produit comportant des éléments numériques’ : tout produit logiciel ou matériel et ses solutions de traitement des données à distance, y compris les composants logiciels ou matériels devant être mis sur le marché séparément.” – CRA, Article 3

Cette définition est importante, car elle confirme que toutes les solutions logicielles qui vont de pair avec un produit réglementé entrent également dans le champ d’application du CRA. Les plateformes SaaS et autres applications mobiles qui accompagnent les produits IoT sont donc assujetties aux mêmes obligations, comme celles qui sont associées aux montres et balances connectées par exemple. À l’inverse, une plateforme SaaS qui n’est adossée à aucun produit n’est pas concernée par le CRA (mais elle peut l’être par la Directive NIS2).

La liste des exceptions

L’Article 2 fait état de rares exceptions, mais qu’il vaut mieux avoir en tête. Sont donc exclus du périmètre du CRA :

  • Les dispositifs médicaux professionnels soumis aux règlements (EU) 2017/745 et (EU) 2017/746 ;
  • Les véhicules à moteurs et leurs remorques ainsi que leurs systèmes, composants et entités techniques distinctes qui sont dans le scope du règlement (EU) 2019/2144 ;
  • Les systèmes d’aviation civile et les équipements marins, respectivement régis par les règlements (EU) 2018/1139 et 2014/90/EU ;
  • Les éléments numériques développés ou modifiés exclusivement à des fins de sécurité ou de défense nationale.

Les quatre catégories de produits réglementées par le CRA

Le Cyber Resilience Act distingue quatre catégories parmi les produits embarquant du numérique qu’il réglemente :

  • La catégorie par défaut, qui n’est pas mentionnée en tant que telle, mais qui existe de facto. Elle comprend tous les produits qui répondent aux définitions générales données précédemment ;
  • Les produits importants de Classe I ;
  • Les produits importants de Classe II;
  • Les produits critiques.

Il est essentiel de bien comprendre cette classification, car elle détermine, entre autres, la procédure d’évaluation de la conformité attendue pour chaque produit. Ainsi, plus le produit est critique, plus l’évaluation sera rigoureuse – comprenez ici l’intervention d’un auditeur tiers.

Les quatre catégories de produits réglementées par le Cyber Resilience Act (CRA)

Les produits importants

Les produits importants sont ordonnés en deux classes : la Classe I et la Classe II, toutes deux détaillées dans l’Annexe III du règlement, que nous examinerons ci-dessous.

Selon l’Article 7 du CRA, un produit est considéré comme important s’il répond à au moins l’un des deux critères suivants :

  • Le produit remplit principalement des fonctions essentielles à la cybersécurité d’autres produits, réseaux ou services, y compris la sécurisation des authentifications et des accès, la prévention et la détection des intrusions, la sécurité des endpoints ou la protection des réseaux ;
  • Le produit remplit une fonction qui comporte un risque significatif d’effets néfastes par son intensité et sa capacité à perturber, contrôler ou endommager un grand nombre d’autres produits ou la santé, la sécurité ou la sûreté de ses utilisateurs par une manipulation directe, telle qu’une fonction de système central, y compris la gestion du réseau, la gestion de configuration, la virtualisation ou le traitement de données à caractère personnel.

Ce n’est évidemment pas aux fabricants de décider si leurs produits sont importants ou non, le CRA ayant pris soin de dresser une liste exhaustive, bien que généraliste. Par ailleurs, l’Article 7 exige que la Commission européenne précise les descriptions techniques des catégories de produits importants et critiques dans un délai de 12 mois à compter de la publication du règlement.

Notons également que la Commission européenne peut modifier l’Annexe III comme bon lui semble, et ainsi ajouter, supprimer ou déplacer une catégorie de produits d’une classe à l’autre. Le cas échéant, la règle générale est d’observer une période de transition de 12 mois avant que les nouvelles règles ne s’appliquent.

Enfin, le CRA souligne qu’un produit qui intègre un produit important n’est pas systématiquement important en soi, et n’est donc pas nécessairement soumis aux mêmes obligations d’évaluation de la conformité.

La liste des produits importants de Classe I

Les produits importants de la Classe I sont détaillés dans l’Annexe III du CRA. La liste exacte est reproduite ci-dessous, bien que traduite par nos soins.

Les produits importants de Classe I sont :

  1. Les systèmes de gestion de l’identité et les logiciels et matériels de gestion des accès privilégiés, y compris les dispositifs d’authentification et de contrôle d’accès, dont les lecteurs biométriques ;
  2. Les navigateurs autonomes et intégrés ;
  3. Les gestionnaires de mots de passe ;
  4. Les logiciels qui recherchent, suppriment ou mettent en quarantaine les logiciels malveillants ;
  5. Les produits contenant des éléments numériques avec la fonction de réseau privé virtuel (VPN) ;
  6. Les systèmes de gestion de réseau ;
  7. Les systèmes de gestion des informations et des événements de sécurité (SIEM) ;
  8. Les gestionnaires de démarrage (boot managers) ;
  9. Les infrastructures à clés publiques et les logiciels d’émission de certificats numériques ;
  10. Les interfaces de réseau physiques et virtuelles ;
  11. Les systèmes d’exploitation ;
  12. Les routeurs et les modems destinés à la connexion à l’internet, ainsi que les commutateurs ;
  13. Les microprocesseurs dotés de fonctionnalités liées à la sécurité ;
  14. Les microcontrôleurs dotés de fonctionnalités liées à la sécurité ;
  15. Les circuits intégrés spécialisés (ASIC) et les réseaux de portes programmables (FPGA) dotés de fonctionnalités liées à la sécurité ;
  16. Les assistants virtuels polyvalents pour maison intelligente (smart home) ;
  17. Les produits pour maison intelligente avec des fonctionnalités de sécurité, y compris les serrures de porte intelligentes, les caméras de sécurité, les systèmes de surveillance des bébés et les systèmes d’alarme ;
  18. Les jouets connectés à l’internet couverts par la Directive 2009/48/CE qui ont des fonctions sociales interactives (par exemple, parler ou filmer) ou qui ont des fonctions de géolocalisation ;
  19. Les produits personnels à porter ou à placer sur un corps humain qui ont une finalité de surveillance de la santé (comme le suivi) ou les produits personnels à porter qui sont destinés à être utilisés par et pour les enfants. (NDLR : sont exclus les dispositifs médicaux professionnels régis par les règlements (UE) 2017/745 et (UE) 2017/746).

La liste des produits importants de Classe II

Les produits importants de Classe II sont :

  1. Les hyperviseurs et les systèmes d’exécution de conteneurs qui prennent en charge l’exécution virtualisée de systèmes d’exploitation et d’environnements similaires ;
  2. Les pare-feu, les systèmes de détection et/ou de prévention des intrusions ;
  3. Les microprocesseurs dits “tamper-resistant” (anti-sabotage) ;
  4. Les microcontrôleurs dits “tamper-resistant” (anti-sabotage).

Les produits critiques

La classification critique des produits est la plus élevée de toutes celles établies par le CRA. Sans surprise, les produits appartenant aux catégories désignées sont ceux soumis aux obligations les plus strictes en matière d’évaluation de la conformité.

Pour savoir ce qui fait qu’un produit est critique, il faut se référer à l’Article 8 du CRA. Celui-ci dispose qu’une catégorie de produits peut être considérée comme critique si, en plus des critères relatifs aux produits importants, elle apparaît comme telle au regard des deux évaluations suivantes :

  • La mesure dans laquelle il existe une dépendance critique des entités essentielles visées à l’Article 3 de la Directive (UE) 2022/2555 – alias NIS2 – vis-à-vis de cette catégorie de produits ;
  • La mesure dans laquelle les incidents et les vulnérabilités exploitées concernant cette catégorie des produits peuvent entraîner de graves perturbations des chaînes d’approvisionnement critiques dans l’ensemble du marché intérieur.

Derrière ces formulations quelque peu sibyllines se cachent en réalité deux obsessions de la Directive NIS2 :

  • Protéger les entités essentielles, celles dont la défaillance pourrait avoir des effets systémiques au sein de l’UE, à l’image des acteurs du transport, de l’énergie ou de la santé. Si vous souhaitez en savoir plus sur les Entités Essentielles (EE), vous pouvez vous référer à la section correspondante de notre guide de conformité NIS2 ;
  • Sécuriser la chaîne d’approvisionnement, ces fameux prestataires de services qui, lorsqu’ils sont numériquement fragiles, représentent un vecteur d’attaque privilégié contre les entités qui travaillent avec eux. Si vous n’êtes pas familier avec le sujet, nous vous conseillons de vous pencher sur la cyberattaque contre SolarWinds, qui est aujourd’hui un cas d’école en matière de “supply chain attack”.

Dès lors, il est compréhensible que les produits jugés critiques par le CRA soient ceux qui présentent un risque pour les entités vitales au bon fonctionnement de l’Union, ou qui sont susceptibles de mettre en péril les chaînes d’approvisionnement les plus importantes.

La liste des produits critiques

Il convient de noter ici que la liste ci-dessous n’est pas gravée dans le marbre, puisque, comme pour les produits importants, la Commission européenne est libre de la modifier à sa guise par le biais d’actes délégués. Dans ce cas, la règle générale est d’observer une période de transition de 6 mois avant l’application des nouvelles règles.

Les produits critiques sont listés dans l’Annexe IV du CRA, à savoir :

  • Les cartes à puce ou dispositifs similaires, y compris les éléments sécurisés ;
  • Les dispositifs matériels avec boîtiers de sécurité (NDLR : les produits de type lecteurs sécurisés de cartes à puce, tachygraphes, Hardware Security Modules (HSM), etc.) ;
  • Les passerelles de compteurs intelligents au sein des systèmes de comptage intelligents tels que définis à l’Article 2.23, de la Directive (UE) 2019/944, et autres dispositifs à des fins de sécurité avancée, y compris pour le traitement cryptographique sécurisé.

Le dernier point étant pour le moins opaque, nous nous permettons d’ouvrir une parenthèse. La Directive (EU) 2019/944 dont il est question est une législation européenne du 5 juin 2019 concernant des règles communes pour le marché intérieur de l’électricité. Elle définit un “système intelligent de mesure” comme suit :

“‘Un système électronique qui est capable de mesurer l’électricité injectée dans le réseau ou l’électricité consommée depuis le réseau en fournissant davantage d’informations qu’un compteur classique, et qui est capable de transmettre et de recevoir des données à des fins d’information, de surveillance et de contrôle en utilisant une forme de communication électronique.” – Directive (EU) 2019/944 , Article 2.23

2. Prenez connaissance des 21 exigences essentielles en matière de cybersécurité

On attaque ici un gros morceau du règlement ; si vous voulez vous servir un café, c’est le moment.

Le Cyber Resilience Act fixe des exigences essentielles – un doux euphémisme pour parler d’obligations – pour tous les produits réglementés et leurs fabricants. Elles sont détaillées dans l’Annexe I du règlement, qui sera régulièrement citée par la suite.

Les exigences essentielles du CRA se décomposent en deux parties :

  1. Les exigences en matière de cybersécurité des produits. Il s’agit ici du niveau de sécurité et des caractéristiques intrinsèques des produits ;
  2. Les exigences en matière de gestion des vulnérabilités. Il s’agit ici des mesures et des processus mis en œuvre par les fabricants.

Nous attirons votre attention sur le fait que ces exigences sont absolument cruciales. Elles sont au cœur du Cyber Resilience Act, et c’est leur mise en œuvre qui déterminera si un produit sera considéré comme conforme ou non. L’Article 6 du CRA dispose d’ailleurs que seuls les produits qui respectent TOUTES ces obligations peuvent être mis sur le marché européen.

Par conséquent, la mise en œuvre de ces exigences devrait être votre feuille de route pour la conformité au Cyber Resilience Act, votre lumière dans la nuit lorsque vous vous sentirez perdu face à l’ampleur de la tâche.

Ces exigences sont également la pierre angulaire du document que vous tenez entre les mains. Dans ce chapitre, nous les énumérerons telles qu’elles sont énoncées dans le règlement, puis nous reviendrons plus en détail sur chacune d’entre elles au fur et à mesure de la progression du guide. Il faut garder à l’esprit que le CRA est un texte de loi et non un manuel de spécifications techniques, si bien que certaines exigences peuvent sembler pour le moins opaques ou généralistes à la première lecture.

Les 13 exigences du CRA en matière de cybersécurité des produits

La première partie des exigences essentielles du CRA est consacrée aux propriétés des produits, lesquelles doivent garantir un niveau de sécurité intrinsèque solide. Le texte est on ne peut plus clair :

“Les produits comportant des éléments numériques doivent être conçus, développés et produits de manière à garantir un niveau approprié de cybersécurité en fonction des risques.” – CRA, Annexe I

Chose importante, les produits IoT doivent donc être sécurisés au regard des risques qui leur sont associés. Ces derniers sont à déterminer au moyen d’une évaluation des risques cyber (voir Chapitre 5), à la charge du fabricant et à réaliser en amont de la conception.

Les produits doivent satisfaire à une liste de 13 exigences essentielles en matière de cybersécurité (Source : Annexe I, Partie 1) :

  1. Être mis à disposition sur le marché sans vulnérabilité exploitable connue ;
  2. Être mis à disposition sur le marché avec une configuration sécurisée par défaut, sauf accord contraire entre le fabricant et l’utilisateur professionnel pour un produit sur mesure, avec la possibilité de réinitialiser le produit à son état d’origine ;
  3. Garantir que les vulnérabilités peuvent être corrigées par des mises à jour de sécurité, y compris, le cas échéant, par des mises à jour de sécurité automatiques installées dans un délai approprié, activées par défaut, avec un système d’opt-out clair et facile à utiliser, en notifiant aux utilisateurs les mises à jour disponibles et en leur offrant la possibilité de les reporter temporairement ;
  4. Assurer la protection contre les accès non autorisés au moyen de mécanismes de contrôle appropriés, y compris mais sans s’y limiter, des systèmes d’authentification, de gestion de l’identité ou de l’accès, ainsi que signaler les éventuels accès non autorisés ;
  5. Protéger la confidentialité des données stockées, transmises ou traitées d’une autre manière, qu’elles soient personnelles ou autres, notamment en chiffrant les données pertinentes au repos ou en transit au moyen de mécanismes conformes à l’état de l’art, et en utilisant d’autres moyens techniques ;
  6. Protéger l’intégrité des données stockées, transmises ou traitées d’une autre manière, qu’elles soient personnelles ou autres, des commandes, des programmes et de la configuration contre toute manipulation ou modification non autorisée par l’utilisateur, ainsi que signaler les corruptions ;
  7. Ne traiter que des données, personnelles ou autres, qui sont adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité du produit (“minimisation des données”) ;
  8. Protéger la disponibilité des fonctions essentielles et basiques, y compris après un incident, notamment par des mesures de résilience et d’atténuation des attaques par déni de service (DDoS) ;
  9. Minimiser l’impact négatif des produits eux-mêmes ou des dispositifs connectés sur la disponibilité des services fournis par d’autres dispositifs ou réseaux ;
  10. Être conçus, développés et produits de manière à limiter les surfaces d’attaque, y compris les interfaces externes ;
  11. Être conçus, développés et produits de manière à réduire l’impact d’un incident à l’aide de mécanismes et de techniques d’atténuation de l’exploitation appropriés ;
  12. Fournir des informations relatives à la sécurité en enregistrant et/ou en surveillant l’activité interne pertinente, notamment l’accès aux données, services ou fonctions ou leur modification, avec un système d’opt-out pour l’utilisateur ;
  13. Donner la possibilité aux utilisateurs de supprimer de manière sûre, simple et permanente toutes les données et tous les paramètres et, lorsque ces données peuvent être transférées à d’autres produits ou systèmes, veiller à ce que cela se fasse de manière sécurisée.

Les 8 exigences du CRA en matière de gestion des vulnérabilités

La deuxième partie des exigences essentielles du CRA concerne les obligations des fabricants en matière de gestion des vulnérabilités. Celles-ci sont tout aussi importantes que les exigences applicables aux produits, et leur mise en œuvre conditionne aussi la mise sur le marché.

Les fabricants d’un produit réglementé par le CRA doivent satisfaire aux 8 exigences de gestion des vulnérabilités suivantes (Source : Annexe I, Partie 2) :

  1. Identifier et documenter les vulnérabilités et les composants contenus dans le produit, notamment en établissant une nomenclature logicielle – SBOM (Software Bill Of Materials) – dans un format couramment utilisé et lisible par une machine, couvrant au minimum les dépendances de premier niveau du produit ;
  2. En ce qui concerne les risques posés par les produits comportant des éléments numériques, remédier sans délai aux vulnérabilités, notamment en fournissant des mises à jour de sécurité. Lorsque cela est techniquement possible, les nouvelles mises à jour de sécurité sont fournies séparément des mises à jour de fonctionnalité ;
  3. Appliquer des tests et des examens efficaces et réguliers de la sécurité du produit ;
  4. Une fois qu’une mise à jour de sécurité a été mise à disposition, partager et divulguer publiquement des informations sur les vulnérabilités corrigées, y compris une description des vulnérabilités, des informations permettant aux utilisateurs d’identifier le produit affecté, les impacts des vulnérabilités, leur gravité et des informations claires et accessibles aidant les utilisateurs à remédier aux vulnérabilités. Dans des cas dûment justifiés, lorsque les fabricants considèrent que les risques de sécurité de la divulgation l’emportent sur les avantages en matière de sécurité, ils peuvent retarder la diffusion des informations concernant une vulnérabilité corrigée jusqu’à ce que les utilisateurs aient eu la possibilité d’appliquer le correctif correspondant ;
  5. Mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités (CVD pour Coordinated Vulnerability Disclosure) ;
  6. Prendre des mesures pour faciliter le partage d’informations sur les vulnérabilités potentielles de leur produit et des éléments tiers contenus dans ce produit, en fournissant notamment une adresse de contact pour le signalement des vulnérabilités découvertes ;
  7. Prévoir des mécanismes de distribution sécurisée des mises à jour des produits afin de garantir que les vulnérabilités sont corrigées ou atténuées en temps utile et, quand applicable, d’une manière automatique ;
  8. Veiller à ce que les mises à jour de sécurité disponibles soient diffusées sans délai (sauf accord contraire entre le fabricant et l’utilisateur professionnel dans le cas d’un produit sur mesure), gratuitement et accompagnées de messages informatifs fournissant aux utilisateurs les informations pertinentes, y compris sur les éventuelles mesures à prendre.

3. Examinez les cas particuliers : importateurs, distributeurs et logiciels libres

Les 21 exigences susmentionnées s’appliquent aux fabricants de produits réglementés par le Cyber Resilience Act. Mais le règlement prend également soin de combler les angles morts, en précisant les obligations applicables aux importateurs, aux distributeurs et aux administrateurs de logiciels libres. Si ces cas particuliers ne vous concernent pas, vous pouvez passer directement au chapitre suivant.

Les obligations des importateurs

Le règlement consacre l’intégralité de son Article 19 aux obligations des importateurs. Il est évident qu’ils ont l’interdiction absolue de mettre sur le marché des produits qui ne sont pas conformes aux 13 exigences essentielles de cybersécurité, ou dont les fabricants n’appliquent pas les 8 exigences essentielles en matière de gestion des vulnérabilités. L’application de toutes ces exigences reste de la responsabilité des fabricants.

Avant de mettre sur le marché, l’importateur doit veiller à ce que :

  1. Les procédures d’évaluation de la conformité ont été menées à bien par le fabricant ;
  2. Le fabricant a établi la documentation technique ;
  3. Le produit porte le marquage CE, en plus d’être accompagné de la déclaration UE de conformité, ainsi que des informations et instructions à destination des utilisateurs ;
  4. Le produit porte un numéro de type, de lot ou de série ou tout autre élément permettant son identification. Lorsque cela n’est pas possible, cette information doit être fournie sur l’emballage ou dans un document accompagnant le produit ;
  5. Le fabricant ET l’importateur ont tous deux indiqué leur nom, leur raison sociale ou leur marque déposée, ainsi que l’adresse postale, électronique ou de site web à laquelle ils peuvent être respectivement contactés. Ces informations doivent figurer sur le produit, sur son emballage ou dans un document l’accompagnant ;
  6. Le fabricant a veillé à ce que la date de fin de la période de support, notamment le mois et l’année, soit précisée au moment de l’achat, d’une manière claire, compréhensible et aisément accessible et, selon le cas, sur le produit, son emballage ou par des moyens numériques.

Les importateurs doivent être en mesure de fournir tous les documents nécessaires prouvant le respect des exigences énoncées ci-dessus. Par ailleurs, si un importateur prend connaissance d’une vulnérabilité dans un produit, il est bien évidemment tenu d’en informer les autorités compétentes.

Les obligations des distributeurs

Pour les obligations qui incombent aux distributeurs, c’est vers l’Article 20 du CRA qu’il faut se tourner. Comme pour les importateurs, il s’agit surtout de vérifier que la paperasserie est en ordre. Les distributeurs doivent donc “agir avec la diligence requise”, vérifier que le produit porte bien le marquage CE et que le fabricant et l’importateur ont bien respecté tous les points de la liste ci-dessus.

Les produits en marque blanche

Exception notable : un importateur ou un distributeur est considéré comme un fabricant quand il met sur le marché un produit “sous son propre nom ou sa propre marque”, ou lorsqu’il apporte une “modification substantielle” à un produit déjà sur le marché. (Article 21) Toutes les obligations incombant aux fabricants s’appliquent alors.

Il en va de même pour toute personne physique ou morale autre que le fabricant, l’importateur ou le distributeur qui apporte une modification substantielle à un produit et le met à disposition sur le marché européen. (Article 22)

Les logiciels open source

Le logiciel libre a été un sujet majeur tout au long du processus d’élaboration du Cyber Resilience Act, suscitant de nombreuses levées de boucliers de la part des acteurs de l’open source.

Les premières versions du règlement menaçaient directement le modèle en engageant la responsabilité des créateurs, au point que la communauté craignait un “effet dissuasif” sur le développement des logiciels – libres ou non, les seconds dépendant souvent des premiers. En effet, il ne faut pas penser qu’il y a d’un côté les logiciels libres et de l’autre les logiciels sous licence. En réalité, les deux coexistent pour former l’écosystème logiciel que nous connaissons aujourd’hui, dans une sorte de symbiose profitable à tout le monde.

L’inquiétude était telle qu’en avril 2023, la Fondation Eclipse – qui compte parmi ses membres de grands noms tels que Google, IBM, Oracle et Microsoft – publiait une lettre ouverte à la Commission européenne, cosignée par de nombreux acteurs comme la Fondation Linux Europe ou le CNLL français.

Heureusement, la Commission européenne a pris soin de se concerter avec les représentants de l’open source, et la dernière version semble satisfaire tout le monde.

Quels sont les logiciels open source concernés par le CRA ?

Avant toute chose, définissons ce qu’est un logiciel open source au regard du CRA :

“‘Logiciel libre et ouvert’: un logiciel dont le code source est partagé de manière ouverte et qui est mis à disposition sous licence libre et ouverte prévoyant qu’il soit librement accessible, utilisable, modifiable et redistribuable pour tous ses droits.” – CRA, Article 3.48

Examinons ensuite le considérant 18, qui précise que “seuls les logiciels libres et ouverts mis à disposition sur le marché, donc fournis pour être distribués ou utilisés dans le cadre d’une activité commerciale, devraient relever du champ d’application du présent règlement.” Il est donc clair que les logiciels libres qui ne font pas partie d’une activité commerciale ne sont pas concernés par le CRA.

Reste à savoir ce qui caractérise une activité commerciale au sens de la réglementation… Sur ce point, le considérant 15 apporte un éclairage bienvenu.

La fourniture dans le cadre d’une activité commerciale peut être caractérisée par :

  • Le prix facturé pour un produit ;
  • Le prix des services d’assistance technique lorsqu’il ne sert pas uniquement à récupérer les coûts réels ;
  • Une intention de monétisation, par exemple par la fourniture d’une plateforme logicielle par l’intermédiaire de laquelle le fabricant monétise d’autres services ;
  • L’exigence, comme condition à l’utilisation, du traitement des données à caractère personnel pour des raisons autres qu’aux seules fins d’améliorer la sécurité, la compatibilité ou l’interopérabilité du logiciel ;
  • L’acceptation de dons supérieurs aux coûts associés à la conception, au développement et à la fourniture du produit.

Si le logiciel répond à l’un de ces critères, il est visé par le Cyber Resilience Act. A l’inverse, précisons que les éléments suivants ne peuvent pas suffire à caractériser une activité commerciale :

  • “Le fait d’accepter des dons sans intention lucrative” (Considérant 15) ;
  • “La fourniture dans le cadre d’une prestation de service pour laquelle une rétribution est perçue à la seule fin de récupérer les coûts réels directement liés au fonctionnement de ce service, comme ce peut être le cas de certains produits fournis par des entités de l’administration publique.” (Considérant 16) ;
  • “La fourniture de produits qui répondent aux critères de logiciels libres et ouverts qui ne sont pas monétisés par leur fabricant.” (Considérant 18)
  • Le simple fait qu’un fabricant verse un soutien financier à un logiciel libre ou qu’il contribue au développement d’un tel produit” (Considérant 18) ;
  • L’existence de mises à jour régulières. (Considérant 18)
  • Le développement par des organisations à but non lucratif, “pour autant que l’organisation concernée ait été créée de telle façon que tous les bénéfices sont utilisés pour atteindre des objectifs non lucratifs.” (Considérant 18)

Enfin, le CRA précise que les éléments suivants ne sont pas considérés comme une mise à disposition sur le marché :

  • La fourniture d’un produit open source destiné à être intégré par d’autres fabricants à leurs propres produits SAUF SI “le composant est monétisé par son fabricant d’origine.” (Considérant 18) Il est donc possible de distribuer un logiciel libre sans avoir à s’inquiéter s’il venait à être monétisé par quelqu’un d’autre.
  • Le seul fait d’héberger des produits sur des répertoires ouverts, y compris par l’intermédiaire de gestionnaires de packages ou de plateformes collaboratives” (Considérant 20) Il est donc possible d’agréger et mettre à disposition d’autres projets libres sans être considéré comme un distributeur – à moins qu’il n’y ait une intention commerciale, évidemment.

Le statut d’administrateur de logiciels libres

Maintenant, qu’en est-il des organisations qui développent et maintiennent des logiciels libres à des fins commerciales ? Le CRA a pris soin de leur créer un statut à part, celui d’administrateur de logiciels libres, dont voici la définition :

“‘Administrateur de logiciels libres’ : une personne morale, autre que le fabricant, qui a pour objectif ou finalité de fournir un soutien systématique et continu au développement de produits spécifiques comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts et sont destinés à des activités commerciales, et qui assure la viabilité de ces produits.” – CRA, Article 3.14

Il ne fait aucun doute que ce sont les grandes fondations et structures de la communauté open source, telles que les fondations Linux, Mozilla et Eclipse, et leurs administrateurs qui sont visés. Les petites mains qui apportent leur brique au monde de l’open source sont épargnées :

Le présent règlement ne s’applique pas aux personnes physiques ou morales qui contribuent, sous forme de code source, à des produits comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts ne relevant pas de leur responsabilité.” – CRA, Considérant 18

Quant aux administrateurs, rappelons qu’ils ne peuvent être condamnés à des amendes pour quelque infraction que ce soit au Cyber Resilience Act.

Les obligations des administrateurs de logiciels open source

Après cette longue mais nécessaire digression sur le cas particulier de l’open source, il est temps de se pencher sur les obligations spécifiques qui incombent aux administrateurs, détaillées dans l’Article 24.

Les administrateurs de logiciels open source doivent mettre en place et documenter de manière vérifiable une politique de cybersécurité. Cette dernière doit favoriser les développements sécurisés, ainsi que la gestion efficace des vulnérabilités par les développeurs. Cette politique doit “comprendre, en particulier, des aspects liés à la documentation, au traitement et à la correction des vulnérabilités, ainsi qu’à la promotion du partage d’informations sur les vulnérabilités découvertes au sein de la communauté des logiciels libres.”

Cette politique de cybersécurité doit être tenue à la disposition de toute autorité de surveillance du marché qui en fait la demande, en vue de parer à un éventuel risque de sécurité. La coopération de l’administrateur tout au long de la manœuvre sera bien entendu requise.

Par ailleurs, l’Article 24.3 dispose que les administrateurs sont soumis aux mêmes exigences de signalement qui s’appliquent aux fabricants, à savoir :

  • Pour les vulnérabilités activement exploitées, dès lors qu’ils participent au développement des produits concernés ;
  • Pour les incidents graves dès lors qu’ils touchent les réseaux et les systèmes d’information fournis pour le développement des produits affectés.

Nous ne détaillerons pas plus ici, puisque toutes ces exigences relatives à la notification des vulnérabilités exploitées et des incidents graves font l’objet du Chapitre 10 de ce guide.

Enfin, l’Article 25 du Cyber Resilience Act ouvre la voie à “des programmes volontaires d’attestation de sécurité” qui permettront d’évaluer la sécurité des logiciels open source. Il y a tout lieu de croire que ces programmes seront réalisés conjointement par le régulateur et les principales fondations open source.

Une partie de la communauté a déjà fait savoir qu’elle travaillait à l’élaboration de processus communs de cybersécurité pour la mise en conformité avec le CRA. Parmi les signataires se trouvent les fondations Apache, Blender, OpenSSL, PHP, Python, Rust et Eclipse – que du beau monde.

4. Préparez une documentation technique pour chaque produit mis sur le marché

Revenons à nos moutons : les obligations qui incombent aux fabricants de produits réglementés par le CRA. La production d’une documentation technique pour accompagner chaque produit est une condition sine qua non pour sa commercialisation en Europe. On ne fait que paraphraser le texte officiel :

“Avant de mettre sur le marché un produit comportant des éléments numériques, les fabricants établissent la documentation technique visée à l’Article 31.” – CRA, Article 13.12

L’Article 31 en question dispose que la documentation doit contenir toutes les informations qui démontrent le produit et les processus mis en place par le fabricant sont conformes aux exigences essentielles du CRA. Oui, toutes. Plus précisément, elle doit inclure au minimum tous les éléments listés dans l’Annexe VII (cf. ci-dessous).

Une excellente feuille de route pour la mise en conformité

La préparation de la documentation technique est l’une des dernières étapes du processus de mise en conformité, précisément parce qu’elle doit contenir les informations nécessaires pour prouver que les étapes précédentes ont été réalisées dans les règles de l’art. Néanmoins, nous avons pensé qu’il serait judicieux de la présenter assez tôt dans ce guide.

En effet, puisqu’elle énumère à peu près tout ce qui doit être fait, la documentation technique constitue une excellente feuille de route pour la mise en conformité avec le CRA. Aussi, nous ne pouvons que vous conseiller de l’accrocher au-dessus de votre bureau aux côtés des 21 exigences essentielles en matière de sécurité des produits et de gestion des vulnérabilités.

Les éléments à inclure dans la documentation technique

Si vous êtes friand de documentations à rallonge, vous allez être comblé. La documentation technique doit comprendre au minimum tous les éléments énumérés dans l’Annexe VII du CRA, à savoir :

  1. Une description générale du produit comportant des éléments numériques, notamment :
    • son utilisation prévue ;
    • les versions de logiciel ayant des incidences sur la conformité aux exigences essentielles ;
    • lorsque le produit est un produit matériel, des photographies ou des illustrations montrant les caractéristiques extérieures, le marquage et la disposition intérieure ;
    • les informations et instructions destinées à l’utilisateur (cf. Annexe II du CRA) ;
  2. Une description de la conception, du développement et de la fabrication du produit et des processus de gestion des vulnérabilités, et notamment :
    • les informations nécessaires sur la conception et le développement du produit, y compris, le cas échéant, des dessins et des schémas et/ou une description de l’architecture du système expliquant comment les composants logiciels s’appuient les uns sur les autres ou s’alimentent et s’intègrent dans le traitement global ;
    • les informations et spécifications nécessaires concernant le processus de gestion des vulnérabilités mis en place par le fabricant, y compris la nomenclature des logiciels, la politique coordonnée de divulgation des vulnérabilités, la preuve de la fourniture d’une adresse de contact pour le signalement des vulnérabilités et une description des solutions techniques choisies pour la distribution sécurisée des mises à jour ;
    • les informations et spécifications nécessaires concernant les processus de production et de suivi du produit, et la validation de ces processus;
  3. Une évaluation des risques de cybersécurité sur la base de laquelle le produit est conçu, développé, produit, livré et entretenu, y compris la manière dont les exigences essentielles en matière de cybersécurité des produits sont applicables ;
  4. Les informations qui ont été prises en compte pour déterminer la période de support (voir Chapitre 13) ;
  5. Une liste des normes européennes harmonisées, des spécifications communes ou des schémas européens de certification de cybersécurité qui ont été appliqués ;
    • Lorsqu’ils n’ont pas été appliqués : une présentation des solutions adoptées pour répondre aux exigences essentielles du CRA, y compris une liste des autres spécifications techniques pertinentes appliquées.
    • Dans le cas d’une application partielle, la documentation technique précise les parties appliquées ;
  6. Les rapports des tests réalisés pour vérifier la conformité du produit et des processus de gestion des vulnérabilités aux exigences essentielles du CRA ;
  7. Une copie de la déclaration UE de conformité ;
  8. Le cas échéant, la nomenclature logicielle (Software Bill Of Materials) à la suite d’une demande motivée d’une autorité de surveillance du marché.

Cette documentation technique doit être tenue à la disposition des autorités de surveillance du marché pendant au moins 10 ans, ou pendant le reste de la durée de support, la durée la plus longue étant retenue.

Une documentation technique simplifiée pour les micro-entreprises et les PME

Il est à noter que les micro-entreprises et les PME, y compris les startups, peuvent produire une documentation technique simplifiée en vertu de l’Article 33.5. Celui-ci dispose que la Commission européenne devra préciser les détails du formulaire simplifié au moyen d’actes délégués. Affaire à suivre donc.

5. Réalisez une évaluation des risques cyber en amont de la conception d’un produit

Comme indiqué plus haut, les 13 exigences essentielles du règlement relatives aux produits doivent être appliquées en tenant compte des risques de cybersécurité spécifiques au produit dont il est question. Et pour déterminer ces risques, il n’y a pas trente-six mille solutions : il faut procéder à une évaluation des risques cyber.

La sécurité tout au long du cycle de vie des produits

L’évaluation des risques doit être réalisée par le fabricant, en amont de la conception du produit. Elle servira ensuite à alimenter les réflexions et les choix en matière de sécurité tout au long du cycle de vie du produit.

“Les fabricants d’un produit doivent réaliser une évaluation des risques de cybersécurité qui lui sont associés, et tenir compte des résultats de cette évaluation durant les phases de planification, de conception, de développement, de production, de livraison et de maintenance du produit, en vue de réduire au minimum les risques de cybersécurité, de prévenir les incidents de sécurité et de réduire au minimum les conséquences de ces derniers, notamment en ce qui concerne la santé et la sécurité des utilisateurs.” – CRA, Article 13.2

Cette notion de sécurité à chaque étape du cycle de vie du produit, depuis les prémices de sa conception jusqu’à la fin de la période de support, est au cœur de la Loi sur la cyber-résilience. Les fabricants ont désormais le devoir de veiller à ce que leurs produits soient toujours sécurisés, et pas seulement lorsqu’ils sont mis sur le marché. Puisqu’elle est la raison d’être de toutes les exigences essentielles du règlement, la sécurité continue des produits devrait être le point de mire de tous les gestionnaires de la sécurité concernés.

Les éléments à inclure dans l’évaluation des risques cyber

Ce même Article 13 dispose que l’évaluation doit comprendre au minimum une analyse des risques de cybersécurité fondée sur :

  • L’utilisation prévue et l’utilisation raisonnablement prévisible du produit ;
  • Les conditions d’utilisation du produit, telles que l’environnement opérationnel ou les actifs à protéger ;
  • En tenant compte de la durée d’utilisation prévue du produit.

Elle doit également indiquer clairement :

  • Comment les exigences essentielles relatives aux produits s’appliquent au produit concerné, et comment elles sont mises en œuvre ;
  • Comment le fabricant s’assurera que le produit est conçu, développé et produit de manière à garantir un niveau approprié de cybersécurité ;
  • Comment le fabricant appliquera les exigences essentielles en matière de gestion des vulnérabilités.

Un devoir de diligence si le produit intègre des composants tiers, y compris open-source

Le CRA prend soin de préciser que les fabricants doivent conduire une “due diligence” si leurs produits intègrent des composants tiers, y compris open-source. Il faut donc évaluer les risques intrinsèques à chaque composant tiers, ainsi que ceux posés par la manière dont ils sont intégrés dans le produit.

“Les fabricants font preuve de la diligence nécessaire lorsqu’ils intègrent des composants provenant de tiers de manière à ce que ces composants ne compromettent pas la cybersécurité du produit contenant des éléments numériques, y compris lorsqu’ils intègrent des composants gratuits ou open-source qui n’ont pas été mis à disposition sur le marché dans le cadre d’une activité commerciale.” – CRA, Article 13.5

Le règlement précise que les fabricants doivent prévenir l’entité ou la personne propriétaire du composant tiers s’ils venaient à y découvrir une vulnérabilité – ce qui semble être la moindre des politesses. Il faut ensuite la traiter et y remédier conformément aux exigences essentielles en matière de gestion des vulnérabilités (Article 13.6). C’est un point qui nous paraît délicat, puisque la correction de la vulnérabilité sera le plus souvent à la charge du propriétaire du composant tiers.

À notre avis, le plus sage est d’éviter, dans la mesure du possible, d’intégrer des composants tiers qui comportent une vulnérabilité identifiée ; d’autant plus que le CRA ne fait ici aucune différence entre les vulnérabilités qui représentent un vrai risque de sécurité et celles qui n’auraient aucun impact. Néanmoins, précisons que si le fabricant décide de mettre sur pied un correctif, logiciel ou matériel, il est tenu d’en partager le contenu avec le propriétaire du composant tiers.

Enfin, sachez que l’évaluation des risques doit être incluse dans la documentation technique, en plus d’être documentée et mise à jour tout au long de la période de support du produit (voir Chapitre 13).

6. Intégrez la sécurité à chaque étape du processus de création d’un produit

Une fois l’évaluation des risques réalisée, il faut s’atteler au gros du travail : la création du produit. Ici comme ailleurs, le plus important est, comme le veut la formule consacrée, de penser la sécurité au plus près du produit. Concrètement, il s’agit de mettre en œuvre les 13 exigences essentielles de cybersécurité des produits en intégrant des jalons de sécurité à chaque étape du cycle de vie.

Passer des exigences généralistes du CRA à des normes harmonisées

Avant tout, il convient de spécifier les solutions techniques qui permettront de répondre aux exigences essentielles. En effet, le CRA est un texte de droit européen, et pas une documentation technique rédigée par et pour des ingénieurs. Les exigences essentielles ne sont jamais plus que cela ; le CRA énumère des objectifs à atteindre, mais ne dit jamais comment les atteindre.

Prenons l’exemple de la seconde exigence applicable aux produits, à savoir qu’ils soient “mis à disposition sur le marché avec une configuration sécurisée par défaut.” Tout le monde est à même de comprendre l’objectif, clair et général, mais c’est une autre paire de manches que de faire en sorte qu’il soit atteint.

Transposer ces exigences réglementaires générales en exigences techniques auxquelles les fabricants peuvent se conformer, c’est le rôle des normes harmonisées européennes. Un ensemble de lignes directrices élaborées par des organismes de normalisation, fournissant des spécifications techniques dont l’utilisation prouve que les produits et les services atteignent un certain niveau de qualité, de sécurité et de fiabilité.

Il existe des normes harmonisées pour toutes sortes de choses, et ce n’est qu’une question de temps avant que n’arrivent celles préconisées pour le CRA. Pour autant, il existe déjà un certain nombre de standards et de bonnes pratiques en matière de cybersécurité dont l’application ne peut être que bénéfique. Les normes harmonisées européennes viendront standardiser l’existant et adresser les angles morts, mais certains efforts à fournir sont déjà clairement identifiés pour peu que l’on sache où chercher.

Mettre en miroir les exigences essentielles avec des spécifications techniques

Dans l’attente de normes harmonisées spécifiques, l’un des meilleurs documents disponibles à ce jour est la Cartographie des normes relatives aux exigences du Cyber Resilience Act (2024), publiée conjointement par le Centre Commun de Recherche (CCR) et l’Agence de l’Union européenne pour la cybersécurité (ENISA).

Ce document précieux fait correspondre chacune des exigences essentielles du CRA avec un ou plusieurs standards existants. L’objectif premier de cette publication est de contribuer à l’élaboration de normes harmonisées en recensant ce qui existe déjà, mais elle peut également être utile aux fabricants qui souhaitent adopter dès à présent les bonnes pratiques en matière de cybersécurité.

Prenons l’exemple de la septième exigence essentielle relative aux produits : “Ne traiter que des données, personnelles ou autres, qui sont adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité du produit.”

Ici, le document du CCR et de l’ENISA souligne la valeur de la norme ISO/IEC 27701, une extension des normes ISO/IEC 27001 et ISO/IEC 27002 pour la gestion des informations relatives à la vie privée. Bien qu’elle ne soit pas spécifique aux produits, l’ISO 27701 propose une correspondance utile entre diverses normes et législations comme le RGPD, en plus de couvrir correctement le concept de minimisation des données. Elle sera donc utile aux fabricants en ce qui concerne l’exigence essentielle susmentionnée.

Ce n’est qu’un exemple, mais la Cartographie des normes offre des pistes de réflexion intéressantes pour chacune des exigences essentielles du règlement, aussi bien pour ce qui est de la cybersécurité des produits que de la gestion des vulnérabilités – même si, bien souvent, le constat des auteurs est que l’existant est trop théorique, et donc insuffisant, et que les futures normes harmonisées devront préciser les spécifications techniques attendues.

Quoi qu’il en soit, nous recommandons vivement cette lecture à toute personne impliquée dans la réflexion sur la sécurité des produits, qu’il s’agisse d’ingénieurs, de développeurs, de chefs de produits, de CTO, CPO ou autres.

Planifier les spécifications techniques à chaque phase du cycle de vie du produit

Chaque exigence essentielle peut être satisfaite par des spécifications techniques appropriées, lesquelles peuvent être planifiées pour une phase spécifique du cycle de vie du produit. Définir clairement quelles exigences et spécifications doivent être adressées à quelle étape vous aidera à organiser vos tâches et celles des équipes de manière plus efficace.

La première chose à faire est de définir précisément les étapes du cycle de vie de votre produit. Elles peuvent varier d’un produit à l’autre, mais certaines décompositions générales offrent une base de travail solide. Par exemple, l’Article 13 du CRA découpe le cycle de vie en six phases : planification, conception, développement, production, livraison et maintenance.

Pour notre part, nous préférons le découpage avancé dans la Cartographie des normes relatives aux exigences du CRA, où les auteurs décomposent le cycle de vie d’un produit de la manière suivante :

  1. Conception ;
  2. Réalisation ;
  3. Validation ;
  4. Mise en service ;
  5. Surveillance / Maintenance ;
  6. Fin de vie.

Ce découpage est particulièrement approprié, puisqu’il considère la fin de vie du produit comme partie intégrante du cycle ; un choix judicieux, puisque les exigences de sécurité du CRA doivent s’appliquer de bout en bout.

Une fois que les phases du cycle de vie et les spécifications techniques à mettre en œuvre ont été déterminées, il ne reste plus qu’à les mettre en correspondance pour avoir une vue d’ensemble de ce qu’il faut faire et quand – oui, c’est plus facile à dire qu’à faire. Gardez toutefois à l’esprit qu’il faudra attendre les normes harmonisées pour que le travail soit fait dans les règles de l’art.

7. Réalisez des tests de sécurité “efficaces et réguliers”

S’il est essentiel (et obligatoire) de penser à la sécurité tout au long du cycle de vie, il l’est tout autant de tester la sécurité réelle des produits.

La sécurité numérique ne peut pas être seulement théorique : il faut s’assurer que tout ce qui a été mis en place est bien efficace. Autrement dit, il faut introduire des jalons de sécurité tout au long de la vie des produits pour s’assurer qu’ils ne présentent pas de vulnérabilités susceptibles d’être exploitées par un acteur malveillant.

La réalisation de tests réguliers et efficaces est une obligation pour les fabricants, puisque ce n’est est autre que la troisième exigence essentielle en matière de gestion des vulnérabilités.

“Les fabricants soumettent les produits comportant des éléments numériques à des tests et examens de sécurité réguliers et efficaces.” – CRA, Annexe I, Partie 2.

De plus, certains modules d’évaluation de la conformité, comme le module H, sur lequel nous reviendrons plus loin, demandent de dresser une description détaillée des tests “qui seront effectués avant, pendant et après la production et la fréquence à laquelle ils auront lieu”. Il ne suffit donc pas de réaliser des tests de sécurité : il faut élaborer et documenter une stratégie de test cohérente, exhaustive et continue.

Pourquoi réaliser des tests de sécurité ?

Au-delà de leur caractère obligatoire, les tests sont une évidence pour assurer un niveau minimum de cybersécurité. Tout produit comportant des éléments numériques contient des vulnérabilités, c’est inévitable. Les tests sont justement là pour les débusquer, puis les classifier.

Certaines vulnérabilités peuvent être extrêmement difficiles à détecter, là où d’autres sauteront aux yeux du premier testeur venu. De même, l’exploitation de certaines vulnérabilités peut avoir des conséquences dramatiques, alors que d’autres n’auront aucun impact sur la sécurité réelle du produit. Après tout, une vulnérabilité peut tout à fait porter sur des fonctionnalités non exploitables, ou ne pouvant pas altérer la sécurité ni l’usage du produit. Supposons qu’une faille dans un radio-réveil connecté permette uniquement de changer la couleur de l’affichage numérique de bleu à rouge : c’est ennuyeux, mais ce n’est pas le piratage du siècle…

Il est d’ailleurs étrange de constater que cette notion d’impact des vulnérabilités exploitables est absente du Cyber Resilience Act ; un fait d’autant plus regrettable que certains acteurs du monde de la cybersécurité avaient déjà souligné cette inconséquence dès les premières versions du règlement. On pense notamment à l’Alliance pour la Confiance Numérique (ACN), qui déplorait déjà début 2023 qu'”une vulnérabilité exploitable n’est en aucun cas un concept absolu ou binaire”. Espérons que les passerelles entre le CRA et les schémas de certification introduits par le Cybersecurity Act, qui font eux cette distinction, et dont nous parlerons dans le chapitre suivant, permettront de gommer ce manque de nuance.

Quoi qu’il en soit, il est impératif de réaliser des tests de sécurité car, au-delà de la détection, ce sont eux qui permettront d’ évaluer le niveau de criticité et l’impact potentiel des vulnérabilités sur le produit et ses utilisateurs. Une vulnérabilité exploitée avec succès par un acteur malveillant peut non seulement compromettre la sécurité de tous, mais aussi avoir des conséquences en termes d’image de marque et de business. En tant que fabricant, il est donc essentiel de faire tout ce qui est en votre pouvoir pour réduire les risques.

Quels tests de sécurité privilégier ?

Il n’existe pas de forme unique de test qui suffirait à tout vérifier. Les tests à mettre en œuvre dépendent de l’objectif poursuivi et, surtout, de la phase du cycle de vie du produit. Les tests de cybersécurité sont nombreux et éclectiques, ont des visées différentes, et n’interviennent pas aux mêmes stades. C’est la combinaison des différents tests qui permettra de construire une stratégie de test solide.

Par exemple, pendant la phase de développement logiciel, il est opportun de mettre en place des revues du code source, des tests unitaires, des tests d’intégration ou des tests de bout en bout. Ceux-ci interviennent en amont de la mise en production, au cours du cycle de vie de développement (SDLC) dans le cadre d’une approche DevSecOps. Ils ne cherchent pas spécifiquement à identifier des vulnérabilités, mais plutôt des problèmes en général, non seulement en termes de sécurité, mais aussi de compatibilité ou de logique. Dans de mauvaises mains, ces derniers peuvent conduire à des vulnérabilités exploitables et dangereuses (ou tout simplement nuire à la qualité et au bon fonctionnement du produit).

D’autres formes de tests sont spécifiquement conçues pour détecter les vulnérabilités de manière proactive. Cela peut être de façon automatique, comme les scanners de vulnérabilités, ou manuelle comme les tests d’intrusion. Elles font partie de ce qu’on appelle plus généralement la Sécurité Offensive, ou OffSec pour Offensive Security.

Le rôle de la Sécurité Offensive dans la stratégie de tests

La Sécurité Offensive est une approche proactive de la cybersécurité : elle ne cherche pas à protéger les produits, mais à identifier leurs vulnérabilités avant les acteurs malveillants. Les tests OffSec simulent des attaques en adoptant la posture des cyber-attaquants, et leurs méthodes, afin d’éprouver les défenses des organisations et de leurs produits, d’identifier leurs faiblesses potentielles, et d’évaluer leur niveau de sécurité réel. Pour le dire plus simplement : la Sécurité Offensive permet aux fabricants de mettre à l’épreuve leurs propres produits afin d’identifier les failles pour mieux les corriger.

L’OffSec permet de tester presque tous les types d’actifs, des infrastructures cloud aux applications web et mobiles, en passant par toutes les formes de produits physiques, qu’ils soient destinés au grand public ou à l’industrie.

Si l’on vous dit tout cela, ce n’est pas par hasard, mais parce que nous, Yogosha, sommes spécialisés dans les tests de sécurité offensifs.

Pentest as a Service (PtaaS)

Le pentest, ou test d’intrusion, est une technique qui vise à simuler une attaque informatique contre un actif, ici un produit, afin d’identifier ses vulnérabilités. C’est une technique éprouvée, que les équipes de sécurité de France et de Navarre connaissent déjà bien, et il est impératif d’y avoir recours pour tester les produits réglementés avant de les mettre sur le marché.

Yogosha propose une approche innovante du test d’intrusion : le Pentest as a Service (PtaaS). Une solution idéale pour toutes les organisations qui doivent réaliser de multiples tests tout au long de l’année, sur de nombreux produits et périmètres.

Le Pentest as a Service (PtaaS) permet :

  1. La continuité des tests de sécurité, qui peuvent être échelonnés tout au long du cycle de vie des produits, avant et après leur mise sur le marché, afin de garantir une sécurité solide et permanente conformément aux exigences essentielles du CRA ;
  2. L’accès direct à la Yogosha Strike Force (YSF), une communauté de plus de 1000 experts en sécurité certifiés et spécialisés dans différents types d’actifs et de technologies ;
  3. La digitalisation et l’industrialisation des activités de test grâce à une plateforme OffSec européenne disponible en SaaS, ou en auto-hébergement pour les acteurs aux exigences de sécurité les plus élevées.

Adopter une approche continue des tests de sécurité

Le CRA appelle à la sécurité continue des produits tout au long de leur cycle de vie. Chez Yogosha, c’est une philosophie que nous appliquons au quotidien.

Historiquement, les tests de sécurité ont toujours été occasionnels : un pentest avant la mise en production, puis plus rien pendant des mois, voire des années. Mais le caractère ponctuel des tests de sécurité traditionnels fait qu’ils ne sont plus adaptés pour répondre aux enjeux de sécurité des fabricants d’aujourd’hui. Ils sont certes utiles pour identifier les vulnérabilités à un instant T, mais ils sont par nature insuffisants pour faire face à la nature fluctuante des cybermenaces.

L’écosystème numérique est dynamique, les mises à jour des produits sont nombreuses et régulières, de nouvelles vulnérabilités apparaissent chaque jour, et les acteurs malveillants renouvellent sans cesse leurs approches. Les tests ponctuels n’offrent qu’une visibilité restreinte, qui expose les entreprises aux risques potentiels qui peuvent survenir entre deux tests.

Pour les fabricants réglementés par le CRA, aux besoins de sécurité croissants, la réponse est donc ailleurs que dans les approches traditionnelles. Il faut pouvoir répondre aux projets en mode Agile, aux livraisons nombreuses et régulières, aux impératifs business… Il faut une approche du test d’intrusion qui soit flexible, évolutive, rationalisée et continue.

Avec le Pentest as a Service, Yogosha propose des tests d’intrusion à la demande, qui peuvent être facilement programmés et répétés tout au long du cycle de vie des produits. Cela permet non seulement de compléter les capacités internes, mais aussi de garder un œil vigilant et constant sur la sécurité des produits réglementés. Il s’agit d’un sérieux avantage, étant donné que l’exécution régulière de tests de sécurité est l’une des exigences essentielles du CRA.

Trouver des experts en sécurité qualifiés

La mise en place de tests de sécurité soulève une autre difficulté : il faut trouver des experts qualifiés pour les réaliser. Là, deux options s’offrent aux fabricants.

Premièrement, disposer des ressources humaines compétentes en interne. Cette option présente de nombreux avantages, mais il existe malheureusement une pénurie mondiale de talents en cybersécurité. Forbes estimait à 3,5 millions le nombre de postes vacants dans le secteur au début de l’année 2023, soit une augmentation de 350% en moins de 10 ans. Les talents sont donc rares et coûteux.

Deuxième solution : faire appel à un prestataire de services spécialisé. C’est la solution retenue par de nombreuses entreprises, qui choisissent d’externaliser les tests de sécurité à un prestataire, le plus souvent un cabinet d’audit. Mais l’expertise d’un cabinet est toujours limitée à celle de ses propres employés, ainsi qu’à leur nombre. Même le pentester le plus talentueux ne sera pas familier avec tous les types de produits et de technologies, c’est impossible. Au moment de choisir le prestataire qui effectuera les tests, il est donc essentiel de s’assurer qu’il dispose des compétences internes correspondant aux spécificités du périmètre à éprouver.

Face à ces deux difficultés – recruter des professionnels qualifiés, ou s’assurer des compétences internes d’un prestataire –, nous apportons une réponse unique : la Yogosha Strike Force.

La Yogosha Strike Force, 1000+ chercheurs en sécurité triés sur le volet

La Yogosha Strike Force (YSF) est une communauté privée et sélective qui regroupe plus de 1000 chercheurs en sécurité internationaux qui sont :

  • Spécialisés dans la recherche des vulnérabilités les plus critiques en simulant les attaques sophistiquées des pirates informatiques.
  • Experts dans de multiples types d’actifs – Applications Web et Mobiles, IOT, Cloud, Réseaux, API, Infrastructure…
  • Titulaires de certifications reconnues en matière de cybersécurité – OSCP, OSEP, OSWE, OSEE, GXPN, GCPN, eWPTXv2, PNPT, CISSP…

Nous sélectionnons uniquement les chercheurs les plus talentueux : seuls 10% des candidats sont acceptés, après avoir réussi des examens techniques et pédagogiques. Leur identité et leurs antécédents sont également vérifiés.

A travers la Yogosha Strike Force, les fabricants visés par le Cyber Resilience Act ont donc accès à :

  • Un grand nombre d’experts en sécurité internationaux triés sur le volet ;
  • Un panel de compétences sans pareil pour adresser au mieux tous les types de produits et de technologies.

“Par l’intermédiaire de Yogosha, nous avons réussi à trouver des gens vraiment talentueux.” — Éric Vautier, RSSI du Groupe ADP (Aéroports de Paris)

Yogosha, une plateforme de Sécurité Offensive disponible en SaaS ou Self-Hosted

Les tests de sécurité impliquent un certain nombre de données sensibles, comme des informations sur des vulnérabilités potentiellement exploitables. Il est donc essentiel de choisir un prestataire de tests fiable et solide. Il appartient ici aux organisations de se renseigner sur la qualité de chaque fournisseur.

De notre côté, nous proposons plusieurs types de déploiement de notre plateforme de Sécurité Offensive afin de répondre au mieux aux impératifs de sécurité de chaque organisation, y compris les plus sensibles.

La plateforme Yogosha est disponible :

  • en SaaS : une solution clé en main, hébergée via 3DS Outscale et son cloud souverain certifié SecNumCloud, la plus haute norme de sécurité française, établie par l’ANSSI. Les données sont hébergées sur le sol français.
  • en Self-Hosted : une solution taillée pour les entités aux exigences de sécurité les plus strictes. Vous êtes libre d’héberger la plateforme Yogosha où bon vous semble – cloud privé, on prem – pour garder le contrôle total de vos données et du contexte d’exécution.

Dans les deux cas, la robustesse intrinsèque de notre produit est au centre de nos préoccupations. Nous sécurisons continuellement nos actifs à travers un pipeline DevSecOps, les directives OWASP, des tests d’intrusion récurrents et un programme de bug bounty continu. Par ailleurs, Yogosha est en cours d’obtention de la certification ISO 27001 – un processus qui sera probablement achevé au moment où vous lirez ces lignes.

Le Bug Bounty, une approche recommandée par le Cyber Resilience Act

Le Bug Bounty est une autre approche de la Sécurité Offensive, mentionnée noir sur blanc dans le considérant 77 du CRA – qui préfère parler de “prime aux bogues”, dans un français impeccable. Elle permet aux fabricants de se confronter à la réalité du terrain en mobilisant de nombreux chercheurs en sécurité pour tester tout ou partie de leurs produits ou systèmes.

Le Bug Bounty est une chasse aux bugs qui repose sur une logique de paiement au résultat. Les organisations versent des récompenses monétaires – les bounties donc – aux chercheurs pour chaque vulnérabilité valide qu’ils parviennent à identifier. Plus la vulnérabilité est critique, plus la prime est importante. Si les chercheurs ne trouvent rien, l’organisation ne dépense rien.

Nous ne nous attarderons pas davantage ici sur le Bug Bounty, car il s’agit d’un élément important de la politique de divulgation coordonnée des vulnérabilités (CVD), qui est l’une des exigences essentielles du CRA et le sujet du Chapitre 11 de ce guide.

Néanmoins, précisons dès à présent que Yogosha, en tant que spécialiste de la Sécurité Offensive, propose bien évidemment des programmes de bug bounty. C’est d’ailleurs l’une de nos activités historiques, puisque nous sommes la seule plateforme européenne entièrement privée à proposer des programmes de bug bounty, et ce depuis 2015.

8. Obtenez une certification de cybersécurité pour vos produits

Si les tests permettent de réduire les risques en identifiant les vulnérabilités des produits, la certification permet d’attester d’un niveau de sécurité général élevé. Obtenir une certification de cybersécurité, c’est obtenir la preuve que le produit est aussi sécurisé que possible.

En effet, la certification implique une évaluation approfondie de la sécurité du produit et des processus mis en place par son fabricant. Si tous les voyants sont au vert, la certification vient récompenser le travail bien fait.

Pourquoi obtenir une certification de cybersécurité ?

L’obtention d’une certification demande du temps, de l’argent et un certain engagement de la part des équipes concernées. D’aucuns se demanderont alors si le jeu en vaut la chandelle – spoiler : oui.

Les avantages de la certification sont nombreux, et pas seulement en matière de sécurité. Dans un environnement concurrentiel, la certification peut être un facteur de différenciation fort entre les produits. Les clients peuvent être plus enclins à choisir un produit certifié qu’un produit qui ne l’est pas, car ils auront l’assurance qu’il répond à des normes de sécurité élevées. Si les considérations de cybersécurité ne font pas (encore) partie des principaux critères de choix du commun des mortels, elles peuvent être absolument primordiales si les clients s’avèrent être des organisations, a fortiori lorsqu’elles sont réglementées par la Directive NIS2.

En ce qui concerne le CRA en particulier, l’obtention d’une certification de cybersécurité présente un avantage majeur : elle dispense des procédures d’évaluation de la conformité par un tiers – sous certaines conditions, évidemment.

Les produits certifiés dans le cadre d’un schéma européen présumés conformes aux exigences du CRA

Avant toute chose, il nous faut parler brièvement du Cybersecurity Act (CSA), ou Loi sur la cybersécurité. Il s’agit d’un autre règlement majeur de l’UE adopté en 2019, qui a notamment introduit un cadre de certification de la cybersécurité à l’échelle de l’Union pour les produits, les services et les processus TIC. L’objectif était de garantir un niveau adéquat de cybersécurité et d’harmoniser les évaluations, afin que les entreprises opérant dans l’UE puissent certifier leurs produits une seule fois avec un certificat reconnu sur l’ensemble du territoire.

Si l’on vous dit cela, vous vous doutez bien que ce n’est pas pour la culture générale. En effet, le Cyber Resilience Act dispose que les produits certifiés selon un schéma de certification européen élaboré dans le cadre du Cybersecurity Act sont présumés conformes aux exigences essentielles du CRA, dès lors qu’elles ont été appréciées au cours du processus de certification.

“Les produits comportant des éléments numériques et les processus mis en place par le fabricant pour lesquels une déclaration UE de conformité ou un certificat de cybersécurité européen ont été délivrés dans le cadre d’un schéma européen de certification de cybersécurité adopté conformément au règlement (UE) 2019/881 [NDLR : le Cybersecurity Act] sont présumés conformes aux exigences essentielles énoncées à l’annexe I, dans la mesure où celles-ci sont couvertes par la déclaration UE de conformité ou le certificat de cybersécurité européen, ou des parties de ceux-ci.” – CRA, Article 27.8

Le règlement précise bien que seules les certifications délivrées dans le cadre d’un schéma européen au titre du Cybersecurity Act peuvent constituer une preuve de conformité.

Par ailleurs, la certification à un niveau d’assurance au moins “substantiel” dispense de l’obligation d’effectuer une évaluation de la conformité par un tiers, autrement obligatoire pour certaines catégories de produits – on y reviendra.

“En outre, la délivrance d’un certificat de cybersécurité européen au titre de tels schémas, au minimum au niveau d’assurance dit ‘substantiel’, supprime l’obligation d’un fabricant de procéder à une évaluation de la conformité par un tiers pour les exigences correspondantes.” – CRA, Article 27.9

Les schémas de certification européens introduits par le Cybersecurity Act (CSA)

Le Cybersecurity Act a amené avec lui trois schémas de certification européens, dont l’élaboration à été confiée à l’ENISA :

  • Le schéma EU5G sur la sécurité des réseaux 5G ;
  • Le schéma EUCS sur la sécurité des services cloud ;
  • Le schéma EUCC pour les produits TIC (matériel, logiciels et composants).

C’est ce dernier schéma qui nous intéresse particulièrement dans le contexte du CRA.

SYSTÈMES DE CERTIFICATION EUROPÉENS INTRODUITS PAR LE CYBERSECURITY ACT (CSA)

Le schéma EUCC : des règles de certification harmonisées pour les produits TIC

Le schéma EUCC (EU Common Criteria) est le premier – et le seul à ce jour – des trois cadres à avoir été officiellement adopté par la Commission européenne, le 31 janvier 2024. Il fournit un ensemble de règles et de procédures harmonisées pour certifier les produits TIC, matériels comme logiciels, ceux-là mêmes qui sont réglementés par le Cyber Resilience Act.

Le cadre EUCC repose sur les Critères Communs (un ensemble de normes d’évaluation des systèmes informatiques) et pioche dans les différents cadres nationaux existants qui étaient rassemblés au sein du SOG-IS, un accord européen de reconnaissance mutuelle des certificats délivrés par une autorité nationale, comme l’ANSSI en France. Cette dernière a d’ailleurs confirmé que “les certificats SOG-IS existants pourront être réévalués en certificats EUCC dès lors que les nouvelles exigences seront respectées.” (Source)

Nous ne détaillerons pas davantage le contenu du schéma EUCC, car le sujet est si riche qu’il pourrait faire l’objet d’un autre guide. Toutefois, si le sujet vous intéresse, voici quelques documents de référence :

À noter que les premiers certificats EUCC pourront être délivrés à partir de février 2025, un an après la publication du schéma.

Quels sont les produits soumis à une obligation de certification ?

Les produits critiques au regard du CRA peuvent être soumis à une certification obligatoire, mais pas par défaut. En effet, l’Article 8 donne à la Commission européenne le droit de décider, au moyen d’actes délégués, quelles catégories de produits critiques sont tenues d’obtenir une certification européenne de cybersécurité à un niveau d’assurance au moins “substantiel”. Là encore, le niveau de dépendance des entités réglementées par la Directive NIS2 vis-à-vis des produits examinés pèsera dans la balance.

Cette obligation n’est matérialisée que par un tel acte délégué ; en son absence, les produits critiques ne sont pas tenus d’être certifiés. Ils sont alors soumis à la même procédure d’évaluation de la conformité que les produits importants de Classe II, sur laquelle nous reviendrons dans le chapitre suivant.

Dans le cas d’un acte délégué qui introduit une obligation de certification pour une catégorie de produits critiques, la règle générale est d’observer une période de transition de 6 mois avant que les nouvelles règles ne soient appliquées, à moins qu’un impératif de sécurité ne justifie une application plus rapide.

9. Déterminez la procédure d’évaluation de la conformité à appliquer pour chaque produit

La mise en œuvre des exigences essentielles du Cyber Resilience Act est obligatoire, et les fabricants devront montrer patte blanche avant de mettre des produits réglementés sur le marché. Il faudra donc apporter la preuve de la preuve de la conformité, au moyen d’une évaluation.

Le CRA instaure différentes procédures d’évaluation de la conformité, plus ou moins strictes selon le niveau de risque des produits. Le premier niveau consiste en une auto-évaluation par les fabricants, tandis que les procédures avancées exigent le recours à un organisme d’évaluation tiers, ou l’obtention d’une certification de cybersécurité.

Quatre procédures d’évaluation basées sur différents modules

L’Article 32 du CRA introduit quatre procédures d’évaluation de la conformité, chacune basée sur un ou plusieurs modules :

  • Procédure d’évaluation 1 : Module A
  • Procédure d’évaluation 2 : Module B + Module C
  • Procédure d’évaluation 3 : Module H
  • Procédure d’évaluation 4 : L’obtention d’une certification selon un schéma européen publié dans le cadre du Cybersecurity Act, sujet que nous avons évoqué dans le chapitre précédent.

Les fabricants peuvent utiliser n’importe laquelle de ces procédures, à l’exception des produits importants ou critiques qui ne peuvent pas bénéficier de la première.

Les modules en question sont :

  1. Module A : Procédure d’évaluation de la conformité basée sur le contrôle interne ;
  2. Module B : Examen UE de type ;
  3. Module C : Conformité au type sur la base du contrôle interne de la fabrication ;
  4. Module H : Conformité sur la base de l’assurance complète de la qualité.

Le module A correspond à une auto-évaluation par le fabricant, tandis que les modules B + C impliquent le recours à un organisme de certification indépendant. Le module H consiste en l’application d’un système de qualité approprié et approuvé par un organisme tiers.

Nous ne détaillerons pas le contenu exact de chaque module dans ce guide, car toutes les informations pertinentes sont édictées de façon claire et précise dans l’annexe VIII du Cyber Resilience Act.

Sachez néanmoins que, quel que soit le module, la documentation à rassembler est conséquente. Aucun des quatre n’est une mince affaire, et tous nécessiteront de l’organisation et de la rigueur dans la gestion du projet de mise en conformité.

Le cas général : l’auto-évaluation

Lorsque les produits ne sont ni importants ni critiques, les fabricants peuvent opter pour l’auto-évaluation, ce qui correspond à la première procédure d’évaluation (Module A). Il s’agit de la méthode la plus simple de toutes celles prévues par le règlement.

Dans ce cas, le fabricant assure et déclare sous sa seule responsabilité que les produits satisfont à toutes les exigences essentielles de cybersécurité, et qu’il a bien respecté les exigences essentielles en matière de gestion des vulnérabilités. Il doit également établir la documentation technique et la déclaration UE de conformité, et apposer le marquage CE sur le produit.

Les fabricants qui peuvent bénéficier de l’auto-évaluation mais qui souhaitent appliquer une procédure plus stricte sont bien entendu libres de le faire.

L’évaluation des produits importants et critiques

Les produits importants (classes I et II) ne peuvent être évalués qu’à l’aide des procédures 2, 3 ou 4. En d’autres termes, il est obligatoire de faire appel à un organisme d’évaluation indépendant, ou d’obtenir une certification de cybersécurité appropriée (voir le point suivant). L’auto-évaluation n’est pas possible.

Attention, certains produits critiques peuvent être soumis à une obligation de certification de cybersécurité, en particulier lorsque des entités réglementées par NIS2 en dépendent, afin de s’assurer qu’ils ne peuvent pas être utilisés comme vecteurs d’attaque à leur encontre. La Commission européenne devra préciser les catégories concernées au moyen d’actes délégués. En l’absence d’un tel acte, les produits critiques peuvent choisir entre la certification, la deuxième procédure (module B+C) ou la troisième (module H).

La certification selon un schéma européen comme preuve de conformité

Comme indiqué plus haut, l’obtention d’une certification selon un schéma européen publié dans le cadre du Cybersecurity Act peut suffire à prouver la conformité avec les exigences essentielles du CRA. Il s’agit plus précisément du schéma EUCC, dont nous avons parlé dans le chapitre précédent.

La certification EUCC à un niveau d’assurance au moins “substantiel” dispense de l’évaluation de la conformité par un tiers, autrement obligatoire pour les produits importants et critiques. Il appartient donc aux fabricants de ces produits de choisir entre l’obtention de la certification EUCC ou l’évaluation de la conformité par un organisme indépendant.

“En outre, la délivrance d’un certificat de cybersécurité européen au titre de tels schémas, au minimum au niveau d’assurance dit ‘substantiel’, supprime l’obligation d’un fabricant de procéder à une évaluation de la conformité par un tiers pour les exigences correspondantes.” – CRA, Article 27.9

Les cas particuliers : open-source, systèmes DME et systèmes d’IA à haut risques

Il existe quelques cas particuliers qu’il nous semble important de préciser : les produits open-source, les systèmes de dossiers médicaux électroniques (DME) et les systèmes d’IA à haut risques.

L’évaluation des produits avec des éléments open-source

Les produits contenant des éléments open-source peuvent avoir recours à l’auto-évaluation (module A). Cela s’applique également aux produits open-source considérés comme importants, comme précisé par l’Article 32.5 du CRA, et son considérant 92 :

“Les fabricants de produits importants comportant des éléments numériques qualifiés de logiciels libres devraient pouvoir suivre la procédure de contrôle interne basée sur le module A, à condition de mettre la documentation technique à la disposition du public.” – CRA, Considérant 92

L’évaluation des système de dossiers médicaux électroniques (DME)

Les systèmes de dossiers médicaux électroniques (DME) sont à la fois réglementés par le CRA et l’EHDS (European Health Data Space Regulation). Néanmoins, pour prouver leur conformité, les fabricants ne doivent pas appliquer les procédures d’évaluation du CRA mais celles détaillées dans le Chapitre III du EHDS.

Cette mesure est précisée à l’Article 32.6 du CRA, qui pourrait néanmoins disparaître de la version finale du règlement. En effet, ce même article pourrait être introduit directement dans l’EHDS si ce dernier venait être publié bien plus tard que le CRA. Mais ce n’est là qu’un jeu d’écriture, et ça ne changerait rien pour les fabricants concernés.

L’évaluation des systèmes d’IA à haut risques

Il peut arriver que des produits embarquant du numérique soient également considérés comme des systèmes d’IA à haut risques selon l’Article 6 de l’Artificial Intelligence Act (AI Act), la loi européenne sur l’intelligence artificielle adoptée en mars 2024.

En effet, l’Article 15 de l’AI Act amène des exigences en matière de précision, de robustesse et de cybersécurité des systèmes d’IA. Se pose alors la question de savoir quelle législation prévaut sur l’autre en matière de sécurité numérique…

L’Article 12 du CRA lève tout doute en indiquant que les systèmes d’IA à haut risque sont considérés comme étant conformes aux exigences de cybersécurité de l’AI Act si :

  • Ces produits satisfont aux exigences essentielles du CRA en matière de cybersécurité des produits et de gestion des vulnérabilités ;
  • Le niveau de cybersécurité est démontré par la déclaration UE de conformité délivrée en vertu du CRA.

De manière générale, c’est toujours la procédure d’évaluation de la conformité définie par l’Article 43 de l’IA Act qui s’applique, même si l’évaluateur doit être compétent en la matière des deux réglementations. En revanche, si le système d’IA à haut risques est également considéré comme un produit important ou critique par le CRA, alors ses procédures d’évaluation s’appliquent également en ce qui concerne ses exigences essentielles.

10. Connaissez (et respectez) les délais de signalement des incidents graves et des vulnérabilités exploitées

Dans la droite lignée de la Directive NIS2, le Cyber Resilience Act introduit également des obligations de signalement des incidents graves et des vulnérabilités activement exploitées aux autorités.

Nous attirons votre attention sur le fait que le respect de ces exigences est de la plus haute importance. Non seulement pour des raisons évidentes de sécurité générale, mais aussi parce que leur non-respect peut donner lieu à des amendes substantielles, exception faite des micro-entreprises, des PME et des gestionnaires de logiciels open-source.

En outre, toutes les dispositions à ce sujet seront applicables 21 mois après la publication officielle du CRA, contrairement aux autres qui entreront en application après 36 mois. La publication du règlement étant attendue pour 2024, il est raisonnable de dire que les obligations de signalement des incidents graves et des vulnérabilités exploitées s’appliqueront dès 2026.

Des signalements obligatoires à faire simultanément à l’ENISA et au CSIRT compétent

Les obligations en matière de signalement des incidents graves et des vulnérabilités exploitées sont introduites par l’Article 14. On vous épargne la paraphrase du texte officiel, qui est clair comme de l’eau de roche :

Un fabricant doit notifier toute vulnérabilité activement exploitée contenue dans le produit comportant des éléments numériques dont il prend connaissance simultanément au CSIRT désigné comme coordinateur […] et à l’ENISA. Le fabricant notifie cette vulnérabilité activement exploitée par l’intermédiaire de la plateforme unique de notification établie conformément à l’Article 16.” – CRA, Article 14.1

L’Article 14.3 entérine quant à lui la même obligation en ce qui concerne les incidents graves.

Pour résumer, les fabricants doivent donc :

  • Signaler les incidents graves et les vulnérabilités activement exploitées ;
  • dans les délais impartis ;
  • simultanément à l’ENISA et au CSIRT approprié ;
  • via une plateforme unique de signalement.

Plusieurs questions se posent ici, auxquelles nous répondrons par la suite :

  • Que sont l’ENISA et les CSIRT ?
  • Comment savoir à quel CSIRT s’adresser ?
  • Qu’est-ce que la plateforme unique de signalement ?
  • Qu’est-ce qu’un “incident grave” ?
  • Qu’est-ce qu’une “vulnérabilité activement exploitée” ?
  • Quels sont les délais de notification introduits par le CRA ?

Que sont l’ENISA et les CSIRT ?

L’ENISA est l’Agence de l’Union européenne pour la cybersécurité, un acteur incontournable du paysage cyber de l’Union et, de facto, du Cyber Resilience Act. Parmi ses nombreuses missions, l’ENISA est notamment chargée de créer les différents schémas de certification en cybersécurité découlant du Cybersecurity Act évoqués précédemment (EU5G, EUCS, EUCC).

Dans le contexte du CRA, les CSIRT (Computer Security Incident Response Team) sont des équipes spécialisées désignées par les différents pays de l’UE, chargées de coordonner la cybersécurité au niveau national et de réagir aux incidents cyber sur leur sol. A titre d’information, vous croiserez peut-être le terme CERT (Computer Emergency Response Team), qui est souvent utilisé de manière interchangeable avec CSIRT.

Il y a par exemple le CERT-BE en Belgique, le CERT-Bund en Allemagne, le GR-CSIRT en Grèce, ou encore le CERT-FR en France, qui est le CSIRT à compétence nationale rattaché à l’ANSSI (Agence nationale de la sécurité des systèmes d’information). Vous trouverez la liste des CSIRT de chaque pays de l’Union sur le site officiel du réseau, CSIRTs Network.

Comment savoir à quel CSIRT s’adresser ?

C’est simple : en cas d’incident grave ou de vulnérabilité exploitée, les fabricants doivent avertir le CSIRT désigné comme coordinateur dans l’État membre où ils ont leur établissement principal dans l’Union.

L’Article 14.7 du CRA dispose qu’un fabricant est réputé avoir son établissement principal dans l’Union dans l’État membre où sont principalement prises les décisions relatives à la cybersécurité des produits comportant des éléments numériques.

Si un tel État membre ne peut être déterminé, l’établissement principal est considéré comme se trouvant dans l’État membre où le fabricant possède l’établissement comptant le plus grand nombre de salariés.

Si l’établissement principal ne peut toujours pas être déterminé, le fabricant doit avertir le CSIRT le plus approprié selon l’ordre suivant :

  1. L’État membre dans lequel le mandataire agissant au nom du fabricant pour le plus grand nombre de produits comportant des éléments numériques de ce fabricant est établi ;
  2. L’État membre dans lequel l’importateur qui met sur le marché le plus grand nombre de produits comportant des éléments numériques de ce fabricant est établi ;
  3. L’État membre dans lequel le distributeur qui met à disposition sur le marché le plus grand nombre de produits comportant des éléments numériques de ce fabricant est établi ;
  4. L’État membre dans lequel se trouvent le plus grand nombre d’utilisateurs de produits comportant des éléments numériques de ce fabricant.

Qu’est-ce que la plateforme unique de signalement ?

Les signalements doivent se faire simultanément à l’ENISA et au CSIRT approprié, et à chaque fois “par l’intermédiaire de la plateforme unique de notification” de l’Union européenne. Elle doit être administrée et maintenue par l’ENISA, et permettre à chaque CSIRT national de “mettre en place leurs propres points finaux de notification électronique.”

Malheureusement, il est difficile de vous en dire plus pour le moment, car cette plateforme est encore en gestation à l’heure où nous écrivons ces lignes. Si le CRA entérine la responsabilité de l’ENISA dans le développement du projet, les détails de sa mise en œuvre demeurent incertains. D’aucuns s’interrogent d’ailleurs sur sa capacité à mener à bien une telle tâche. Ce ne sont évidemment pas la compétence et la qualité des équipes de l’ENISA qui sont questionnées, mais bien ses effectifs et sa bande passante.

Pour mémoire, l’Agence européenne emploie une centaine de personnes réparties entre son siège à Athènes, Héraklion et Bruxelles. Un effectif somme toute modeste, surtout si l’on considère l’ampleur des travaux à réaliser, de ses missions quotidiennes à la conception des schémas de certification demandés par le Cybersecurity Act, en passant par la création d’une base de données européenne sur les vulnérabilités suite à NIS2, à l’image de la base CVE maintenue par le MITRE. Autant de tâches auxquelles s’ajoutent les impératifs du CRA, comme la plateforme de signalement ou les rapports techniques bisannuels sur les tendances émergentes en matière de risques cyber dans les produits comportant des éléments numériques (Article 17).

Qu’est-ce qu’un “incident grave” ?

C’est bien beau de devoir signaler les incidents graves, mais encore faut-il savoir de quoi il s’agit ! Heureusement, l’Article 14.5 du Cyber Resilience Act est là pour nous éclairer.

Un incident ayant un impact sur la sécurité du produit est considéré comme grave lorsque :

  • Il entache ou est susceptible d’entacher la capacité d’un produit comportant des éléments numériques à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes ; ou
  • Il a conduit ou est susceptible de conduire à l’introduction ou à l’exécution d’un code malveillant dans un produit comportant des éléments numériques ou dans le réseau et les systèmes d’information d’un utilisateur du produit.

Qu’est-ce qu’une “vulnérabilité activement exploitée” ?

Pour trouver la réponse, il faut se tourner vers l’Article 3 du CRA, consacré aux définitions.

“‘Vulnérabilité activement exploitée’ : une vulnérabilité pour laquelle il existe des preuves fiables qu’elle a été exploitée par un acteur malveillant dans un système sans l’autorisation du propriétaire du système.” – CRA, Article 3.42

Les délais obligatoires de signalement d’un incident grave

Les délais de signalement relatifs aux incidents graves sont détaillés dans l’Article 14.4. On ne peut que saluer la décision du régulateur de s’aligner sur les délais de notification introduits par la Directive NIS2, afin de standardiser les processus à travers l’Union et de simplifier la vie des entités régulées.

CRA - Chronologie des obligations de réponse en cas d'incident grave impliquant un produit contenant des éléments numériques

En cas d’incident grave, le fabricant doit soumettre simultanément à l’ENISA et au CSIRT compétent :

  1. Une première notification au plus tard 24 heures après en avoir pris connaissance. Elle doit indiquer, au minimum, si l’incident est suspecté d’avoir été causé par des actes illicites ou malveillants et, le cas échéant, les pays de l’UE dans lesquels le produit a été mis à disposition ;
  2. Une deuxième notification au plus tard 72h après avoir pris connaissance de l’incident, à moins que les informations pertinentes n’aient déjà été communiquées. Elle doit fournir :
    • les informations générales disponibles sur la nature de l’incident ;
    • l’évaluation initiale de l’incident, ainsi que toute mesure corrective ou d’atténuation qui a été prise ;
    • les mesures correctives ou d’atténuation que les utilisateurs peuvent prendre ;
    • s’il y a lieu, le degré de sensibilité que le fabricant prête aux informations notifiées.
  3. Un rapport final dans un délai d’un mois à compter de la précédente notification, à moins que les informations pertinentes n’aient déjà été communiquées. Ce rapport doit comprendre au moins :
    • une description détaillée de l’incident, y compris de sa gravité et de son impact ;
    • le type de menace ou la cause profonde qui a probablement déclenché l’incident ;
    • les mesures d’atténuation appliquées et en cours.

Les délais obligatoires de signalement d’une vulnérabilité activement exploitée

Les délais de signalement relatifs aux vulnérabilités exploitées sont détaillés dans l’Article 14.2. Là encore, la Loi sur la cyber-résilience s’aligne peu ou prou sur les mêmes fenêtres que NIS2.

CRA - Chronologie des obligations de réponse en cas de vulnérabilité activement exploitée dans un produit contenant des éléments numériques

En cas de vulnérabilité activement exploitée, le fabricant doit soumettre simultanément à l’ENISA et au CSIRT compétent :

  1. Une première notification au plus tard 24 heures après en avoir pris connaissance. Elle doit indiquer les États membres de l’UE dans lesquels le produit a, à sa connaissance, été mis à disposition ;
  2. Une deuxième notification au plus tard 72h après en avoir pris connaissance, à moins que les informations pertinentes n’aient déjà été communiquées. Elle doit préciser :
    • les informations générales disponibles sur le produit concerné ;
    • la nature générale de l’exploitation et de la vulnérabilité concernée ;
    • toute mesure corrective ou d’atténuation qui a été prise ;
    • les mesures correctives ou d’atténuation que les utilisateurs peuvent prendre ;
    • s’il y a lieu, le degré de sensibilité que le fabricant prête aux informations notifiées.
  3. Un rapport final au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation, à moins que les informations pertinentes n’aient déjà été communiquées. Ce rapport doit comprendre au moins :
    • une description de la vulnérabilité, y compris de sa gravité et de son impact ;
    • le cas échéant, des informations concernant tout acteur malveillant ayant exploité ou exploitant la vulnérabilité ;
    • des précisions concernant la mise à jour de sécurité ou les autres mesures correctives qui ont été mises en place pour remédier à la vulnérabilité.

Une obligation de prévenir les utilisateurs affectés

Dans son Article 14.8, le CRA introduit également une notion de notification aux utilisateurs d’un produit sujet à un incident grave ou à une vulnérabilité exploitée.

“Après avoir pris connaissance d’une vulnérabilité activement exploitée ou d’un incident grave, le fabricant informe les utilisateurs du produit affectés et, s’il y a lieu, tous les utilisateurs de la vulnérabilité activement exploitée ou de l’incident grave ayant un impact sur la sécurité du produit et, le cas échéant, de toute mesure corrective ou d’atténuation des risques que les utilisateurs peuvent mettre en place pour atténuer l’impact de cette vulnérabilité ou de cet incident, s’il y a lieu dans un format structuré, pouvant être facilement traité automatiquement et lisible par machine.

Lorsque le fabricant n’informe pas les utilisateurs du produit […] en temps utile, les CSIRT notifiés désignés comme coordinateurs peuvent fournir ces informations aux utilisateurs lorsqu’ils le jugent proportionné et nécessaire pour prévenir ou atténuer l’impact de cette vulnérabilité ou de cet incident.” – CRA, Article 14.8

Le texte prend soin de distinguer les utilisateurs affectés, qu’il faut prévenir quoiqu’il arrive, de l’ensemble des utilisateurs du produit, qu’il faut prévenir “s’il y a lieu”. Dans les deux cas, la notification aux utilisateurs doit s’accompagner des mesures correctives ou d’atténuation qu’ils peuvent mettre en place – sans quoi le signalement n’aurait de toute façon que peu d’intérêt, voire causerait plus de tort que de bien…

Le sujet épineux de la notification aux utilisateurs

En effet, la notification des utilisateurs est un sujet sensible, où tout est question de timing – timing qui n’est pas spécifié par le Cyber Resilience Act, tant il sera spécifique à chaque situation.

Pour simplifier, on peut envisager trois possibilités :

  • Trop tôt : Notifier les utilisateurs avant le déploiement d’une mise à jour les mettrait en danger, car cela alerterait également certains acteurs malveillants qui pourraient tenter de tirer profit de l’information.
  • Lors du déploiement d’une mise à jour : Informer les utilisateurs des détails d’une vulnérabilité dès qu’une mise à jour est disponible pourrait exposer ceux qui ne l’appliquent pas immédiatement ; ce qui n’est pas rare dans le cas des produits IoT, qui ne sont parfois jamais mis à jour par les utilisateurs, voire jamais connectés à l’internet, entravant les mises à jour automatiques des fabricants.
  • Trop tard : Ne jamais avertir les utilisateurs, ou les avertir trop tard, c’est courir le risque de les laisser vulnérables à une menace dont ils ne sont pas conscients, et face à laquelle ils ne chercheront pas à appliquer un correctif.

Comme disait un grand scribe de son temps : il n’y a pas vraiment de bonne ou de mauvaise situation. Il appartiendra aux fabricants d’évaluer la situation en fonction de la nature du problème, de celle du produit, mais aussi de celle des utilisateurs.

En effet, les enjeux de la notification aux utilisateurs ne seront pas les mêmes selon les profils concernés. Une vulnérabilité exploitée dans le grille-pain connecté de M. Tout-le-monde n’aura pas les mêmes conséquences qu’une vulnérabilité dans un lecteur de cartes à puce intégré dans tous les distributeurs de billets de France et de Navarre.

C’est notamment pour cette raison que le CRA donne aux CSIRT le droit d’informer les utilisateurs si le fabricant ne le fait pas, et s’ils le jugent “proportionné et nécessaire pour prévenir ou atténuer” les conséquences. Il y a fort à parier que cette mesure sera peu voire jamais appliquée dans le cas d’utilisateurs particuliers, mais elle peut permettre d’alerter efficacement des utilisateurs qui seraient des entités sensibles ou critiques, telles que celles réglementées par NIS2.

Enfin, rappelons que, si le CRA demande aux fabricants de “partager et divulguer publiquement des informations sur les vulnérabilités corrigées” dès qu’une mise à jour a été distribuée, il laisse aussi une certaine marge de manœuvre en acceptant que la diffusion de certaines informations soit retardée si des raisons de sécurité l’exigent. Nous vous renvoyons ici au Chapitre 14 de ce guide consacré aux mises à jour.

11. Mettez en place une politique de divulgation coordonnée des vulnérabilités (CVD)

Mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités est une obligation pour les fabricants, puisque ce n’est autre que la cinquième exigence essentielle du CRA en matière de gestion des vulnérabilités. La divulgation coordonnée des vulnérabilités est aussi appelée Coordinated Vulnerability Disclosure (CVD) ou Responsible Disclosure (divulgation responsable), tous ces termes étant utilisés de manière interchangeable.

Ce concept est né de la relation entre les entreprises et les hackers éthiques. Si certains hackers bienveillants souhaitaient exposer les vulnérabilités sur la place publique pour prévenir les utilisateurs, certaines organisations préféraient quant à elles les passer sous silence indéfiniment. En règle générale, aucune de ces deux attitudes ne sert correctement l’intérêt général et la sécurité de tous. La divulgation coordonnée des vulnérabilités s’est alors imposée comme un bon compromis, qui satisfait à la fois l’intérêt général et celui de toutes les parties prenantes.

Avec la divulgation responsable, les fabricants et les chercheurs en sécurité s’engagent à communiquer aux utilisateurs les éventuelles vulnérabilités dans un produit, mais pas avant qu’un correctif ne soit disponible. Les utilisateurs peuvent alors adopter les mesures de correction, sans être à l’entière merci d’une vulnérabilité exploitable.

Qu’est-ce que la divulgation coordonnée des vulnérabilités ?

La divulgation coordonnée des vulnérabilités (CVD) est le processus de collaboration entre les propriétaires d’actifs numériques et les personnes susceptibles de signaler une vulnérabilité dans ces actifs. Dans le contexte du CRA, les actifs sont les produits réglementés, les propriétaires sont les fabricants, et les personnes qui peuvent signaler les vulnérabilités sont tout un chacun. Néanmoins, comme l’identification d’une vulnérabilité dans un produit requiert un certain niveau d’expertise, les signalements sont généralement effectués par des chercheurs en sécurité, ou hackers éthiques.

Le processus de CVD commence par la collecte d’informations sur une vulnérabilité auprès de la communauté des chercheurs, et se poursuit par la coordination de ces informations entre les chercheurs et les fabricants. Il peut conduire à une divulgation coordonnée de la vulnérabilité (d’où son nom) : une divulgation publique après une remédiation appropriée qui sert les intérêts et la sécurité de toutes les parties concernées – le chercheur, les utilisateurs et le fabricant, mais aussi ses partenaires, ses fournisseurs et potentiellement le grand public.

Qu’est-ce qu’une politique de divulgation coordonnée des vulnérabilités ?

La politique de CVD est, comme son nom l’indique, une politique. Il s’agit d’un document qui consigne tout ce que le fabricant met en place pour faciliter le processus de divulgation responsable : le canal de communication mis à disposition pour le signalement des vulnérabilités, les parties prenantes internes, la procédure de traitement des signalements reçus et toutes les étapes de la collaboration, du premier contact jusqu’au déploiement d’un correctif et à la prévention des utilisateurs.

En d’autres termes, il s’agit de définir clairement et par écrit le processus de divulgation responsable, afin de s’assurer qu’il existe un plan d’action à suivre le jour où une vulnérabilité est signalée. On rappelle que la mise en place d’une politique de CVD est une exigence essentielle obligatoire du Cyber Resilience Act.

Si vous souhaitez approfondir la question, nous vous recommandons la lecture du CERT Guide to Coordinated Vulnerability Disclosure de l’Université Carnegie Mellon. Bien que publié en 2017, il reste l’un des documents de référence sur le sujet. Les standards ISO/IEC 29147:2020 et ISO/IEC 30111:2020 peuvent également se révéler utiles. Le premier propose des lignes directrices pour la divulgation des vulnérabilités, mais sans entrer dans les détails de la CVD, et le second se concentre sur les processus de gestion des vulnérabilités, y compris la divulgation responsable, bien qu’à un niveau théorique.

Mettre en place un canal de communication pour le signalement des vulnérabilités

Le processus de divulgation responsable commence lorsqu’une personne informe le fabricant d’une vulnérabilité potentielle dans un produit. Mais pour que cela soit possible, le fabricant doit avoir mis en place un canal de communication public dédié au signalement des vulnérabilités, et l’avoir clairement indiqué aux utilisateurs. La mise en place d’une telle adresse de contact est une obligation pour les fabricants, puisqu’il s’agit de la sixième exigence essentielle du CRA en matière de gestion des vulnérabilités.

“Toute politique de divulgation coordonnée des vulnérabilités par les fabricants devrait définir un processus structuré dans lequel les vulnérabilités sont signalées à un fabricant de manière à lui donner la possibilité de diagnostiquer la vulnérabilité et d’y remédier avant que des informations détaillées à ce sujet soient divulguées à des tiers ou au public.” – CRA, Considérant 77

Ce canal de communication porte un nom : un programme de divulgation des vulnérabilités, ou Vulnerability Disclosure Program (VDP). Il est important de comprendre que le VDP est un élément de la politique de CVD, mais que ce sont deux choses distinctes. Le premier est un canal de communication, là où le second est un document qui définit les étapes du processus de divulgation responsable.

Le programme de divulgation des vulnérabilités (VDP)

Un Vulnerability Disclosure Program (VDP) est un canal structuré fourni par une organisation pour que quiconque puisse lui signaler un problème de sécurité numérique. En d’autres termes, il s’agit d’un moyen sûr pour que les tiers sachent où et comment signaler des vulnérabilités.

Il est tout à fait possible de rédiger et mettre en place un VDP par soi-même. Il existe de nombreuses ressources pour vous guider, comme par exemple :

  • le site Disclose.io, qui propose un générateur de politique de divulgation des vulnérabilités ;
  • le site securitytxt.org, qui aide à créer des fichiers security.txt .

En effet, il est de bon ton d’indiquer le moyen de contact prévu par votre VDP dans une notice security.txt, disponible à l’adresse www.siteweb.tld/.well-known/security.txt. A titre d’exemple, voici le security.txt du site Yogosha.

Mettre en place un VDP gratuitement avec Yogosha

Une autre solution est de faire appel à une plateforme spécialisée pour créer et héberger votre VDP. Un exercice auquel nous sommes habitués chez Yogosha, puisque nous proposons des VDP à nos clients depuis 2015. D’ailleurs, la mise en place d’un VDP avec Yogosha est totalement gratuite pour les clients de nos tests de Sécurité Offensive.

Nous accompagnons les organisations à chaque étape du parcours, de la rédaction de la politique de divulgation – scope, règles de divulgation, directives, clauses juridiques et dites “Safe Harbor”, etc. – et nous mettons à disposition une plateforme sécurisée pour collecter et centraliser tous les rapports de vulnérabilités soumis.

Mettre en place un programme de Bug Bounty

Le bug bounty, ou “prime aux bogues”, est un élément important des politiques de divulgation coordonnée des vulnérabilités les plus solides, au point d’être recommandé par le considérant 77 du Cyber Resilience Act.

“[…] Étant donné que les informations sur les vulnérabilités exploitables dans les produits comportant des éléments numériques largement utilisés peuvent être vendues à des prix élevés sur le marché noir, les fabricants de ces produits devraient pouvoir utiliser, dans le cadre de leurs politiques de divulgation coordonnée des vulnérabilités, des programmes visant à encourager le signalement des vulnérabilités en veillant à ce que les personnes ou les entités soient reconnues et récompensées pour leurs efforts. Il s’agit de ce que l’on appelle les programmes dits de «prime aux bogues».– CRA, Considérant 77

La mise en place d’un programme de bug bounty n’est donc pas une obligation pour les fabricants, mais une bonne pratique recommandée dans le cadre de la politique de CVD, qui elle est obligatoire.

La raison d’être du bug bounty dans une politique de divulgation responsable est très clairement expliquée par le considérant 77 : puisque les informations sur les vulnérabilités peuvent être revendues à prix d’or sur le marché noir, il est important de récompenser les chercheurs bienveillants pour leurs efforts. Du point de vue des fabricants, il est préférable d’encourager et de récompenser la collecte d’informations sur des vulnérabilités potentiellement critiques, plutôt que de les voir exploitées plus tard par des acteurs malveillants. Il existe des failles dans tous les systèmes, et l’enjeu est le même pour les “gentils” comme pour les “méchants” : identifier les vulnérabilités en premier.

Ils font du bug bounty, ils racontent.

Le bug bounty comme test de sécurité dans le cadre du CRA

Le bug bounty n’est pas seulement un élément de la politique de divulgation responsable, mais aussi un test de sécurité à part entière. Il permet donc de se conformer non pas à une, mais à deux exigences essentielles du règlement : la mise en œuvre d’une politique de CVD et la réalisation de tests efficaces et réguliers.

Le bug bounty est un moyen de tester le niveau de cybersécurité d’un système en le confrontant à la réalité du terrain. Les fabricants peuvent mobiliser de quelques dizaines à plusieurs centaines de chercheurs en sécurité pour tester la sécurité des produits dans des conditions au plus proche du réel.

C’est un exercice qui intervient après les tests précédents, en complément du test d’intrusion, et qui permet d’aller chercher les angles morts, les vulnérabilités complexes et à haut risque. Les chercheurs examinent les actifs en utilisant toute une série de tactiques, de techniques et de procédures (TTP) pour déceler les vulnérabilités critiques en profondeur, qui échappent à d’autres formes de tests plus calibrées, comme les scanners automatiques.

Lire aussi : Bug Bounty, avantages et inconvénients

Le bug bounty présente un autre avantage pour les fabricants : il adopte une logique de paiement au résultat. Les entreprises versent une récompense monétaire aux chercheurs seulement s’ils parviennent à identifier des failles. Plus la vulnérabilité est critique, plus la prime est importante. Et si les chercheurs ne trouvent rien, l’entreprise ne dépense rien.

Nous pourrions vous parler du sujet pendant des heures, puisque Yogosha est un spécialiste reconnu du bug bounty depuis 2015. Mais ce guide est déjà assez long comme ça, alors nous dirons seulement ceci :

  • La Yogosha Strike Force (YSF) est une communauté de plus de 1000 chercheurs en sécurité internationaux certifiés. Ils sont spécialisés dans la recherche des vulnérabilités critiques, experts dans de multiples types d’actifs et de technologies, et titulaires de certifications reconnues en matière de cybersécurité – OSCP, OSEP, OSWE, OSEE, GXPN, GCPN, eWPTX, PNPT, CISSP… Nous sélectionnons uniquement les chercheurs les plus talentueux : seuls 10% des candidats sont acceptés, après avoir réussi des examens techniques et pédagogiques. Leur identité et leurs antécédents sont également vérifiés.
  • Les vulnérabilités découvertes sont signalées en direct sur notre plateforme de Sécurité Offensive, et documentées avec leur score CVSS, des preuves de concept (POC) et des conseils de remédiation.
  • Yogosha est la seule plateforme de bug bounty entièrement privée en Europe. Notre communauté d’experts est fermée et sélective, et tous nos programmes de bug bounty sont privés et confidentiels.

12. Indiquez un point de contact unique pour les utilisateurs, ainsi que les informations et instructions à leur intention

Au-delà de la divulgation responsable et du bug bounty, il est essentiel que tous les utilisateurs d’un produit connecté sachent clairement quel moyen de communication utiliser pour les sujets liés à la cybersécurité. À cette fin, l’Article 13.17 du CRA exige des fabricants qu’ils définissent “un point de contact unique pour permettre aux utilisateurs de communiquer directement et rapidement avec [eux].”

Si ce n’est pas déjà le cas, et si la structure de votre organisation le permet, nous ne pouvons que recommander la mise en place d’une Product Security Incident Response Team (PSIRT), qui constituera un point de contact tout désigné. Les PSIRT sont les alter-egos des CSIRT, mais spécialisés dans les produits. Ils sont chargés de leur sécurité, et de la réponse aux incidents liés à leurs vulnérabilités.

Les utilisateurs doivent pouvoir choisir “leurs moyens de communication préférés”, et le point de contact unique ne peut être limité à des outils automatisés.

“Lorsque les fabricants optent pour des outils automatisés, par exemple des chatbots, ils doivent également proposer un numéro de téléphone ou d’autres moyens de contact numériques, tels qu’une adresse électronique ou un formulaire de contact. Le point de contact unique ne doit pas dépendre uniquement d’outils automatisés.– CRA, Considérant 64

Il doit être tenu à jour, facilement identifiable par les utilisateurs, et figurer dans les informations et instructions à leur intention – oui, encore plus de paperasserie.

La liste des éléments à inclure dans les informations et instructions aux utilisateurs

Les informations et instructions à destination des utilisateurs sont un document obligatoire, qui doit accompagner tout produit mis sur le marché “sous forme papier ou électronique”. Ce document étant destiné au grand public, le CRA prend soin de préciser que les informations doivent être “claires, compréhensibles, intelligibles et lisibles.” (Article 13.18)

Les informations et instructions destinées aux utilisateurs doivent inclure au minimum tous les éléments listés dans l’Annexe II, à savoir :

  1. Le nom, la raison sociale ou la marque déposée du fabricant et l’adresse postale, l’adresse électronique ou tout autre contact numérique ainsi que, le cas échéant, le site internet sur lequel le fabricant peut être contacté ;
  2. Le point de contact unique où les informations sur les vulnérabilités du produit peuvent être signalées et reçues, et où peut être trouvée la politique du fabricant en matière de divulgation coordonnée des vulnérabilités ;
  3. Le nom et type du produit, ainsi que toute information supplémentaire permettant son identification ;
  4. L’utilisation prévue du produit, notamment l’environnement de sécurité fourni par le fabricant, ainsi que ses fonctionnalités essentielles et les informations sur ses propriétés de sécurité ;
  5. Toutes circonstances connues ou prévisibles susceptibles d’entraîner des risques de cybersécurité importants, qu’elles soient liées à l’utilisation prévue du produit ou à des conditions de mauvaise utilisation raisonnablement prévisibles ;
  6. L’adresse internet à laquelle la déclaration UE de conformité peut être consultée, si applicable ;
  7. Le type d’assistance technique en matière de sécurité proposé par le fabricant, et la date de fin de la période de support pendant laquelle les utilisateurs peuvent s’attendre à recevoir des mises à jour de sécurité ;
  8. Des instructions détaillées sur (ou une adresse internet renvoyant vers elles) :
    • les mesures nécessaires lors de la mise en service initiale du produit et pendant toute sa durée de vie pour assurer sa sécurité d’utilisation ;
    • la façon dont les modifications apportées au produit peuvent affecter la sécurité des données ;
    • la façon dont les mises à jour de sécurité peuvent être installées ;
    • la mise hors service sécurisée du produit, en ce compris des informations sur la manière dont les données utilisateur peuvent être supprimées en toute sécurité ;
    • la manière dont le réglage par défaut permettant l’installation automatique des mises à jour de sécurité peut être désactivé ;
    • lorsque le produit est destiné à être intégré dans d’autres produits comportant des éléments numériques, les informations nécessaires à l’intégrateur pour se conformer aux exigences essentielles et aux exigences relatives à la documentation technique.
  9. Des renseignements quant à l’endroit où peuvent être trouvées les informations sur la nomenclature logicielle (SBOM), lorsque le fabricant décide de les mettre à disposition de l’utilisateur.

Ce document doit être tenu à la disposition des utilisateurs et des autorités de surveillance du marché pendant au moins dix ans après la mise sur le marché du produit, y compris en ligne si tel était le cas au départ, ou pendant la période de support, la durée la plus longue étant retenue.

13. Déterminez la période de support du produit

Il est essentiel de fixer la période de support du produit réglementé, car elle déterminera, entre autres choses, la durée pendant laquelle le fabricant doit s’astreindre à mettre à jour l’évaluation des risques évoquée plus avant, ou encore à appliquer toutes les exigences essentielles en matière de gestion des vulnérabilités. Comme le CRA vise la sécurité des produits tout au long de leur cycle de vie, il est important d’en connaître la fin.

C’est aux fabricants de déterminer la période de support de leurs produits, en respectant les garde-fous fixés par l’Article 13.8 du CRA, qui leur dicte de tenir compte :

  • De la durée d’utilisation prévue du produit, eu égard notamment :
    • aux attentes raisonnables des utilisateurs ;
    • à la nature du produit, et à son usage prévu ;
    • du droit applicable de l’Union pertinent pour déterminer la durée de vie dudit produit.
  • De la période de support des produits offrant une fonctionnalité similaire mis sur le marché par d’autres fabricants ;
  • De la disponibilité de l’environnement d’exploitation ;
  • De la période de support des composants tiers intégrés qui fournissent des fonctions essentielles ;
  • Des recommandations du groupe ADCO (Administrative Cooperation Group) qui sera créé dans le cadre du CRA. Ce dernier pourra d’ailleurs émettre des recommandations sur la période de support minimale attendue de certaines catégories de produits.

Dans tous les cas, la période de support d’un produit ne peut pas être inférieure à 5 ans, ou doit être égale à la durée d’utilisation prévue du produit si celle-ci est inférieure à 5 ans. Les informations utilisées pour déterminer la période de support doivent être incluses dans la documentation technique accompagnant le produit.

14. Assurez la disponibilité des mises à jour de sécurité pendant au moins 10 ans

Les mises à jour de sécurité doivent être tenues à la disposition des utilisateurs pendant au moins 10 ans, quand bien même la période de support du produit serait plus courte.

“Les fabricants veillent à ce que chaque mise à jour de sécurité qui a été mise à la disposition des utilisateurs pendant la période de support reste disponible après sa publication pendant une durée minimale de 10 ans ou pendant le reste de la période de support, la durée la plus longue étant retenue.” – CRA, Article 13.9

Les mises à jour de sécurité doivent être gratuites et, lorsque cela est techniquement possible, fournies séparément des mises à jour de fonctionnalités. Par ailleurs, si des archives sont maintenues pour le public, il doit y être clairement fait mention des risques de cybersécurité associés à l’utilisation d’une version plus ancienne.

Une obligation de remédier aux vulnérabilités des anciennes versions si la dernière en date est payante

L’obligation pour les fabricants de remédier aux vulnérabilités via des mises à jour de sécurité (cf. les 13 exigences essentielles applicables aux produits) ne s’applique qu’à la dernière version placée sur le marché, si et seulement si “les utilisateurs des versions précédemment mises sur le marché ont accès gratuitement à la dernière version, et n’ont pas à supporter de coûts supplémentaires pour adapter l’environnement matériel et logiciel dans lequel ils utilisent la version originale.” (Article 13.10)

Cette précision est importante dans le cas des solutions logicielles (application, plateforme…) adossées à un produit IoT, qui sont également concernées par le CRA. Les fabricants devront corriger les vulnérabilités et proposer des mises à jour de sécurité pour toutes les versions antérieures dudit logiciel si les utilisateurs doivent payer pour la dernière version, ou pour mettre à niveau l’environnement dans lequel ils l’utilisent.

Dans un registre similaire, la gratuité des mises à jour de sécurité pourrait menacer les business models de support de sécurité étendu, dans lesquels les mises à jour sont gratuites pour la dernière version, mais payantes pour les versions antérieures. Un schéma vertueux qui est le plus souvent utilisé dans le monde de l’open-source afin de financer les nouveaux développements. Ce point faisait d’ailleurs l’objet d’une réserve émise par l’ACN (Alliance pour la Confiance Numérique) début 2023, qui prenait pour exemple le modèle d’OpenSSL.

Des mises à jour à distribuer de manière automatique et “sans délai”

Outre la gratuité, les exigences essentielles relatives aux produits demandent à remédier aux vulnérabilités via “des mises à jour de sécurité automatiques” activées par défaut, tandis que celles relatives aux mesures de gestion des vulnérabilités requièrent de diffuser ces mises à jour “sans délai”. Ces deux injonctions soulèvent un certain nombre de problématiques pour les fabricants, là encore relevées par l’ACN.

La mise à jour automatique d’un produit nécessite qu’il soit connecté à Internet. Cependant, il s’agit d’un paramètre qui dépend de l’utilisateur, et non du fabricant ou du produit. Certains produits numériques peuvent être utilisés pendant une longue période sans être reconnectés par l’utilisateur, voire jamais. Dans ce cas, l’utilisateur est susceptible d’utiliser un produit dont les vulnérabilités sont connues et ont été corrigées par le fabricant, mais sans que ce dernier ne puisse prendre de mesures directes.

Cette même situation pose également un problème au regard d’une autre exigence du CRA, à savoir “partager et divulguer publiquement des informations sur les vulnérabilités corrigées” dès qu’une mise à jour a été distribuée. Mais c’est oublier que, bien souvent, une proportion importante d’utilisateurs ne bénéficiera pas d’emblée de la mise à jour, et se retrouvera donc vulnérable aux attaques d’acteurs malveillants qui auraient appris l’existence de la vulnérabilité à exploiter par le biais des communications du fabricant.

En effet, il n’est pas toujours judicieux de communiquer sur les vulnérabilités dès qu’un correctif est publié, et il peut même arriver que ne jamais communiquer soit la meilleure option. Aussi, nous ne pouvons que recommander aux fabricants d’appliquer judicieusement cette disposition des exigences essentielles en matière de gestion des vulnérabilités :

“Dans des cas dûment justifiés, lorsque les fabricants considèrent que les risques de sécurité liés à la divulgation l’emportent sur les avantages en matière de sécurité, ils peuvent retarder la diffusion des informations concernant une vulnérabilité corrigée jusqu’à ce que les utilisateurs aient eu la possibilité d’appliquer le correctif adapté.” – CRA, Annexe I, Partie II

Les produits exemptés de mises à jour automatiques

Le considérant 57 du CRA précise que les dispositions portant sur les mises à jour automatiques ne s’appliquent pas :

  1. “Aux produits dont les éléments numériques sont principalement destinés à être intégrés en tant que composants dans d’autres produits” ;
  2. “Aux produits pour lesquels les utilisateurs ne s’attendent pas raisonnablement à des mises à jour automatiques, y compris les produits destinés à être utilisés dans des réseaux TIC professionnels, et en particulier dans des environnements critiques et industriels où une mise à jour automatique pourrait perturber les opérations.”

Dans le premier cas, il s’agit des produits eux-mêmes intégrés dans d’autres, pour lesquels il n’est pas possible de pousser les mises à jour directement. En effet, le fabricant d’un microcontrôleur peut mettre à disposition des mises à jour, mais ne peut certainement pas les diffuser de son propre chef s’il est intégré dans un autre produit sur lequel il n’a pas la main. La mise à jour dépend alors du fabricant du produit final.

Dans le deuxième cas, il s’agit des produits dont la mise à jour automatique pourrait avoir des conséquences directes sur l’activité de certains acteurs, notamment industriels. Pas besoin de grand discours pour illustrer le pourquoi du comment : imaginez simplement qu’une station d’épuration ou une centrale nucléaire soit paralysée parce qu’un composant numérique a été mis à jour… L’exemple est exagéré, mais vous voyez l’idée.

15. Établissez une déclaration UE de conformité, et apposez le marquage CE sur les produits

Nous approchons de la fin, mais il reste encore quelques détails administratifs à régler : la déclaration UE de conformité et le marquage CE. Ces éléments doivent être traités une fois que la procédure d’évaluation de la conformité, abordée au Chapitre 9, a été menée à bien.

“Lorsqu’il a été démontré, au moyen de cette procédure d’évaluation de la conformité que le produit comportant des éléments numériques est conforme aux exigences essentielles […] le fabricant établit la déclaration UE de conformité conformément à l’Article 28 et appose le marquage CE conformément à l’Article 30.” – CRA, Article 13.12

La déclaration UE de conformité

La déclaration UE de conformité doit être établie par le fabricant, et attester que le respect des exigences essentielles a été démontré. Elle doit être rédigée selon le modèle disponible à l’annexe V du règlement, dont voici le contenu en l’état :

  1. Nom et type, ainsi que toute information supplémentaire permettant l’identification unique du produit comportant des éléments numériques ;
  2. Nom et adresse du fabricant ou de son mandataire ;
  3. Attestation certifiant que la déclaration UE de conformité est établie sous la seule responsabilité du fournisseur ;
  4. Objet de la déclaration (identification du produit comportant des éléments numériques permettant sa traçabilité et pouvant inclure une photographie) ;
  5. Une mention indiquant que l’objet de la déclaration décrit ci-dessus est conforme à la législation d’harmonisation de l’Union applicable ;
  6. Les références de toute norme harmonisée pertinente appliquée ou de toute autre spécification commune ou certification de cybersécurité par rapport auxquelles la conformité est déclarée ;
  7. Le cas échéant, le nom et le numéro de l’organisme notifié, une description de la procédure d’évaluation de la conformité suivie et la référence du certificat délivré ;
  8. Informations supplémentaires : (à compléter si nécessaire) ;
  9. Signé par et au nom de : (date et lieu d’établissement).

Un modèle de déclaration simplifiée est disponible à l’annexe VI, à l’intention des PME et des startups. Par ailleurs, précisons que la déclaration UE de conformité doit être tenue à la disposition des autorités de surveillance du marché pendant une durée d’au moins dix ans après la mise sur le marché du produit, ou pendant la période de support, la période la plus longue étant retenue.

Le marquage CE

Les règles et conditions d’apposition du marquage CE sont définies à l’Article 30 du CRA. Il est obligatoire et doit être apposé de manière visible, lisible et indélébile sur les produits. Nous n’allons pas détailler toutes les règles liées au marquage CE, car cela sort de notre domaine d’expertise, à savoir la cybersécurité, et nous considérons que les fabricants sont déjà bien au fait de ce sujet qui n’est pas nouveau. Nous vous renvoyons donc à l’Article 30 du règlement pour de plus amples informations.

Conclusion

Le Cyber Resilience Act est attendu pour 2024, et entrera en application trois ans après sa publication au Journal Officiel de l’Union, ce qui amène à une date butoir de mise en conformité pour les fabricants courant 2027. Par ailleurs, les obligations de signalement des incidents graves et des vulnérabilités activement exploitées (voir Chapitre 10) seront quant à elles applicables après 21 mois, soit dès 2026.

L’heure n’est pas encore à l’urgence, mais il n’y a pas de temps à perdre. Les obligations amenées par le CRA sont nombreuses, et trois années ne seront pas de trop pour faire les choses dans les règles de l’art. Nous conseillons donc à tous les gestionnaires de la sécurité des entités concernées par le CRA de travailler dès maintenant à leur mise en conformité. Comme dit l’adage, mieux vaut prévenir que guérir.

L’essentiel du travail devrait s’articuler autour des 21 exigences essentielles du Cyber Resilience Act. Treize d’entre elles concernent la cybersécurité des produits et huit la gestion des vulnérabilités. Elles sont toutes obligatoires et représentent l’essentiel des efforts à fournir pour rendre les produits sécurisés et conformes. Nous vous conseillons de commencer par mettre en place les processus liés au signalement des incidents graves et des vulnérabilités exploitées, car cette obligation entrera en vigueur avant les autres.

Pour plus d’informations sur les exigences essentielles, nous vous renvoyons vers le Chapitre 2 de ce guide et vers l’Annexe I du règlement. La documentation technique (voir Chapitre 4) est également une excellente feuille de route, puisqu’elle énumère à peu près tout ce qui doit être fait dans le cadre du CRA.

Après les exigences essentielles viendra l’évaluation de la conformité (voir Chapitre 9), dont la procédure et la charge de travail associée dépendront de la sensibilité du produit concerné. A cela s’ajouteront toutes les formalités administratives à accomplir, de la documentation technique à la déclaration UE de conformité.

Enfin, rappelons que la réalisation de tests de cybersécurité réguliers constitue une étape importante de la mise en conformité, et une exigence essentielle en soi. Ils permettent de s’assurer que les produits mis sur le marché européen sont correctement sécurisés, qu’ils ne présentent pas de vulnérabilités graves et qu’ils ne constituent pas un danger pour leurs utilisateurs, qu’il s’agisse de particuliers ou d’entreprises.

Quand viendra le moment de réaliser des tests, n’hésitez pas à nous contacter. Yogosha est un spécialiste européen de la Sécurité Offensive reconnu depuis 2015, et nous proposons plusieurs types de tests dans le cadre du CRA :

  • Pentest as a Service (PtaaS) : Des tests d’intrusion lancés de manière rapide, agile et continue pour répondre à l’une des préoccupations majeures du règlement : la sécurité des produits tout au long du cycle de vie. Accédez à une communauté internationale de plus de 1000 chercheurs en sécurité certifiés et triés sur le volet, et recevez des rapports de vulnérabilités en temps réel via notre plateforme.
  • Bug Bounty : Un test de sécurité à part entière, mais également un élément de la politique de divulgation coordonnée des vulnérabilités demandée par le CRA (voir Chapitre 11). Évaluez la sécurité de vos produits en continu et identifiez les vulnérabilités critiques restées dans l’ombre. Récompensez, corrigez et re-testez avec agilité avant qu’elles ne soient exploitées.

Il ne nous reste plus qu’à vous souhaiter bonne chance dans votre démarche de mise en conformité avec le Cyber Resilience Act. Et si d’aventure vous avez besoin d’un conseil à quelque étape que ce soit, voire d’un accompagnement expert, n’hésitez pas à nous contacter.