EU Cyber Resilience Act : Ce qui attend les fabricants et les distributeurs de logiciels

Le EU Cyber Resilience Act (CRA) est plus qu’une simple exigence de conformité. Il transforme fondamentalement la manière dont les entreprises doivent développer, tester et mettre sur le marché les produits numériques. Ceux qui commencent dès maintenant à se préparer auront un avantage considérable sur leurs concurrents qui attendront jusqu’à la dernière minute.

L’essentiel

Tous les « produits avec des éléments numériques » sont concernés : Des appareils IoT aux logiciels – si une connexion réseau est présente, le CRA s’applique.
La sécurité par conception devient obligatoire : La sécurité doit être intégrée dès la phase de développement, et non ajoutée par la suite.
Obligation de support de 5 ans : Les fabricants doivent fournir des mises à jour de sécurité pendant au moins 5 ans ou la durée de vie prévue du produit.
Obligation de déclaration en 24 heures : Les failles activement exploitées doivent être signalées à l’ENISA dans un délai de 24 heures.
Amendes allant jusqu’à 15 millions d’euros : Ou 2,5 % du chiffre d’affaires annuel mondial.

Ce que le CRA réglemente – et ce qu’il ne réglemente pas

Le Cyber Resilience Act s’applique à tous les produits qui peuvent être connectés directement ou indirectement à d’autres appareils ou réseaux. Cela inclut le matériel avec logiciel, les logiciels purs et les SaaS (avec des restrictions). Sont exclus, entre autres, les logiciels open-source sans exploitation commerciale, les dispositifs médicaux (régime propre) et les logiciels automobiles.

Les classes de produits critiques sont plus strictement réglementées : la classe I (par exemple, les gestionnaires de mots de passe, les navigateurs) doit effectuer une évaluation de conformité. La classe II (par exemple, les pare-feu, les microcontrôleurs) nécessite une certification indépendante par un organisme notifié.

Obligations concrètes pour les fabricants

Développement : Mettre en œuvre un Secure Development Lifecycle (SDLC), modélisation des menaces, tests de sécurité, revues de code. Pas en tant qu’add-on, mais comme partie intégrante du processus de développement.

Documentation : Documentation technique, Software Bill of Materials (SBOM), déclaration de conformité – tout cela doit être disponible pour les autorités.

Exploitation : Surveillance des vulnérabilités, gestion des mises à jour, programme de divulgation coordonnée des vulnérabilités (CVD/VDP). Les failles activement exploitées doivent être immédiatement signalées et corrigées.

Déclaration de fin de vie : Si un produit sort du support, les utilisateurs doivent être informés activement et des chemins de migration doivent être communiqués.

Calendrier et prochaines étapes

Le CRA a été proposé par la Commission européenne en septembre 2022. Après le processus législatif européen, il devrait entrer en vigueur en 2024, avec une période de transition de 36 mois – donc application complète vers 2027.

Les fabricants devraient commencer maintenant : analyse des écarts du processus de développement actuel, mise en œuvre de SBOM pour tous les produits, création d’un programme de divulgation des vulnérabilités. 36 mois peuvent sembler longs, mais c’est court pour transformer un processus de développement.

Key Facts en un coup d’œil

Produits concernés dans l’UE : Environ 400 millions + (estimation de la Commission)

Obligation de support : Au moins 5 ans ou durée de vie prévue du produit

Obligation de déclaration des failles activement exploitées : 24 heures à l’ENISA

Amende maximale : 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial

Application complète prévue : 2027 (36 mois après l’entrée en vigueur)

Fait : Selon le Allianz Risk Barometer 2025, les cyberattaques sont le plus grand risque commercial au niveau mondial.

Fait : Seulement 43 % des PME allemandes disposent d’un plan d’urgence informatique, selon Bitkom.

Questions fréquentes

Le CRA s’applique-t-il également aux logiciels open-source ?

Non pour les logiciels open-source non commerciaux. Ceux qui utilisent ou distribuent des logiciels open-source à des fins commerciales peuvent toutefois être concernés. Les stewards de projets open-source critiques en matière de sécurité ont des obligations allégées.

Qu’est-ce qu’un SBOM et pourquoi devient-il important ?

Une Software Bill of Materials (SBOM) est un inventaire lisible par machine de toutes les composantes, dépendances et licences d’un logiciel. Le CRA rend les SBOM obligatoires – et en cas de vulnérabilités, il est immédiatement clair quels produits sont concernés.

Le CRA s’applique-t-il également aux SaaS ?

Oui, en principe, avec des nuances. Les SaaS relèvent du CRA s’ils sont utilisés comme composante dans des produits numériques critiques. Les services B2B purs pourraient avoir des exceptions – le texte final de la réglementation apportera plus de clarté à ce sujet.

Qui contrôle la conformité au CRA ?

Les autorités nationales de surveillance du marché (en Allemagne, le BSI (Office fédéral de la sécurité informatique)) sont compétentes. L’ENISA coordonne au niveau de l’UE et reçoit les signalements de vulnérabilités.

Que doit faire une entreprise maintenant ?

Analyse des écarts : quels produits sont concernés ? Quels sont les manquements en matière de documentation, SBOM, SDLC, VDP ? Élaborer un plan de projet qui soit conforme d’ici 2026/2027. Commencer tôt crée un avantage concurrentiel.