Cyber Resilience Act : ce que le règlement impose aux logiciels, et depuis quand

En bref :

• Depuis le 11 septembre 2026 : tout éditeur d’un produit comportant des éléments numériques doit notifier à l’ENISA les vulnérabilités activement exploitées et les incidents graves. Les délais sont une alerte sous 24 h, une notification sous 72 h, puis un rapport final sous 14 jours après la mise à disposition d’un correctif.
• À partir du 11 décembre 2027 : la mise sur le marché européen sera conditionnée aux exigences du règlement. Il s’agit de la sécurité par conception et par défaut, de l’absence de vulnérabilité exploitable connue, d’un inventaire des composants logiciels (SBOM, Software Bill of Materials), de correctifs de sécurité pendant au moins cinq ans après la première commercialisation et d’une politique de divulgation coordonnée des vulnérabilités, qui permet à des tiers de signaler une faille.

Partenaire tech et IA de plus de 800 entreprises, Galadrim conçoit et maintient de nombreux logiciels et applications. Sur ces projets, nos ingénieurs appliquent déjà les bonnes pratiques que le Cyber Resilience Act (CRA) rend désormais obligatoires : sécurité par conception, développement sécurisé, gestion des dépendances, suivi des vulnérabilités, déploiement rapide des correctifs et maintien en conditions de sécurité. Elles restent pourtant peu répandues, et beaucoup d’applications devront être mises en conformité. Cette responsabilité incombe à l’éditeur, c’est-à-dire l’entreprise qui commercialise le produit sous son nom, que le règlement appelle le fabricant.

Un simulateur, plus bas dans l’article, vous indique si votre produit est concerné.

Ce que le CRA exige d’un produit numérique

Le Cyber Resilience Act est un règlement européen, d’application directe comme le RGPD. Il a été adopté par le Parlement européen le 12 mars 2024. C’est le premier texte européen à imposer des exigences de cybersécurité à l’ensemble des « produits comportant des éléments numériques ».

Seul le signalement est en vigueur depuis le 11 septembre 2026 ; les exigences de sécurité s’appliqueront le 11 décembre 2027.

Depuis le 11 septembre 2026 : l’obligation de signalement

L’éditeur doit signaler deux types d’événements :

• une vulnérabilité activement exploitée, c’est-à-dire dont des éléments fiables montrent qu’un acteur malveillant l’a utilisée pour compromettre un système ;
• un incident grave, c’est-à-dire un événement qui menace la protection des données et des fonctions du produit, ou qui y introduit du code malveillant.

La notification doit être faite sur la plateforme unique de signalement de l’ENISA. À partir de l’identification de l’incident ou de la vulnérabilité, vous êtes tenus de respecter ces délais :

• 24 h : alerte précoce ;
• 72 h : notification détaillée, avec la nature de l’exploitation, les mesures correctives et les mesures recommandées aux utilisateurs ;
• rapport final : 14 jours après la mise à disposition d’un correctif pour une vulnérabilité, ou un mois après la notification pour un incident.

L’éditeur doit aussi informer les utilisateurs touchés de la vulnérabilité ou de l’incident, et des mesures à appliquer pour s’en protéger, dans un format structuré et lisible par machine.

Tenir le délai de 24 h suppose de savoir à tout moment quelles versions du produit sont déployées et quels composants chacune embarque, de superviser le backend pour détecter une exploitation, et d’avoir une procédure de signalement avec un responsable désigné.

Vous souhaitez vous préparer, ou votre produit est touché par une faille ? Nos équipes vous aident à vous organiser pour signaler et corriger dans les délais. Échanger avec nos experts

À partir du 11 décembre 2027 : les exigences de sécurité

L’éditeur ne pourra mettre sur le marché qu’un produit conforme aux exigences du règlement. Il devra :

• concevoir un produit sécurisé par défaut : configuration sécurisée dès l’installation, surface d’attaque réduite, accès et données protégés par l’authentification, le chiffrement et la journalisation ;
• livrer un produit sans vulnérabilité exploitable connue, ce qui se vérifie sur l’ensemble des dépendances embarquées, pas seulement sur le code développé en interne ;
• tenir une SBOM, l’inventaire lisible par machine des composants du produit ;
• corriger toute vulnérabilité dès sa découverte, par des mises à jour de sécurité gratuites et distinctes des évolutions fonctionnelles ;
• diffuser ces mises à jour de façon sécurisée, par exemple signées pour que l’appareil vérifie qu’elles proviennent bien de l’éditeur ;
• assurer ce suivi pendant au moins cinq ans après la première commercialisation ;
• publier une politique de divulgation coordonnée des vulnérabilités : un point de contact et une procédure pour que des tiers puissent lui signaler une faille.

Ces bonnes pratiques sont celles que nous appliquons sur les logiciels que nous développons et maintenons.

Pourquoi la conformité est d’abord un chantier technique

Les dépendances. Une application embarque des centaines de composants open source, du langage aux bibliothèques. Chacun peut introduire une vulnérabilité, par erreur ou volontairement lors d’une attaque de la chaîne d’approvisionnement (supply chain attack). Une fois connue, la vulnérabilité peut être exploitée automatiquement sur toutes les versions non mises à jour : les vulnérabilités PHP2Shell, publiées le 21 octobre 2026, ont été exploitées dès leur divulgation. Sur un projet ancien, corriger impose souvent de monter de version un framework qui n’est plus maintenu.

La veille continue. Pendant toute la période de support, il faut surveiller les vulnérabilités publiées (CVE, avis du CERT-FR) sur chaque composant.

Avec l’essor de l’IA dans le développement, le volume de code produit augmente, et les outils d’analyse assistés par l’IA détectent les vulnérabilités de plus en plus vite. Le goulot d’étranglement devient la correction : trier, corriger, tester et déployer sur toutes les versions en circulation avant l’exploitation.

Nous pouvons mettre en place ces pratiques sur votre produit ou accompagner vos équipes. Échanger avec nos experts

Votre produit est-il concerné ?

Le CRA s’applique aux produits comportant des éléments numériques vendus ou distribués dans l’Union européenne dans le cadre d’une activité commerciale. Un produit est concerné si l’utilisateur installe un logiciel sur son appareil. C’est le cas d’une application mobile, d’une application de bureau, d’une extension de navigateur, d’un logiciel déployé sur les serveurs du client ou du logiciel embarqué d’un objet connecté. Les serveurs indispensables au fonctionnement de ce logiciel sont aussi concernés, par exemple le backend d’une application mobile ou son module de paiement. Sont exclus :

• les applications web utilisées uniquement dans le navigateur, sans rien à installer, sauf si elles sont indispensables au fonctionnement d’un logiciel concerné ;
• les logiciels développés et utilisés exclusivement en interne ;
• les produits relevant d’une réglementation sectorielle : dispositifs médicaux, véhicules, aéronautique certifiée, équipements marins et défense.

L’entreprise qui commercialise le produit est responsable de sa conformité, mais le prestataire chargé de son développement a aussi des obligations : fournir la SBOM, corriger les vulnérabilités dans les délais et assurer le support sur la durée prévue.

Pour un produit déjà commercialisé, le signalement s’applique dès aujourd’hui. Les exigences de 2027 ne s’appliqueront qu’en cas de modification substantielle après le 11 décembre 2027, c’est-à-dire une évolution qui change l’usage prévu du produit ou affecte sa conformité. Les correctifs de sécurité n’en font pas partie.

Les manquements exposent à une amende pouvant atteindre 15 M€ ou 2,5 % du chiffre d’affaires mondial, et au retrait du produit du marché.

Simulateur : votre produit est-il concerné ?

Répondez à quatre questions pour savoir si le CRA s’applique à votre produit.

Au-delà de ce diagnostic, nous accompagnons les entreprises dans toute leur mise en conformité, de l’audit à la correction des vulnérabilités. Échanger avec nos experts

Lexique

• Faille : vulnérabilité d’un système informatique qui permet à un attaquant de porter atteinte à son fonctionnement normal, ou à la confidentialité ou à l’intégrité des données qu’il contient (ANSSI).
• Vulnérabilité : faiblesse ou défaut d’un produit qui peut être exploité par une menace.
• Vulnérabilité activement exploitée : vulnérabilité dont des éléments fiables montrent qu’un acteur malveillant l’a utilisée sans l’autorisation du propriétaire du système.
• Incident grave : événement qui compromet, ou peut compromettre, la disponibilité, l’intégrité ou la confidentialité des données ou des fonctions d’un produit, ou qui y introduit du code malveillant.
• SBOM (Software Bill of Materials) : inventaire formel des composants d’un logiciel, de leurs versions et de leurs dépendances.
• CVE (Common Vulnerabilities and Exposures) : identifiant public standardisé attribué à une vulnérabilité connue.
• ENISA : Agence de l’Union européenne pour la cybersécurité, qui opère la plateforme de signalement du CRA.
• CSIRT : centre de réponse aux incidents de sécurité informatique. En France, le CERT-FR, opéré par l’ANSSI, est le CSIRT national (ANSSI).
• CI/CD (intégration et déploiement continus) : chaîne automatisée qui teste puis met en production chaque modification du code.

À propos de l’auteur

Harold Stern est Expert Cybersécurité et Conformité chez Galadrim. Il développe cette offre, aux côtés de l’équipe de sécurité applicative.