Exigences de sécurité pour les produits connectés : la rupture imposée par le Cyber Resilience Act

Cyber Resilience Act : ce qui entre dans le champ d’application – et ce qui en sort

Le CRA s’applique à tous les produits contenant des éléments numériques. Cela inclut aussi bien les matériels que les logiciels, dès lors qu’ils peuvent être connectés directement ou indirectement à un réseau. Sont ainsi concernés les objets connectés, les systèmes de contrôle industriels, les systèmes d’exploitation, les micrologiciels ou encore les logiciels de communication. Même les fonctionnalités Software-as-a-Service peuvent être incluses, dès lors qu’elles impliquent un traitement de données à distance.
Des exceptions sont prévues pour certains secteurs déjà encadrés par des exigences de sécurité, notamment les dispositifs médicaux, les véhicules, l’aéronautique ou certains composants de l’industrie de la défense. Les logiciels open source sont également exclus, à condition qu’ils ne soient pas exploités à des fins commerciales. Cependant, dès qu’un service de support ou de conseil est proposé, les exigences du CRA s’appliquent également. Cela concerne en particulier les fournisseurs qui réutilisent de l’open source dans des produits commerciaux.

Qui est concerné par le CRA ? Fabricants, fournisseurs, distributeurs

La responsabilité de mise en conformité au CRA incombe à celui qui met un produit sur le marché de l’UE pour la première fois. Il peut s’agir du fabricant lui-même, d’un importateur ou d’un distributeur. Le critère déterminant n’est pas le lieu d’implantation de l’entreprise, mais son accès au marché européen.

Les fournisseurs et éditeurs de logiciels sont eux aussi concernés, même s’ils n’opèrent pas directement sur le marché. Les fabricants doivent en effet documenter et sécuriser l’ensemble de leur chaîne d’approvisionnement. Toute personne fournissant des composants, des bibliothèques ou des logiciels embarqués entre ainsi dans le champ du règlement. Le CRA impose ici un nouveau niveau de transparence.

Obligations et exigences : le CRA transforme le développement produit

Les exigences centrales comprennent :
– une évaluation des risques avant mise sur le marché,
– une documentation sur l’architecture, les fonctions de sécurité et les analyses de risque,
– une approche de sécurité dès la conception,
– un processus de gestion des vulnérabilités sur tout le cycle de vie du produit,
– l’obligation de fournir des mises à jour de sécurité pendant la durée d’utilisation (au minimum cinq ans ou selon la durée de vie prévue),
– et l’obligation de signaler incidents et vulnérabilités aux autorités nationales et à l’ENISA dans un délai de 24 heures.

Il ne s’agit pas seulement de mesures techniques. Les processus organisationnels et la capacité de réaction face aux incidents doivent également être documentés. Il est essentiel que les produits soient livrés avec une configuration sécurisée dès leur sortie d’usine. Les fonctions de journalisation, de gestion des utilisateurs, de contrôle des interfaces, ainsi qu’un inventaire des composants logiciels utilisés (sous forme de SBOM – Software Bill of Materials) font partie des exigences.

Conséquences pour les produits existants

Les produits déjà présents sur le marché peuvent aussi être concernés par le CRA, notamment s’ils sont à nouveau fabriqués ou modifiés après l’entrée en vigueur du règlement. Cela soulève la question de leur capacité à être mis à jour et adaptés aux nouvelles exigences de sécurité. Cela pose un problème particulier pour les produits à architecture figée. Pour les entreprises qui misent sur des cycles produits longs, cela devient un risque stratégique.

Documentation technique et communication des risques

La documentation technique constitue un pilier central. Elle doit permettre aux autorités de surveillance du marché et aux clients de comprendre les caractéristiques de sécurité du produit, les risques identifiés et les mesures de protection mises en place. Pour les produits existants, il est recommandé de revoir cette documentation et d’ajouter une analyse de risque structurée.

Pour les nouveaux produits, cette analyse doit faire partie intégrante du processus de développement. Il s’agit non seulement d’évaluer comment le produit réduit les risques, mais aussi comment il s’intègre dans des scénarios d’utilisation concrets. La connaissance des conditions réelles d’utilisation par les clients est ici essentielle. Celui qui peut identifier et expliciter ces risques peut, dans certains cas, renoncer à certaines mesures techniques, à condition qu’elles soient compensées par des mesures organisationnelles ou opérationnelles.

Chaîne d’approvisionnement, fournisseurs et composants logiciels tiers

Les fabricants doivent garder une vue d’ensemble : quels composants sont utilisés, quelles bibliothèques sont intégrées, quelles sont les dépendances existantes ? Les bibliothèques tierces et les composants open source présentent un risque particulier. Le fait qu’ils puissent ne plus être maintenus ou mis à jour doit être anticipé.

Le CRA reste volontairement vague sur la manière de gérer ces risques au cas par cas. Mais une chose est claire : les fabricants doivent garantir la sécurité de leurs produits même si un fournisseur se retire. La capacité à remplacer des composants, à appliquer leurs propres correctifs et à gérer proprement la liste des logiciels utilisés devient donc impérative.

Classification, conformité, certification du Cyber Resilience Act

Le CRA classe les produits selon différents niveaux de risque. Pour les groupes de produits jugés particulièrement critiques, une évaluation de conformité externe par un organisme notifié est obligatoire. Dans les cas moins sensibles, une auto-déclaration peut suffire.
Seulement, même cette auto-déclaration doit s’appuyer sur une analyse structurée et une documentation complète. Des déclarations erronées, des lacunes dans l’implémentation ou un contrôle insuffisant peuvent entraîner des sanctions importantes, allant jusqu’à la perte du marquage CE et l’interdiction de mise sur le marché européen.

CRA : ce qu’il faut faire maintenant

Les entreprises doivent analyser leur portefeuille produits afin d’identifier ceux qui entrent dans le champ du CRA. Les nouveaux produits comme ceux déjà commercialisés doivent être évalués. En l’absence de possibilité d’adaptation, des alternatives ou des stratégies de retrait doivent être élaborées.
Il est également recommandé d’impliquer des experts en cybersécurité le plus tôt possible dans les processus de développement. Cela concerne particulièrement les PME, où la sécurité a souvent été un sujet marginal. Le CRA change la donne. Il impose aussi de mettre en place des processus organisationnels clairs, de définir les responsabilités et d’ancrer une véritable culture de la sécurité dans l’entreprise.

Regarder vers l’avenir : le CRA comme opportunité

Aussi contraignante soit-elle, cette transformation représente aussi une opportunité. Les entreprises capables de prouver qu’elles conçoivent des produits sûrs, bien documentés et maintenus tout au long de leur cycle de vie se distingueront de la concurrence. La cybersécurité devient ainsi non seulement une obligation, mais un véritable argument de qualité sur le marché.

Et elle devient une condition d’accès au marché européen. Cela seul devrait suffire à convaincre d’agir dès maintenant.