Cyber Resilience Act, transparence renforcée… mais des angles morts à surveiller »

Le Cyber Resilience Act : obligations et calendrier

Le Cyber Resilience Act (CRA) est le règlement européen (UE 2024/2847) qui impose des exigences de cybersécurité à tous les produits comportant des éléments numériques : logiciels, applications, firmware, objets connectés, équipements réseau, etc.

Il introduit deux échéances majeures :

• 11 septembre 2026 : Obligation de notification des vulnérabilités activement exploitées. Les fabricants doivent : notifier l’ENISA (European Union Agency for Cybersecurity) et le CSIRT national (Computer Security Incident Response Team) dans les 24 heures ; fournir une analyse détaillée dans les 72 heures ; transmettre un rapport final dans le mois ; avertir les utilisateurs « sans retard injustifié ».

• 11 décembre 2027 : Obligation de conformité complète avec le marquage CE-Cyber, sans lequel un produit ne peut plus être commercialisé ni mis à jour dans l’UE.

En France, le CSIRT national correspond au CERT-FR (ANSSI). Les CSIRT territoriaux sont les équipes régionales de réponse aux incidents. Les CRC (Centres Régionaux de Cybersécurité) accompagnent les TPE/PME et collectivités.

Les obligations couvrent :

• sécurité dès la conception ;
• gestion structurée des vulnérabilités ;
• SBOM (Software Bill of Materials) maintenu 5 ans ;
• signature des artefacts logiciels ;
• documentation technique complète ;
• support de sécurité pendant toute la durée de vie du produit.

Impact pour les éditeurs et fabricants

Certains éditeurs et fabricants jouent déjà le jeu depuis longtemps — notamment l’open‑source, le SaaS moderne ou ceux disposant d’un programme de gestion des vulnérabilités mature. Pour les autres, le CRA marque un changement profond :

• Fin du silence sur les vulnérabilités : impossible de corriger discrètement une faille.
• Obligation d’un processus de gestion des vulnérabilités opérationnel et documenté – Interne à l’entreprise.
• Mise en place d’un VDP (Vulnerability Disclosure Program) – Externe à l’entreprise.
• Gestion rigoureuse des dépendances logicielles via SBOM.
• Renforcement des pipelines CI/CD pour garantir l’intégrité des mises à jour.
• Classification des produits selon leur criticité, avec des niveaux d’évaluation différents.

Remarques importantes :

• Le CRA impose un canal unique de notification : la Single Reporting Platform (SRP), opérée par l’ENISA. Le format technique des pièces jointes reste flexible (PDF, JSON, STIX…), mais la SRP impose une structure de champs, un workflow commun et une diffusion automatique vers les CSIRT concernés. Cela apporte une homogénéisation du canal… mais pas du contenu, qui reste très variable selon les éditeurs.
• Vulnérabilités non activement exploitées : aucune obligation de notification.
• Zero‑day non exploité : aucune obligation de notification.
• Absence d’obligation de correction : le fabricant doit notifier, mais n’est pas légalement tenu de corriger.
• Durée de vie du produit : définie par le fabricant → risque d’obsolescence programmée.
• Durée d’usage réelle souvent plus longue → tension fabricant / utilisateur.
• Absence de standard de notification → hétérogénéité des pratiques.

Les éditeurs doivent simplement garantir que l’information est :

• transmise dans les délais,
• compréhensible,
• actionnable,
• adressée aux bonnes parties prenantes.

Impact pour les clients : une chaîne d’alerte enfin accélérée

Pour les clients (…et les éditeurs et fabricants qui ne jouaient pas le jeu avant le CRA), le CRA apporte un changement majeur : les vulnérabilités ne pourront plus être corrigées en silence.

Les notifications obligatoires pourraient alimenter une chaîne technique déjà utilisée dans les grandes organisations :

• publication d’un CVE (Common Vulnerabilities and Exposures) ;
• enrichissement via NVD (USA) et EUVD (UE) ;
• diffusion automatisée en STIX/TAXII ;
• ingestion par les moteurs de sécurité : IPS, EDR, firewalls ;
• déploiement des correctifs via les outils de patch management.

Depuis la mise en ligne de la Single Reporting Platform (SRP), les notifications CRA transitent désormais par un portail unique. Cela simplifie la transmission côté fabricants, mais ne change rien à la charge d’analyse pour les clients.

Un progrès… mais quelle capacité absorber pour les petites structures ?

Le CRA améliore la transparence, mais ne résout pas la capacité des petites structures à absorber ces alertes.

Les TPE/PME n’ont généralement :

• aucun outil de supervision des CVE ;
• aucun flux STIX/TAXII ;
• aucun scanner de vulnérabilités ;
• aucun pipeline de patch automatisé ;
• aucune équipe sécurité.

Et l’absence de standard de notification renforce ce problème : si chaque éditeur notifie différemment, comment une petite structure peut-elle suivre, prioriser et appliquer les correctifs ?

Préconisation d’Harmonie Digitale : se tourner vers les solutions LTS ou l’open‑source quand c’est possible

Le CRA n’impose pas la correction des vulnérabilités. Un fabricant peut notifier… sans corriger.

Dans ce contexte, Harmonie Digitale préconise de privilégier les éditeurs ou les fabricants qui proposent des garanties de corrections sur le long terme (LTS – Long Term Support) ou les solutions open‑source. Rappelons que les solutions open-source sans pour autant être toujours gratuites, offrent des avantages majeurs :

• publication du code ;
• durée de vie définie par l’usage, pas par le marketing – Absence d’obsolescence programmée
• correctifs souvent rapides grâce à la communauté ;
• correctifs toujours possibles par un développeur interne, externe, ou via des outils d’IA
• indépendance vis‑à‑vis d’un tiers qui pourrait ne pas corriger.

Conclusion

Le Cyber Resilience Act est un progrès important, surtout pour les entreprises qui ne jouaient pas le jeu de la transparence. Il renforce la notification, structure la gestion des vulnérabilités, et impose une discipline minimale aux fabricants.

Mais il laisse plusieurs angles morts :

• pas d’obligation de correction,
• vulnérabilités non exploitées non couvertes,
• durée de vie définie par le fabricant,
• petites structures non outillées.

La prochaine étape devra être d’accompagner les TPE/PME, faute de quoi la transparence ne suffira pas.