Cyber Resilience Act : où se situent réellement les lacunes

Le Cyber Resilience Act entrera en pleine application le 11 décembre 2027, mais le travail préparatoire décisif se fait bien avant cette date. Une enquête récente relayée par heise online montre que de nombreuses entreprises ne connaissent encore pas suffisamment les exigences relatives aux obligations de notification et aux nomenclatures logicielles. Pour les fonctions gouvernance, risques et conformité, la question n’est plus de savoir si le CRA est pertinent, mais quelles preuves doivent effectivement être en place avant les prochaines échéances, et qui est responsable de les fournir.

Où en est réellement l’industrie dans la mise en œuvre du CRA ?

Selon une enquête du fournisseur de cybersécurité ONEKEY citée par heise online, 45 % des entreprises interrogées connaissent peu ou pas du tout les exigences du CRA.

Un second constat pèse davantage plus loin dans la chaîne d’approvisionnement : selon la même enquête, seuls 18 % des fournisseurs transmettent les informations CRA nécessaires, alors même que les fabricants restent responsables également des composants fournis. Le risque réel se situe donc moins dans le propre service de développement d’une entreprise que dans la chaîne des fournisseurs en amont.

Néanmoins, un tiers des entreprises déclarent vouloir satisfaire à toutes les exigences avant l’échéance de décembre 2027, selon heise online. Dans de nombreux cas, un écart subsiste entre cette ambition et une préparation réellement documentée. Une incertitude similaire sur le périmètre d’application réel se retrouve aussi dans d’autres réglementations européennes, comme l’illustre l’article La lacune d’enregistrement NIS2 : ce qu’elle révèle sur l’incertitude du périmètre.

Quelles échéances se situent entre aujourd’hui et l’application intégrale ?

Le Cyber Resilience Act est entré en vigueur le 10 décembre 2024, l’obligation de notification des vulnérabilités et des incidents s’applique à partir du 11 septembre 2026, et le règlement s’applique intégralement à partir du 11 décembre 2027.

Le véritable temps de préparation se situe entre ces deux dates. Les entreprises qui veulent respecter l’obligation de notification dès septembre 2026 doivent disposer, à cette date, d’une chaîne de détection et d’escalade opérationnelle, et non d’un simple projet. La conformité intégrale, incluant l’obligation de SBOM, suit un peu plus d’un an plus tard, mais les processus nécessaires ne peuvent pas être mis en place dans les dernières semaines avant l’échéance.

L’Office fédéral allemand de la sécurité de l’information (BSI) accompagne cette période transitoire au moyen d’une directive technique qui précise les exigences relatives au SBOM et à la notification, mais cette directive ne remplace pas l’évaluation des risques propre à chaque entreprise.

Que requiert concrètement l’obligation de notification prévue à l’article 14 du CRA ?

Les fabricants doivent notifier les vulnérabilités activement exploitées et les incidents de sécurité graves à l’autorité coordinatrice compétente ainsi qu’à l’ENISA, avec une alerte précoce dans un délai de 24 heures et une notification de suivi dans un délai de 72 heures.

Les deux notifications passent par la plateforme de notification unique prévue par le CRA, qui les transmet simultanément au CSIRT coordinateur et à l’ENISA. Le délai commence à courir dès que le fabricant a connaissance du problème, et non lorsqu’un service spécialisé ou un lanceur d’alerte externe le confirme.

Pour une fonction GRC, cela signifie que les voies d’escalade dans le délai de 24 heures doivent être documentées par écrit et testées avant l’échéance de septembre 2026. À quel point une telle chaîne de notification dépend de processus rodés plutôt que de la seule technologie est décrit dans l’article SMSI : les personnes, les processus et la technologie sont déterminants.

Quelles preuves relatives à la nomenclature logicielle manquent le plus souvent encore ?

Le SBOM fait partie de la documentation technique et doit couvrir au moins les dépendances logicielles directes, mais de nombreuses entreprises manquent précisément de ces informations pour les composants fournis.

Le CRA n’impose pas de format technique unique ; en pratique, CycloneDX et SPDX se sont imposés. Ce qui compte est moins le format que l’actualité : un SBOM établi une seule fois perd de sa pertinence à chaque mise à jour logicielle et devrait être étroitement couplé aux processus de build et de mise en production.

Le constat relatif aux fournisseurs s’applique directement ici : sans informations fiables provenant de la chaîne d’approvisionnement, le SBOM propre à une entreprise reste incomplet, quelle que soit la qualité de l’organisation de la documentation interne. La manière de saisir systématiquement ces dépendances envers des tiers est décrite dans l’article Ce que le Third-Party Cyber Risk Management peut apprendre des fonctions de sécurité établies.

Quelle première étape peut être planifiée concrètement dès maintenant ?

La prochaine étape vérifiable consiste en un inventaire complet des produits qui indique, pour chaque produit, si un SBOM lisible par machine existe et quels fournisseurs doivent encore fournir les informations manquantes.

Les responsables sécurité ou conformité devraient disposer, avant l’échéance du 11 septembre 2026, d’un processus d’escalade documenté pour les vulnérabilités activement exploitées, incluant l’accès à la plateforme de notification et un responsable nommé pour le respect du délai de 24 heures. En parallèle, il est utile de dresser un état des lieux des produits et fournisseurs disposant actuellement de données SBOM lisibles par machine.

Comme les notifications CRA se rapportent aux produits, tandis que d’autres régimes tels que NIS2 rapportent au niveau organisationnel, il est également utile d’examiner les interfaces entre ces deux obligations, comme l’expose l’article Repenser la cyber-résilience dans le contexte de NIS2. Les entreprises qui entament dès maintenant cet état des lieux ont encore le temps, avant l’échéance de septembre 2026, de réaliser un test de la chaîne de notification.