TL;DR

La CRA (Cyber Resilience Act) rend la sécurité obligatoire pour tout ce qui est « numérique » vendu dans l'UE : applications, micrologiciels, IoT, logiciels.

Nécessite la sécurité dès la conception, la mise à jour, les SBOM et la divulgation des vulnérabilités tout au long du cycle de vie d'un produit.

Débute en décembre 2027. En cas de non-conformité ? Attendez-vous à des amendes de plus de 15 millions d'euros ou à des interdictions de marché.

Résumé du tableau de bord Cyber Resilience Act européenne Cyber Resilience Act CRA) :

• Effort de développement : Élevé (Nécessite d'intégrer la sécurité tout au long du cycle de vie du produit : conception sécurisée, codage sécurisé, tests rigoureux, mise en œuvre de processus de gestion des vulnérabilités, fourniture de mises à jour sécurisées, maintenance des SBOMs).
• Coût des outils : modéré à élevé (nécessite des outils SDLC sécurisés -DAST, outils SBOM , gestion des vulnérabilités , infrastructure de mise à jour potentiellement sécurisée - plateformes OTA).
• Impact sur le marché : Très élevé (obligatoire pour presque tous les produits matériels/logiciels vendus dans l'UE ; établit une nouvelle référence mondiale pour les attentes en matière de cybersécurité des produits).
• Flexibilité : Modérée (Définit les exigences essentielles mais permet différentes voies d'évaluation de la conformité basées sur la classification des risques du produit).
• Intensité de l'audit : Modérée à Élevée (nécessite des évaluations de conformité – auto-évaluation pour les produits standards, évaluation par un tiers pour les produits critiques ; les autorités de surveillance du marché appliqueront).

Qu'est-ce que la Cyber Resilience Act européenne Cyber Resilience Act CRA) ?

Cyber Resilience Act européenne Cyber Resilience Act CRA) est un règlement qui établit des exigences harmonisées en matière de cybersécurité pour les « produits comportant des éléments numériques » (PCE) mis à disposition sur le marché de l'Union européenne. Elle vise à lutter contre le problème généralisé de l'insécurité des produits matériels et logiciels et du manque de mises à jour de sécurité en temps opportun.

Le CRA s'applique largement à presque tout produit logiciel ou matériel pouvant se connecter directement ou indirectement à un autre appareil ou réseau, avec quelques exceptions (par exemple, les dispositifs médicaux, l'aviation, les voitures déjà couverts par une législation spécifique, les SaaS sauf s'ils sont critiques). Cela inclut les appareils IoT grand public, les équipements réseau, les composants de contrôle industriel, les systèmes d'exploitation, les applications mobiles, les logiciels de bureau, et bien plus encore.

Piliers clés du CRA :

1. Exigences essentielles en matière de cybersécurité (Annexe I) : Les fabricants doivent s'assurer que les PDE répondent à des objectifs de sécurité spécifiques tout au long de leur cycle de vie. Cela couvre :
   
   • Sécurité dès la conception et par défaut : Les produits doivent être conçus, développés et produits pour garantir un niveau de cybersécurité approprié. Ils doivent être livrés avec une configuration par défaut sécurisée.
   • gestion des vulnérabilités: les fabricants doivent disposer de processus permettant d'identifier et de corriger les vulnérabilités pendant toute la durée de vie prévue du produit ou pendant au moins cinq ans, notamment en fournissant « sans délai » et gratuitement des mises à jour de sécurité.
   • Protection des données : Protection de la confidentialité, de l'intégrité et de la disponibilité des données traitées par le produit.
   • Contrôle d'accès: Prévention des accès non autorisés.
   • Résilience : Capacité à résister et à se remettre des incidents.
   • Minimisation de la surface d'attaque : Limiter les surfaces d'attaque et atténuer l'impact des incidents.
2. Obligations des opérateurs économiques :
   
   • Fabricants : ils sont les premiers responsables de la conformité CRA – conception sécurisée, évaluation de la conformité, documentation technique (y compris SBOM), gestion des vulnérabilités, signalement des incidents/vulnérabilités, fourniture de mises à jour et d'instructions claires. Cela s'applique même s'ils sont basés en dehors de l'UE.
   • Importateurs/Distributeurs : Ont l'obligation de vérifier la conformité du fabricant (par ex., marquage CE, documentation) avant de mettre les produits sur le marché.
3. Gestion et signalement des vulnérabilités : Les fabricants doivent établir des processus pour gérer efficacement les vulnérabilités et signaler les vulnérabilités activement exploitées à l'ENISA (Agence de l'Union européenne pour la cybersécurité) dans les 24 heures suivant leur prise de connaissance. Ils doivent également informer les utilisateurs des vulnérabilités corrigées et des mises à jour disponibles.
4. Évaluation de la conformité et marquage CE : Les PDE doivent subir un processus d'évaluation de la conformité (allant de l'auto-évaluation du fabricant à la certification par un tiers, selon la criticité du produit) pour démontrer leur conformité avant de recevoir un marquage CE et d'être mis sur le marché de l'UE.
5. Surveillance du marché : Désigne les autorités nationales de surveillance du marché pour faire appliquer le CRA, enquêter sur les non-conformités et imposer des sanctions ou exiger le retrait/rappel de produits.

Le CRA est entré en vigueur fin 2024, la plupart des obligations devenant applicables 36 mois plus tard (vers décembre 2027), tandis que les obligations de déclaration des fabricants s'appliquent plus tôt (vers septembre 2026).

Pourquoi est-ce important ?

Le CRA est une législation historique avec des implications significatives :

• Transfert de responsabilité : Place la responsabilité de la sécurité des produits directement sur les fabricants, plutôt que de la laisser principalement aux utilisateurs finaux.
• Élève le niveau de sécurité de base : Établit des normes minimales obligatoires de cybersécurité pour une vaste gamme de produits connectés vendus dans l'UE.
• sécurité de la chaîne d’approvisionnement logicielle: traite les vulnérabilités provenant de composants tiers grâce à des exigences telles que les SBOM et gestion des vulnérabilités du cycle de vie.
• Protège les consommateurs et les entreprises : Vise à réduire le nombre de produits non sécurisés exploités par les attaquants, protégeant les utilisateurs contre les violations de données, les pertes financières et les risques de sécurité.
• Harmonise les exigences : Crée un ensemble unique de règles à l'échelle de l'UE, remplaçant les approches nationales potentiellement fragmentées en matière de cybersécurité des produits.
• Impact mondial : Compte tenu de la taille du marché de l'UE, le CRA établit effectivement une norme mondiale, influençant les fabricants du monde entier qui souhaitent vendre des produits en Europe.
• Complète d'autres réglementations : Fonctionne en parallèle avec NIS2 (sécurisation des services critiques), le RGPD (protection des données personnelles) et DORA (résilience financière) pour créer un paysage de cybersécurité européen plus complet.

Pour les fabricants de logiciels et de matériel connecté, la conformité au CRA deviendra une exigence fondamentale pour l'accès au marché dans l'UE.

Quoi et comment implémenter (Technique et Politique)

La mise en œuvre du CRA nécessite l'intégration de ses exigences essentielles (Annexe I) tout au long du cycle de vie du produit :

1. Conception et développement sécurisés (Sécurité dès la conception) :
   
   • Modélisation des menaces : Identifier les menaces potentielles et concevoir des contrôles de sécurité dès le départ.
   • Pratiques de codage sécurisé : former les développeurs et appliquer des normes de codage sécurisé (par exemple, OWASP ASVS, normes de codage CERT). Utiliser SAST .
   • Minimiser la surface d'attaque : Limiter les fonctionnalités, les ports ouverts et les privilèges au strict minimum nécessaire.
   • Paramètres par défaut sécurisés : S'assurer que les produits sont livrés avec des configurations sécurisées (par exemple, pas de mots de passe par défaut, services inutiles désactivés). Implémenter une fonctionnalité de réinitialisation sécurisée.
   • Protection des données : Mettre en œuvre le chiffrement pour les données au repos et en transit, le cas échéant. Protéger l'intégrité des données.
   • Contrôle d'accès: Mettre en œuvre des mécanismes robustes d'authentification et d'autorisation.
2. gestion des vulnérabilités:
   
   • Analyse des composants (SBOM) : générez et maintenez une liste de matériaux logiciels précise liste de matériaux logiciels SBOM) identifiant tous les composants (y compris les bibliothèques open source). Utilisez SCA pour trouver les vulnérabilités connues dans les dépendances.
   • Tests de sécurité : mettre en œuvre régulièrement des analyses de vulnérabilité (SAST, DAST, SCA, IaC), des tests de robustesse et des tests d'intrusion tout au long du développement et après la mise en production.
   • Processus de gestion des vulnérabilités : Établissez des procédures claires pour la réception des rapports de vulnérabilités (internes/externes), leur analyse, le développement de correctifs et la distribution des mises à jour "sans délai".
   • Patching/Mises à jour: Fournir des mises à jour de sécurité gratuites pendant le cycle de vie prévu du produit (min. 5 ans). Mettre en œuvre un mécanisme de mise à jour sécurisé (par exemple, des mises à jour OTA sécurisées avec des contrôles d'intégrité).
3. Transparence et Documentation :
   
   • Documentation technique : conserver une documentation technique détaillée démontrant la conformité aux exigences essentielles. Inclure la SBOM.
   • Informations utilisateur : Fournissez aux utilisateurs des instructions claires sur l'utilisation sécurisée, la configuration, les mises à jour et la durée de vie du support du produit.
   • Divulgation des vulnérabilités : Établissez une politique et un point de contact pour la réception des rapports de vulnérabilités ; divulguez publiquement les vulnérabilités corrigées.
4. Évaluation de la conformité :
   
   • Classification des risques : Déterminez si le produit relève des catégories par défaut, « importantes » (Classe I) ou « critiques » (Classe II) selon l'Annexe III.
   • Procédure d'évaluation : Suivre la procédure requise (par exemple, contrôle interne/auto-évaluation pour les classes par défaut, évaluation/certification par un tiers pour les classes importantes/critiques).
   • Déclaration et marquage CE : Établir une déclaration de conformité UE et apposer le marquage CE une fois la conformité démontrée.
5. Obligations de reporting :
   
   • Vulnérabilités activement exploitées : À signaler à l'ENISA dans les 24 heures suivant la prise de connaissance.
   • Incidents significatifs : Signalez les incidents affectant la sécurité des produits à l'ENISA.

La mise en œuvre exige d'intégrer la sécurité dans la culture d'ingénierie, les processus et les outils, de la conception à la maintenance.

Erreurs courantes à éviter

Les fabricants qui se préparent au CRA devraient éviter ces erreurs courantes :

1. Sous-estimer la portée : Croire que le CRA ne s'applique qu'aux appareils IoT complexes et non aux logiciels standards ou au matériel plus simple avec des éléments numériques. La portée est très large.
2. Retarder l'action : attendre que la date butoir de 2027 approche, sous-estimer les changements importants requis en matière de conception, de développement, de test, de gestion des vulnérabilités et de processus de mise à jour.
3. Traiter la sécurité comme une réflexion après coup : Ne pas intégrer la sécurité dès la phase de conception ("Security by Design") et tenter de l'ajouter ultérieurement, ce qui est moins efficace et plus coûteux.
4. gestion des vulnérabilités inadéquate gestion des vulnérabilités: absence de processus ou d'outils robustes (SCA, SAST, DAST) pour identifier les vulnérabilités, ou incapacité à fournir des mises à jour de sécurité gratuites et en temps opportun pour le cycle de vie requis.
5. SBOM : ne pas générer une SBOM complète SBOM la maintenir à jour à mesure que les composants changent, ce qui entrave gestion des vulnérabilités.
6. Ignorer les mécanismes de mise à jour sécurisés : Ne pas disposer d'un moyen fiable et sécurisé (comme une plateforme OTA robuste) pour livrer les mises à jour « sans délai ». Les mises à jour manuelles ne seront probablement pas suffisantes.
7. Documentation insuffisante : défaut de conservation de la documentation technique requise, SBOM et des preuves d'évaluation de la conformité nécessaires à la surveillance du marché.
8. Se concentrer uniquement sur le développement : Négliger les exigences post-commercialisation continues pour la gestion des vulnérabilités et les mises à jour tout au long du cycle de vie du produit.

Ce que les évaluateurs/autorités pourraient demander (Focus Développeur)

Les organismes d'évaluation de la conformité (pour les produits critiques) ou les autorités de surveillance du marché pourraient poser des questions liées aux exigences du CRA ayant un impact sur le développement :

• (Annexe I) Conception sécurisée : "Comment la sécurité a-t-elle été prise en compte lors de la phase de conception ? Pouvez-vous présenter des modèles de menaces ou des documents d'architecture de sécurité ?"
• (Annexe I) gestion des vulnérabilités: « Quels outils et processus sont utilisés pour identifier les vulnérabilités dans le code propriétaire et les composants tiers (SAST, SCA) pendant le développement ? »
• (Annexe I) Codage sécurisé : "Quelles normes de codage sécurisé sont suivies ? Comment la conformité est-elle appliquée (par exemple, linters, revues de code, formations) ?"
• (Annexe I) Tests de sécurité : "Présentez des preuves de tests de sécurité (par exemple, tests d'intrusion, fuzz testing) effectués avant la publication."
• (Annexe I) Mises à jour sécurisées : "Décrivez le mécanisme de diffusion des mises à jour de sécurité. Comment l'intégrité et l'authenticité des mises à jour sont-elles assurées ?"
• (Art. 10) SBOM: « Fournir la liste de matériaux logiciels SBOM) pour cette version du produit. »
• (Art. 10) Gestion des vulnérabilités : "Décrivez le processus de traitement d'une vulnérabilité signalée, de la réception à la publication du correctif."
• (Annexe I) Configuration sécurisée par défaut : "Comment le produit assure-t-il une configuration sécurisée prête à l'emploi ?"

Ils exigeront des preuves provenant des phases de conception, de développement, de test et de maintenance, incluant la documentation, les rapports d'outils, les descriptions de processus et potentiellement l'accès aux revues de code.

Gains rapides pour les équipes de développement

Bien que la pleine conformité au CRA prenne du temps, les équipes de développement peuvent commencer à jeter les bases :

1. Mettre en œuvre SBOM : intégrer des outils permettant de générer automatiquement une SBOM le cadre du processus de compilation.
2. Intégrer SCA SAST: s'assurer que analyse de la composition logicielle Tests de sécurité des applications statiques de manière fiable dans le pipeline CI/CD.
3. Adoptez une modélisation des menaces de base : Commencez à discuter des menaces potentielles lors des réunions de conception pour les nouvelles fonctionnalités ou produits.
4. Examiner les configurations par défaut : Évaluez et renforcez activement les paramètres par défaut des produits avant leur déploiement. Supprimez les identifiants par défaut.
5. Documenter le processus de mise à jour : Documentez clairement le processus actuel de création et de publication des mises à jour logicielles, même s'il est manuel au départ.
6. Mettre en place un processus de réception des vulnérabilités : Créez un moyen simple et documenté permettant aux équipes internes ou aux chercheurs externes de signaler les vulnérabilités potentielles (par exemple, une adresse e-mail dédiée ou un formulaire).

Ignorez ceci et... (Conséquences de la non-conformité)

Le non-respect du CRA peut entraîner de graves conséquences appliquées par les autorités nationales de surveillance du marché :

• Amendes importantes : Les amendes administratives peuvent atteindre €15 millions ou 2,5 % du chiffre d'affaires annuel mondial total du fabricant pour l'exercice financier précédent, le montant le plus élevé étant retenu, en cas de non-conformité aux exigences essentielles. Les infractions moins graves entraînent des amendes allant jusqu'à 10M€/2% ou 5M€/1%.
• Retrait/Rappel du marché : Les autorités peuvent exiger que les produits non conformes soient retirés du marché de l'UE ou rappelés auprès des utilisateurs finaux.
• Interdiction/Restriction de vente : La mise sur le marché de produits non conformes peut être interdite ou restreinte.
• Atteinte à la réputation : La divulgation publique de la non-conformité, des rappels ou des vulnérabilités importantes nuit à la confiance de la marque et à la perception du marché.
• Perte d'accès au marché : Le non-respect des exigences du CRA bloque effectivement l'accès à l'ensemble du marché unique de l'UE pour les produits concernés.

FAQ

Quels produits sont couverts par le CRA ?

"Produits avec éléments numériques" (PDEs) dont l'utilisation prévue ou raisonnablement prévisible inclut une connexion de données logique ou physique directe ou indirecte à un appareil ou un réseau. Cela inclut la plupart des logiciels (autonomes, mobiles, embarqués) et du matériel avec connectivité (appareils IoT, routeurs, appareils intelligents, composants industriels, etc.). Il existe des exclusions spécifiques (par exemple, les dispositifs médicaux, les voitures, l'aviation, certains SaaS).

Quand les exigences du CRA deviennent-elles obligatoires ?

La plupart des obligations, y compris les évaluations de conformité et les exigences essentielles, s'appliquent 36 mois après l'entrée en vigueur du CRA (vers décembre 2027). Cependant, l'obligation de signalement du fabricant pour les vulnérabilités et incidents activement exploités s'applique plus tôt, 21 mois après l'entrée en vigueur (vers septembre 2026).

Le CRA s'applique-t-il aux logiciels libres et open source (FOSS) ?

Les logiciels libres (FOSS) autonomes développés ou fournis en dehors d'une activité commerciale sont généralement exclus. Cependant, les FOSS intégrés dans un produit commercial sont couverts, et le fabricant du produit final est responsable. Les projets FOSS dotés de structures formelles (par exemple, des fondations) qui monétisent le support ou les versions pourraient également être soumis à certaines obligations du CRA (les détails sont encore débattus).

Qu'est-ce que le marquage CE dans le contexte du CRA ?

À l'instar d'autres réglementations européennes sur les produits, les fabricants doivent apposer le marquage CE sur les PDE conformes pour indiquer qu'ils répondent aux exigences essentielles du CRA avant de les mettre sur le marché de l'UE. Cela nécessite une évaluation de la conformité réussie.

Qu'est-ce qu'une SBOM pourquoi est-elle nécessaire ?

Une liste de matériaux logiciels SBOM) est un registre officiel contenant les détails et les relations au sein de la chaîne d'approvisionnement des différents composants utilisés dans la création de logiciels. La CRA exige des fabricants qu'ils génèrent et tiennent à jour une SBOM leurs produits afin d'améliorer la transparence et de faciliter gestion des vulnérabilités la chaîne d'approvisionnement.

Pendant combien de temps les fabricants doivent-ils fournir des mises à jour de sécurité en vertu du CRA ?

Les fabricants doivent fournir des mises à jour de sécurité pour la durée de vie prévue du produit ou pour une période minimale de cinq ans à compter de sa mise sur le marché, la période la plus courte étant retenue. La durée de vie prévue doit être prise en compte dès la conception. Les mises à jour doivent être gratuites et rapides (« sans délai »).

Comment le CRA se rapporte-t-il à NIS2 ou au RGPD ?

• NIS2: Se concentre sur la sécurité des réseaux et des systèmes utilisés par les fournisseurs de services essentiels/importants. La CRA se concentre sur la sécurité des produits eux-mêmes qui pourraient être utilisés par ces fournisseurs ou consommateurs.

RGPD : Se concentre sur la protection des données personnelles. Le CRA se concentre sur la cybersécurité des produits. Un produit sécurisé sous CRA aide à protéger les données personnelles qu'il traite (soutenant le RGPD), mais la portée du CRA est plus large que les seules données personnelles. Ils sont des éléments complémentaires de la stratégie de sécurité numérique de l'UE.