Cyber Resilience Act : ce qui devient obligatoire le 11 septembre 2026, même pour vos produits déjà vendus

Lorsqu'on parle du Cyber Resilience Act (CRA), une date revient presque systématiquement : le 11 décembre 2027. C'est à cette date que la majorité des exigences du règlement européen deviendront applicables.

Pourtant, pour les éditeurs de logiciels et les fabricants de produits connectés, une première échéance arrive beaucoup plus tôt. Dès le 11 septembre 2026, les fabricants devront signaler certaines vulnérabilités activement exploitées et certains incidents de sécurité graves.

Et cette obligation ne concerne pas uniquement les nouveaux produits commercialisés après cette date. Elle peut également concerner des logiciels et des équipements déjà présents sur le marché depuis plusieurs années.

event_available Ce qui change le 11 septembre 2026

À partir de cette date, un fabricant qui prend connaissance :

• d'une vulnérabilité activement exploitée dans l'un de ses produits, ou
• d'un incident grave affectant la sécurité de ce produit,

devra enclencher un processus de notification réglementaire.

Le premier délai est particulièrement court : 24 heures à compter du moment où le fabricant prend connaissance de la situation. Une notification plus complète doit ensuite être transmise dans les 72 heures.

Ces notifications passent par la Single Reporting Platform (SRP), mise en place et opérée par l'ENISA. La Commission européenne indique que cette plateforme sera opérationnelle à l'entrée en application des obligations, le 11 septembre 2026.

Autrement dit, le CRA n'est plus seulement un chantier de conformité à préparer pour 2027. Une partie du règlement devient opérationnelle dès septembre 2026.

group Qui est concerné ?

Le CRA vise les entreprises qui fabriquent et commercialisent dans l'Union européenne des produits comportant des éléments numériques (article 3 du règlement).

Cette notion couvre des produits matériels et logiciels : applications, logiciels installés localement, systèmes d'exploitation, équipements connectés, composants logiciels ou matériels commercialisés séparément, ainsi que les solutions de traitement de données à distance indispensables au fonctionnement du produit.

Le champ d'application (article 2) repose sur la mise à disposition sur le marché européen d'un produit dont l'utilisation prévue ou raisonnablement prévisible implique une connexion directe ou indirecte, physique ou logique, à un appareil ou à un réseau.

Toutes les entreprises informatiques ne sont donc pas automatiquement concernées. Un service SaaS pur, par exemple, ne devient pas nécessairement un produit relevant du CRA du seul fait qu'il est accessible via Internet : l'accessibilité en ligne ne suffit pas, c'est la combinaison entre un produit et un traitement de données à distance indispensable à son fonctionnement qui compte.

En revanche, un éditeur qui commercialise un logiciel constituant un produit comportant des éléments numériques entre clairement dans le champ d'application.

La confusion entre 2026 et 2027

C'est probablement le point le plus important à comprendre, et celui que la plupart des entreprises manquent.

Pour la majorité des obligations du CRA, les produits mis sur le marché avant le 11 décembre 2027 bénéficient d'un régime transitoire : ils ne sont soumis aux nouvelles exigences que s'ils font ensuite l'objet d'une modification substantielle (article 69, paragraphe 2).

Mais le règlement prévoit une exception explicite pour les obligations de signalement de l'article 14. L'article 69, paragraphe 3, précise que ces obligations s'appliquent également aux produits relevant du CRA qui ont été mis sur le marché avant le 11 décembre 2027.

restore 24 heures, 72 heures, 14 jours : quels sont exactement les délais ?

Le CRA distingue deux situations.

Vulnérabilité activement exploitée

Toutes les vulnérabilités ne doivent pas être signalées. Le règlement définit une vulnérabilité activement exploitée (article 3, point 42) comme une vulnérabilité pour laquelle il existe des éléments fiables indiquant qu'un acteur malveillant l'a effectivement exploitée dans un système sans l'autorisation de son propriétaire.

Cette distinction est essentielle. Une CVE publiée, ou une vulnérabilité techniquement exploitable, ne constitue pas à elle seule la preuve qu'une exploitation malveillante réelle a eu lieu. Sans cette nuance, une PME se noierait en signalements inutiles.

Lorsque le fabricant prend connaissance d'une exploitation active :

• Dans les 24 heures : une alerte précoce doit être transmise.
• Dans les 72 heures : une notification plus complète, précisant notamment les informations disponibles sur le produit concerné, la nature de la vulnérabilité et de son exploitation, ainsi que les mesures correctives ou de mitigation déjà prises ou recommandées aux utilisateurs.
• Rapport final : au plus tard 14 jours après qu'une mesure corrective ou de mitigation est disponible.

Incident grave

Le CRA définit également (article 14, paragraphe 5) les situations dans lesquelles un incident doit être considéré comme grave. C'est notamment le cas lorsqu'il affecte, ou est susceptible d'affecter, la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions importantes, ou lorsqu'il peut conduire à l'introduction ou à l'exécution de code malveillant dans le produit ou dans le système d'un utilisateur.

Le calendrier est similaire :

• 24 heures : alerte précoce.
• 72 heures : notification comportant une première évaluation de l'incident et les mesures prises.
• Un mois : rapport final détaillé, calculé à partir de la notification des 72 heures.

Le compteur démarre au moment où le fabricant prend connaissance de la vulnérabilité activement exploitée ou de l'incident (article 14, paragraphes 2 et 4).

C'est précisément ce qui rend l'organisation interne déterminante : une information reçue par le support, un développeur ou une équipe sécurité doit pouvoir atteindre rapidement la personne chargée de décider si une notification CRA est nécessaire.

flag Comment signaler depuis la Belgique ?

Le CRA prévoit un mécanisme européen commun : la CRA Single Reporting Platform (SRP).

Le fabricant n'a pas à notifier séparément chaque État membre dans lequel son produit est vendu. La notification est introduite une seule fois dans la plateforme. Elle est adressée au CSIRT désigné comme coordinateur de l'État membre correspondant à l'établissement principal du fabricant, et rendue simultanément accessible à l'ENISA, sauf circonstances exceptionnelles prévues par le règlement.

Pour une entreprise dont l'établissement principal se trouve en Belgique, le Centre pour la Cybersécurité Belgique (CCB) joue le rôle de CSIRT national via CERT.be, et sera connecté à la plateforme de l'ENISA pour recevoir les signalements CRA. La plateforme doit être accessible à partir du 11 septembre 2026.

L'ENISA indique par ailleurs que les représentants des fabricants utiliseront un compte EU Login pour s'authentifier. Il est donc possible de s'assurer dès maintenant que les personnes susceptibles de gérer une notification en disposent. En revanche, l'ENISA recommande de ne pas lancer inutilement l'enregistrement et la validation d'un fabricant dans la SRP avant d'avoir effectivement une notification à soumettre.

checklist Ce qu'une PME concernée devrait préparer avant le 11 septembre

Il n'est pas nécessaire d'avoir terminé l'ensemble de son chantier CRA avant septembre 2026. En revanche, une entreprise concernée devrait au minimum être capable de détecter une situation soumise à notification et de respecter le délai de 24 heures.

Cinq éléments peuvent être préparés dès maintenant.

1. Identifier les produits qui entrent dans le champ du CRA. Dressez la liste des logiciels, équipements et composants que votre entreprise met sur le marché européen. Pour chacun, déterminez s'il constitue un produit comportant des éléments numériques au sens des articles 2 et 3.
2. Définir qui décide qu'un événement doit être signalé. Un développeur découvre une exploitation active un samedi soir : qui doit-il prévenir ? Le support reçoit la preuve qu'un client a été compromis via votre logiciel : comment l'information remonte-t-elle ? Avec un premier délai de 24 heures, cette responsabilité ne peut pas être arbitrée après l'incident. Désignez à l'avance un responsable et un remplaçant.
3. Créer une procédure d'escalade interne. Votre processus devrait au minimum permettre de conserver l'heure à laquelle l'entreprise a pris connaissance de l'événement, le produit et les versions affectées, les pays dans lesquels le produit est disponible, la nature de l'exploitation ou de l'incident, les premières mesures de mitigation et les informations destinées aux utilisateurs. Ces éléments correspondent directement aux informations demandées dans les notifications à 24 heures, à 72 heures, puis dans le rapport final.
4. Préparer l'accès à la plateforme. Identifiez les personnes qui pourront effectuer un signalement et assurez-vous qu'elles disposent d'un compte EU Login fonctionnel. Le jour où un incident survient n'est pas le meilleur moment pour découvrir le fonctionnement du processus.
5. Prévoir la communication vers les clients. Le signalement aux autorités n'est pas la seule obligation de l'article 14. Après avoir pris connaissance d'une vulnérabilité activement exploitée ou d'un incident grave, le fabricant doit également informer les utilisateurs concernés et leur communiquer, lorsque c'est nécessaire, les mesures correctives ou de réduction du risque qu'ils peuvent appliquer (article 14, paragraphe 8). Cette obligation est souvent oubliée.

policy Ce que l'on risque

Le règlement prévoit des sanctions administratives dont le plafond varie selon la nature du manquement.

Le non-respect des obligations de signalement de l'article 14 relève du plafond le plus élevé. L'article 64, paragraphe 2, prévoit des amendes administratives pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total de l'exercice précédent, le montant le plus élevé étant retenu. Les autres manquements relèvent de plafonds inférieurs, 10 millions d'euros ou 2 % pour une série d'obligations listées à l'article 64, paragraphe 3, et 5 millions d'euros ou 1 % pour la fourniture d'informations fausses, incomplètes ou trompeuses aux autorités.

L'enjeu réel, pour une PME, n'est cependant pas tant l'amende que la démonstration de bonne foi. Une entreprise capable de montrer qu'elle disposait d'un processus, qu'elle a détecté l'événement et qu'elle a notifié dans les délais se trouve dans une position très différente de celle qui découvre l'obligation après coup.

compare_arrows Et le 11 décembre 2027 ?

Le 11 septembre 2026 n'est que la première grande échéance opérationnelle du Cyber Resilience Act.

À partir du 11 décembre 2027, l'essentiel du règlement devient applicable. Les fabricants concernés devront notamment intégrer les exigences essentielles de cybersécurité définies à l'annexe I, réaliser une analyse des risques de cybersécurité, gérer les vulnérabilités pendant toute la période de support du produit, documenter leur conformité et, selon la catégorie du produit, suivre les procédures d'évaluation de conformité prévues par le règlement (articles 6 et 13, et annexe I).

Le calendrier se résume simplement :

• 11 septembre 2026 : soyez capable de détecter et de signaler.
• 11 décembre 2027 : vos produits et vos processus devront répondre à l'ensemble des exigences applicables du CRA.

Pour les produits déjà mis sur le marché avant décembre 2027, les règles transitoires restent importantes : hors obligations de signalement, les nouvelles exigences ne s'appliqueront généralement à ces produits que s'ils font ensuite l'objet d'une modification substantielle.

lightbulb Ne pas attendre 2027 pour commencer

Une entreprise qui prépare aujourd'hui sa conformité CRA n'a pas besoin d'avoir finalisé son marquage CE, sa documentation technique complète ou l'ensemble de son programme de gestion des vulnérabilités pour septembre.

Mais elle doit savoir répondre à une question beaucoup plus urgente : si nous découvrons demain qu'une vulnérabilité de notre produit est activement exploitée, sommes-nous capables de décider rapidement si elle doit être signalée, et d'envoyer la première notification dans les 24 heures ?

À partir du 11 septembre 2026, cette question ne sera plus théorique.

Si votre entreprise relève également de NIS2, la logique de préparation est largement commune, et une grande partie du travail se recoupe. Nous avons publié une checklist NIS2 pour les entreprises belges qui détaille cette partie.