La Commission européenne vient de publier des lignes directrices pratiques pour accompagner la mise en œuvre du Cyber Resilience Act. Ces clarifications révèlent surtout l’ampleur réelle des obligations. La conformité ne s’arrête pas au code produit en interne, elle s’étend à chaque composant, chaque dépendance, chaque fournisseur intégré dans la chaîne.
Expert : Darren Guccione, CEO et co-fondateur de Keeper Security
Les dernières lignes directrices de la Commission européenne relatives à la loi sur la cyber-résilience (CRA) offrent aux fabricants et aux éditeurs de logiciels une feuille de route plus claire pour s’y retrouver dans l’un des textes législatifs de l’UE les plus importants à ce jour en matière de cybersécurité. Ces lignes directrices clarifient de nombreux détails faisant depuis longtemps l’objet de débats, notamment le traitement réservé aux logiciels open source, les cas dans lesquels une mise à jour logicielle est considérée comme une modification substantielle, ainsi que la manière dont les périodes de support doivent être définies.
Tout cela est utile, mais ces lignes directrices mettent également en évidence un aspect que les organisations concernées par la CRA ont pu jusqu’à présent éviter d’aborder de front : l’obligation de diligence raisonnable vis-à-vis de chaque composant tiers et open source, de la dépendance au traitement des données à distance et des services cloud intégrés à un produit connecté. C’est là que réside le véritable défi en matière de conformité.
En vertu de la loi, la responsabilité d’un fabricant ne se limite pas au code qu’il a écrit. Elle s’étend aux composants qu’il intègre, aux fournisseurs d’infrastructure sur lesquels il s’appuie, ainsi qu’aux identités des machines et aux identifiants qui permettent le transfert de données entre tous ces éléments. Une étude réalisée par Keeper en 2026 montre que 15 % des organisations françaises citent déjà le contrôle limité de l’accès des tiers et des fournisseurs comme une lacune en matière de gouvernance. Ces lignes directrices ne comblent pas cette lacune. Elles fixent une échéance légale pour y remédier, avec des obligations de signalement des vulnérabilités activement exploitées s’appliquant à compter du 11 septembre 2026, bien avant la date principale de mise en conformité fixée à décembre 2027.
Les entreprises qui se préparent à ce calendrier doivent considérer la visibilité sur les identités non humaines et les secrets – à savoir les clés API, les jetons et les comptes de service reliant un produit à ses dépendances – comme une infrastructure de conformité essentielle plutôt que comme une simple nuance technique. C’est en centralisant la gouvernance des secrets à travers les pipelines de développement et d’intégration qu’un fabricant peut réellement démontrer la diligence raisonnable désormais attendue par les lignes directrices. Attendre 2027 pour mettre en place cette visibilité expose considérablement l’échéance de déclaration fixée à septembre.
