Cyber Resilience Act : ce que le règlement européen change pour les équipes tech

Un routeur domestique jamais mis à jour, une application connectée livrée avec un mot de passe par défaut, une bibliothèque open source vulnérable embarquée dans des milliers de produits : les failles des produits numériques coûtent cher, et leurs fabricants n'avaient jusqu'ici aucune obligation européenne uniforme d'y remédier. Le Cyber Resilience Act (CRA) change la donne.

Ce règlement européen (UE) 2024/2847, entré en vigueur en décembre 2024, impose des exigences de cybersécurité à tous les produits comportant des éléments numériques vendus dans l'Union, du logiciel embarqué dans un objet connecté à l'application mobile en passant par les systèmes d'exploitation. Son calendrier est progressif : les obligations de signalement des vulnérabilités s'appliquent depuis le 11 septembre 2026, et l'application complète est prévue pour décembre 2027. Les équipes de développement, de DevOps et de sécurité sont donc déjà concernées.

Dans cet article, nous allons préciser quels produits entrent dans le périmètre, ce que recouvre la sécurité dès la conception, comment les SBOM et la gestion des vulnérabilités s'inscrivent dans le quotidien des équipes, quels sont les délais de notification à l'ENISA et quelle place le texte réserve à l'open source. Nous terminerons par une checklist de mise en conformité.

Quels produits et quels acteurs sont concernés ?

Le CRA s'applique aux produits comportant des éléments numériques mis à disposition sur le marché européen, c'est-à-dire tout logiciel ou matériel dont l'usage prévu implique une connexion directe ou indirecte à un appareil ou à un réseau. Cela couvre les objets connectés, les équipements réseau, les logiciels installés, les applications mobiles, les systèmes d'exploitation, les composants matériels et logiciels vendus séparément.

Quelques catégories sont exclues, car elles relèvent déjà de réglementations sectorielles : dispositifs médicaux, véhicules, aviation, équipements maritimes. Les services web purs (SaaS) ne sont en principe pas couverts en tant que tels, sauf lorsqu'ils constituent la solution de traitement de données à distance indispensable au fonctionnement d'un produit. Une application mobile adossée à un back-end propriétaire entre donc dans le périmètre avec son back-end.

Le règlement distingue plusieurs rôles, chacun avec ses obligations :

• Fabricant : acteur qui conçoit ou fait concevoir le produit et le commercialise sous son nom, il porte l'essentiel des obligations
• Importateur : acteur qui place sur le marché européen un produit d'un fabricant hors Union, il vérifie la conformité et la documentation
• Distributeur : acteur qui met à disposition un produit déjà sur le marché, il contrôle notamment le marquage CE et les instructions
• Mainteneur open source commercial : acteur qui développe un logiciel libre dans un cadre d'activité commerciale, il est traité comme un fabricant

Les produits sont par ailleurs classés selon leur niveau de risque, ce qui détermine la procédure d'évaluation de conformité.

Environ 90 % des produits relèvent de la catégorie par défaut, avec une auto-évaluation. Cela ne dispense pas de produire la documentation technique, de la conserver dix ans et d'apposer le marquage CE, qui devient la preuve visible de conformité.

La sécurité dès la conception

Le cœur du CRA est l'annexe I, qui fixe les exigences essentielles en deux parties : la cybersécurité du produit et la gestion des vulnérabilités. L'idée directrice est la sécurité dès la conception (security by design) et par défaut (security by default) : le produit doit être sûr à la livraison, pas après un correctif.

Les exigences sur le produit

Un produit doit être conçu, développé et fabriqué pour offrir un niveau de cybersécurité adapté aux risques. Concrètement, le texte demande notamment :

• Pas de vulnérabilité exploitable connue au moment de la mise sur le marché
• Configuration sécurisée par défaut, avec possibilité de revenir à l'état d'origine, et sans mot de passe universel par défaut
• Mises à jour de sécurité disponibles, idéalement automatiques, avec possibilité de les désactiver
• Protection contre les accès non autorisés par des mécanismes d'authentification, d'identification et de gestion des accès
• Confidentialité et intégrité des données par le chiffrement au repos et en transit, et la minimisation des données collectées
• Surface d'attaque limitée et résilience face aux attaques par déni de service
• Journalisation des événements de sécurité pertinents, avec option de désactivation

Ces exigences recoupent des pratiques déjà connues : durcissement des configurations, principe du moindre privilège, gestion fine des identités avec des mécanismes comme l'IAM, détection runtime avec des outils tels que Falco. Le CRA les rend simplement opposables.

Une analyse de risques documentée

Le fabricant doit réaliser une évaluation des risques de cybersécurité et l'intégrer à la documentation technique. Elle justifie les choix de conception, et elle est mise à jour tout au long du cycle de vie du produit. Pour une organisation qui applique déjà une démarche de management de la sécurité comme ISO 27001, une partie du travail existe : la méthodologie d'analyse de risques se transpose, même si le CRA vise le produit et non l'organisation.

À lire : découvrez notre formation DevOps Engineer

SBOM et gestion des vulnérabilités

La seconde partie de l'annexe I porte sur la gestion des vulnérabilités sur toute la durée de vie du produit. C'est l'angle qui touche le plus directement les équipes DevOps et les développeurs.

Le SBOM comme obligation

Le fabricant doit identifier et documenter les composants du produit, y compris les dépendances tierces, en établissant une nomenclature logicielle (SBOM, Software Bill of Materials) dans un format lisible par machine et couvrant au minimum les dépendances de premier niveau. Les formats courants sont SPDX et CycloneDX. Le SBOM n'a pas à être publié, mais il doit être fourni aux autorités de surveillance du marché qui le demandent.

Le plus simple est de le générer dans la chaîne d'intégration continue, à chaque build, avec un outil comme Syft ou Trivy :

# Génération d'un SBOM CycloneDX pour l'image du produit
syft registry.example.com/mon-produit:1.4.2 -o cyclonedx-json > sbom.cdx.json

# Analyse des vulnérabilités connues à partir de ce SBOM
grype sbom:sbom.cdx.json --fail-on high

La première commande produit l'inventaire des composants, la seconde le confronte aux bases de vulnérabilités et fait échouer le pipeline si une faille de gravité élevée est détectée. Intégrées à un pipeline GitLab CI/CD ou équivalent, ces étapes produisent des preuves datées et reproductibles, utiles lors d'un contrôle.

Traiter, publier, corriger

Au-delà de l'inventaire, le fabricant doit :

• Traiter les vulnérabilités sans délai, et fournir des correctifs de sécurité séparés des mises à jour fonctionnelles quand c'est techniquement possible
• Tester et auditer régulièrement la sécurité du produit
• Divulguer publiquement les vulnérabilités corrigées, une fois le correctif disponible, avec leur description, leur gravité et les instructions de remédiation
• Mettre en place une politique de divulgation coordonnée et un point de contact pour recevoir les signalements
• Assurer le support de sécurité pendant la durée d'usage attendue du produit, avec un minimum de cinq ans sauf durée de vie plus courte

Ce dernier point pèse sur l'organisation : maintenir cinq ans de correctifs implique de gérer des branches maintenues, des dépendances qui vieillissent et une chaîne de build reproductible. Une approche GitOps, où l'état déployé est versionné et traçable, y aide beaucoup.

Les délais de notification à l'ENISA

C'est la partie du CRA déjà applicable. Depuis le 11 septembre 2026, tout fabricant doit notifier deux types d'événements : les vulnérabilités activement exploitées présentes dans son produit, et les incidents graves ayant un impact sur la sécurité du produit. Les notifications passent par une plateforme unique de signalement opérée par l'ENISA, qui les transmet au CSIRT national désigné comme coordinateur et à l'agence européenne.

Les délais suivent trois étapes :

L'horloge démarre à la prise de connaissance, pas à la découverte par un tiers. Une équipe qui n'a ni astreinte, ni procédure de qualification, ni point d'entrée identifié pour les signalements risque de manquer l'alerte des 24 heures. Il faut donc décider à l'avance qui qualifie une vulnérabilité d'« activement exploitée », qui rédige la notification et qui possède les accès à la plateforme.

Les sanctions sont dissuasives : jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial pour le non-respect des exigences essentielles et des obligations de signalement, jusqu'à 10 millions ou 2 % pour les autres manquements, et jusqu'à 5 millions ou 1 % pour des informations inexactes fournies aux autorités. Les équipes de supervision, comme un analyste SOC, deviennent des maillons directs du processus de notification.

À découvrir : notre formation DevOps Engineer

La place de l'open source

Le texte final a pris en compte les craintes de la communauté. Un logiciel libre développé et fourni hors d'une activité commerciale (projet communautaire, contributeurs individuels, fondations à but non lucratif) n'est pas soumis au règlement. En revanche, dès qu'un logiciel libre est monétisé (support payant réservé, version commerciale, financement lié à l'usage), son éditeur devient un fabricant.

Le CRA crée aussi un statut intermédiaire, celui de steward de logiciel open source : une fondation ou une entreprise qui soutient durablement le développement d'un projet destiné à un usage commercial. Le steward a un régime allégé : politique de cybersécurité, coopération avec les autorités, gestion et signalement des vulnérabilités, mais sans marquage CE ni sanctions financières équivalentes à celles des fabricants.

Pour une équipe qui intègre des composants open source dans un produit commercial, la responsabilité reste entière : le fabricant doit faire preuve de diligence raisonnable sur chaque composant tiers, vérifier son niveau de maintenance, suivre ses vulnérabilités et remonter aux mainteneurs les failles qu'il découvre. Consommer sans contribuer ni surveiller n'est plus une option défendable.

Checklist pour se mettre en conformité

Voici une feuille de route concrète, à adapter à la taille et à la maturité de l'organisation :

• Cartographier le portefeuille : lister les produits et composants mis sur le marché européen, identifier son rôle (fabricant, importateur, distributeur) et la catégorie de chaque produit
• Définir la procédure de signalement : désigner les responsables, documenter la qualification d'une vulnérabilité exploitée, préparer les modèles de notification 24 h, 72 h et rapport final, et ouvrir les accès à la plateforme de l'ENISA
• Générer un SBOM à chaque release : l'intégrer au pipeline CI/CD, en SPDX ou CycloneDX, et l'archiver avec la version correspondante
• Surveiller les vulnérabilités en continu : brancher l'analyse du SBOM sur les bases de vulnérabilités et sur un flux d'alertes, avec des délais de traitement par niveau de gravité
• Publier une politique de divulgation coordonnée : fournir un contact de sécurité, par exemple un fichier security.txt, et un processus de réception des signalements externes
• Intégrer la sécurité dès la conception : mener une analyse de risques par produit, définir des configurations sécurisées par défaut, supprimer les mots de passe par défaut, chiffrer les données
• Fixer et communiquer la période de support : au moins cinq ans, ou la durée d'usage attendue si elle est plus courte, avec un plan de maintenance des branches
• Constituer la documentation technique : analyse de risques, description du produit, preuves de tests, déclaration UE de conformité, conservation pendant dix ans
• Auditer la chaîne de dépendances : évaluer la maintenance des composants open source critiques et prévoir des alternatives en cas d'abandon
• Former les équipes : sensibiliser les développeurs et les équipes d'exploitation aux exigences, et organiser des exercices de simulation de notification

Cette liste n'a pas besoin d'être traitée dans l'ordre. Les points de signalement et de SBOM sont les plus urgents, car ils sont exigibles ou vérifiables dès maintenant, alors que l'évaluation de conformité complète et le marquage CE ne s'imposeront qu'en décembre 2027.

Conclusion

Le Cyber Resilience Act déplace la responsabilité de la sécurité vers les fabricants, sur toute la durée de vie du produit. Marquage CE, sécurité dès la conception, SBOM, support de cinq ans et signalement des vulnérabilités exploitées sous 24 heures : le texte transforme en obligations légales des pratiques que les équipes les plus matures appliquent déjà.

Les obligations de signalement sont déjà applicables, et l'application complète de décembre 2027 laisse peu de temps pour industrialiser les processus. Les organisations qui s'y prennent tôt, en automatisant le SBOM dans leurs pipelines et en structurant leur réponse aux incidents, y gagneront une conformité durable plutôt qu'un chantier de dernière minute.

Au-delà de la contrainte, le CRA fait de la maîtrise de la chaîne logicielle une compétence différenciante. Les profils capables de relier développement, DevOps et sécurité, et de produire des preuves de conformité à partir de pipelines automatisés, seront particulièrement recherchés dans les années à venir.