Cyber Resilience Act : ce qui change dès le 11 septembre 2026

Gad
07/09/2026
Sans commentaires

TL;DR : L’essentiel en quelques secondes

Le Cyber Resilience Act ne commence pas en décembre 2027. Dès le 11 septembre 2026, les fabricants de produits matériels ou logiciels connectés au marché européen devront notifier les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de leurs produits. Le premier signalement devra partir sous 24 heures, puis être complété sous 72 heures. Cette obligation concerne également des produits déjà commercialisés avant 2027.

Le 27 juillet 2026, la Commission européenne a publié de nouvelles orientations pratiques sur le périmètre du CRA, les services cloud liés aux produits, l’open source, les modifications substantielles, la durée de support, l’analyse de risque et le reporting. Ce guide apporte des réponses utiles, mais reste non contraignant et ne décale aucune échéance.

À une semaine de l’entrée en application de l’article 14, les entreprises concernées doivent surtout désigner leurs responsables, inventorier leurs produits, préparer leur chaîne d’escalade et créer les comptes EU Login nécessaires. Le portail unique de notification de l’ENISA doit ouvrir le 11 septembre 2026.

Le compte à rebours est presque terminé. Dans quelques jours, une entreprise qui découvre l’exploitation active d’une faille dans l’un de ses produits connectés ne disposera plus de plusieurs semaines pour organiser sa réponse. Elle devra transmettre une première alerte en moins de 24 heures.

Pourtant, beaucoup d’acteurs de l’IoT, de l’automatisation industrielle et du logiciel continuent de retenir une seule date : décembre 2027. C’est une erreur. Cette date marque l’application générale du Cyber Resilience Act, mais la première obligation opérationnelle arrive quinze mois plus tôt.

Le CRA ne commence pas en 2027

Le règlement européen 2024/2847, plus connu sous le nom de Cyber Resilience Act ou CRA, est entré en vigueur le 10 décembre 2024. Il crée un cadre horizontal de cybersécurité pour les « produits comportant des éléments numériques » mis à disposition sur le marché européen.

Son calendrier comporte trois étapes distinctes :

Date	Ce qui change
11 juin 2026	Application des dispositions relatives à la notification des organismes d’évaluation de la conformité.
11 septembre 2026	Application de l’article 14 : notification obligatoire des vulnérabilités activement exploitées et des incidents graves.
11 décembre 2027	Application générale des exigences de cybersécurité, de documentation, d’évaluation de conformité et de marquage CE.

La nuance est essentielle : le 11 septembre 2026 n’est ni une répétition générale ni une date indicative. À partir de ce jour, le délai réglementaire de 24 heures s’applique réellement.

Une vidéo pour comprendre le Cyber Resilience Act

La chaîne IoT Industriel consacre une vidéo au calendrier du CRA et à ses conséquences pour les fabricants d’objets connectés, d’équipements industriels et de logiciels. Elle montre pourquoi attendre 2027 serait une erreur : le règlement transforme dès maintenant la gestion des vulnérabilités, les mises à jour de sécurité et le suivi du parc.

Cette analyse vidéo offre une bonne introduction au sujet. Les sections suivantes intègrent les orientations du 27 juillet 2026 et les dernières informations opérationnelles de l’ENISA.

Qu’a publié la Commission européenne le 27 juillet 2026 ?

Le 27 juillet 2026, la Commission européenne a publié un guide pratique sur l’application du CRA. Ses 67 exemples et logigrammes clarifient plusieurs zones d’ombre, notamment pour les PME. Ce document reste non contraignant : il explique le règlement, sans le modifier.

1. Les services cloud peuvent entrer dans le périmètre

Une solution de traitement à distance développée par le fabricant, ou sous sa responsabilité, entre dans le périmètre lorsqu’elle est nécessaire à une fonction du produit. Pour un capteur industriel, une gateway ou une caméra, il faut donc analyser l’ensemble device + firmware + backend indispensable. Un SaaS autonome n’entre pas automatiquement dans le CRA.

2. Une modification substantielle peut créer un nouveau « fabricant »

Une modification est substantielle lorsqu’elle affecte la conformité aux exigences essentielles ou change la destination prévue. L’entité qui modifie ainsi le produit et le remet sur le marché peut devenir fabricant. Une correction ordinaire n’entre pas automatiquement dans cette catégorie, l’ajout d’une connexion distante ou d’une fonction critique peut, lui, imposer une nouvelle analyse.

3. La durée de support doit correspondre à la réalité du produit

La période de support doit correspondre à la durée d’utilisation attendue. Le minimum est généralement de cinq ans, sauf si le produit est destiné à être utilisé moins longtemps. Un automate ou une Gateway conçu pour fonctionner dix ou quinze ans appelle donc un support cohérent avec cette longévité.

4. L’open source bénéficie d’un régime spécifique, pas d’une exemption générale

Le code open source développé hors activité commerciale n’entre pas, en principe, dans le périmètre. Un logiciel libre commercialisé sous la responsabilité d’un fabricant reste concerné. Le CRA crée aussi un régime allégé pour les « intendants de logiciels open source », avec politique de cybersécurité, coopération et certaines notifications.

5. L’analyse de risque doit vivre avec le produit

L’analyse de risque devra guider la conception, le développement, la production, la livraison et la maintenance, en intégrant les dépendances tierces et les usages raisonnablement prévisibles. La conformité CRA se construit dans le processus produit ; elle ne s’ajoute pas à la veille de la commercialisation.

Qui est concerné par le Cyber Resilience Act ?

Le CRA s’applique aux produits logiciels et matériels mis à disposition sur le marché européen lorsqu’ils disposent d’une connexion logique ou physique, directe ou indirecte, à un appareil ou à un réseau.

Cela couvre notamment les capteurs, g ateways IoT, routeurs industriels, automates et IHM connectés, caméras, équipements réseau, systèmes d’exploitation, applications, composants vendus séparément et certains backends indispensables.

Le texte vise d’abord le fabricant, c’est-à-dire l’entité qui commercialise le produit sous son nom ou sa marque. Importateurs et distributeurs ont aussi des obligations de vérification et de coopération. Un intégrateur peut devenir fabricant s’il remet sur le marché sous son nom un produit substantiellement modifié.

Certains produits déjà couverts par des règles sectorielles sont exclus ou traités spécifiquement, notamment dans le médical, l’aéronautique et l’automobile. L’exclusion se vérifie produit par produit : le simple usage dans une usine, un véhicule ou un hôpital ne suffit pas.

Que faut-il notifier à partir du 11 septembre 2026 ?

Le CRA n’impose pas de signaler chaque CVE présente dans une bibliothèque logicielle. Deux catégories précises déclenchent l’obligation :

Une vulnérabilité activement exploitée, pour laquelle des éléments fiables montrent qu’un acteur malveillant l’a exploitée sans autorisation
Un incident grave affectant la sécurité du produit, notamment sa disponibilité, son authenticité, son intégrité ou la confidentialité de ses données ou fonctions.

Le calendrier de notification est progressif :

Étape	Délai maximal	Informations attendues
Alerte précoce	24 heures après la prise de connaissance	Produit, nature du signalement et informations immédiatement disponibles.
Notification principale	72 heures	Informations générales, première évaluation, nature de l’exploitation ou de l’incident et mesures prises.
Rapport final pour une vulnérabilité	14 jours après la disponibilité d’une mesure corrective ou d’atténuation	Description, sévérité, impact et correctif disponible.
Rapport final pour un incident grave	Un mois après la notification à 72 heures	Analyse détaillée, cause probable, impact et mesures correctives.

Le délai part du moment où le fabricant prend connaissance de l’événement. Une alerte reçue par le support, un CERT, un chercheur, un fournisseur ou le SOC doit donc atteindre immédiatement l’équipe responsable du CRA.

L’obligation s’applique aussi aux produits déjà mis à disposition sur le marché européen. Un parc IoT installé depuis plusieurs années ne disparaît donc pas du périmètre du 11 septembre.

L’ENISA précise qu’une exploitation active déjà connue du fabricant avant cette date n’a pas à être déclarée rétroactivement. Une prise de connaissance après le 11 septembre peut, elle, déclencher le délai.

Comment fonctionnera la plateforme de notification de l’ENISA ?

Les signalements seront déposés une seule fois sur la Single Reporting Platform ou SRP de l’ENISA. Ils seront adressés au CSIRT coordinateur du pays d’établissement principal et accessibles à l’ENISA, sauf circonstances exceptionnelles. Le CSIRT les transmettra aux autres États membres concernés.

Au 4 septembre 2026, l’ENISA indique que la plateforme sera opérationnelle le 11 septembre, mais son URL publique n’est pas encore communiquée. Sa FAQ, mise à jour le 31 août 2026, permet déjà d’anticiper plusieurs contraintes :

L’authentification reposera sur EU Login avec double authentification
Chaque fabricant pourra disposer d’un représentant principal et de 20 représentants secondaires au maximum
La validation du lien entre le représentant et le fabricant sera réalisée par le CSIRT, mais n’empêchera pas les premiers signalements
Aucune API ne sera disponible au lancement, même si l’entreprise peut automatiser son workflow interne
L’interface sera proposée en anglais au lancement
En cas d’indisponibilité temporaire, il faudra attendre le rétablissement du SRP, contacter le CSIRT si l’urgence l’exige, puis déposer malgré tout la notification sur le portail.

L’ENISA conseille de n’initier l’association formelle qu’au moment d’une notification. Les entreprises peuvent néanmoins créer dès maintenant les comptes EU Login, activer la double authentification et désigner les personnes autorisées.

Ce qui deviendra obligatoire en décembre 2027

Le reporting constitue la première marche. À compter du 11 décembre 2027, les fabricants devront démontrer que leurs produits respectent les exigences essentielles du CRA pendant tout leur cycle de vie.

Cela implique une cybersécurité intégrée dès la conception et activée par défaut, une analyse de risque maintenue, la gestion des vulnérabilités et correctifs, des mises à jour pendant la période de support, une documentation technique, une déclaration UE de conformité et le marquage CE. Les composants devront être documentés, notamment au moyen d’une SBOM lisible par machine couvrant au minimum les dépendances de premier niveau.

La majorité des produits pourra être autoévaluée. Les produits importants ou critiques, comme certains routeurs, firewalls, hyperviseurs, éléments sécurisés ou passerelles de compteurs intelligents, suivront une procédure renforcée, parfois avec organisme notifié obligatoire.

Illustration officielle de la Commission européenne sur l’évaluation de conformité du CRA.

Les normes harmonisées apporteront une présomption de conformité. La Commission a demandé l’élaboration de 41 normes horizontales et verticales, sans exonérer le fabricant de l’analyse de ses propres risques.

Pourquoi le CRA est particulièrement exigeant pour l’IoT industriel

Dans l’OT, un équipement connecté peut rester quinze ans sur une ligne de production, avec un firmware ancien et peu de fenêtres de maintenance. Le fabricant doit pourtant connaître les versions déployées, suivre les composants tiers, qualifier rapidement leur impact et distribuer des correctifs sans déstabiliser la production.

Une garantie commerciale courte ne justifie pas l’arrêt de la sécurité si le produit est destiné à rester en service. Le CRA oblige donc à rapprocher produit, firmware, cloud, PSIRT, support, qualité et conformité : la cybersécurité ne peut plus rester cantonnée au RSSI.

La checklist à appliquer avant le 11 septembre

À quelques jours de l’échéance, l’objectif n’est pas de finaliser toute la conformité 2027, mais de savoir qualifier et notifier un événement à temps.

Identifier les produits concernés, y compris les logiciels, composants vendus séparément, backends indispensables et anciens produits toujours présents sur le marché européen.
Nommer un responsable CRA et un remplaçant capables de déclencher la procédure sans attendre une réunion de direction.
Créer leurs comptes EU Login personnels et activer la double authentification.
Définir les critères de qualification d’une vulnérabilité activement exploitée et d’un incident grave.
Créer une chaîne d’escalade 24/7 entre support, SOC, PSIRT, équipes produit, juridique, direction et communication.
Préparer les données du formulaire SRP : fabricant, produit, catégories, pays de commercialisation, chronologie, impact, mesures d’atténuation et identifiants CVE ou EUVD disponibles.
Cartographier les dépendances critiques et les contacts fournisseurs afin de déterminer rapidement si une faille tierce affecte réellement le produit.
Réaliser un exercice à blanc : simulez une faille exploitée un vendredi soir et vérifiez votre capacité à envoyer l’alerte sous 24 heures, puis la notification sous 72 heures.

Les sanctions ne doivent pas être l’unique moteur de cette préparation, mais elles sont significatives. Selon la nature du manquement, le CRA prévoit des plafonds pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.

Les États membres détermineront le régime concret de sanctions. Les microentreprises et petites entreprises bénéficient d’une dérogation ciblée concernant l’amende liée au non-respect du délai de 24 heures , cela ne supprime pas leurs autres obligations.

Cyber Resilience Act et NIS2 : deux textes complémentaires

Le CRA sécurise les produits numériques, NIS2 encadre les entités essentielles ou importantes et leurs systèmes d’information. Une entreprise peut relever des deux textes. Un même incident peut aussi déclencher le RGPD ou une règle sectorielle : un signalement ne remplace pas automatiquement les autres.

Conclusion : le premier vrai test du CRA arrive maintenant

Le 11 septembre 2026 fait passer le CRA du projet de conformité à la contrainte opérationnelle. Les fabricants ne devront pas encore avoir achevé le dossier 2027, mais ils devront détecter, qualifier, documenter et notifier certains événements en quelques heures. La priorité reste de connaître ses produits, ses composants, son parc et les personnes capables d’agir.

Votre organisation peut-elle aujourd’hui identifier une vulnérabilité activement exploitée, mesurer son impact sur chaque version de produit et envoyer une première alerte avant la fin du délai de 24 heures ? Si la réponse n’est pas clairement oui, le chantier ne peut plus attendre.

Pour approfondir les conséquences du règlement sur les objets connectés et les équipements industriels, retrouvez cette vidéo publiée sur IoT Industriel : Cyber Resilience Act : pourquoi vous n’avez PAS jusqu’en 2027.

FAQ sur le Cyber Resilience Act

Le Cyber Resilience Act s’applique-t-il dès le 11 septembre 2026 ?

Oui, mais uniquement pour les obligations de notification prévues à l’article 14. L’application générale des exigences de conception, de documentation, d’évaluation de conformité et de marquage CE interviendra le 11 décembre 2027.
Que faut-il signaler sous 24 heures ?

Le fabricant doit envoyer une alerte précoce lorsqu’il prend connaissance d’une vulnérabilité activement exploitée ou d’un incident grave affectant la sécurité d’un produit comportant des éléments numériques. Une vulnérabilité théorique ou une simple CVE présente dans une dépendance ne déclenche pas automatiquement cette obligation.
À qui faut-il envoyer la notification CRA ?

La notification sera déposée sur la plateforme unique SRP de l’ENISA. Elle sera adressée au CSIRT coordinateur correspondant à l’établissement principal du fabricant et, sauf exception, rendue simultanément accessible à l’ENISA.
Les anciens produits sont-ils concernés par l’échéance du 11 septembre ?

Oui. Les obligations de reporting couvrent aussi les produits déjà mis à disposition sur le marché européen avant l’application générale du CRA. En revanche, l’ensemble des exigences 2027 ne s’appliquera à un ancien produit que dans les conditions transitoires prévues par le règlement, notamment en cas de modification substantielle après cette date.
Tous les logiciels open source sont-ils soumis au CRA ?

Non. Un logiciel libre fourni hors activité commerciale n’entre généralement pas dans le périmètre. En revanche, un fabricant qui commercialise un produit open source sous son nom reste concerné. Les intendants de logiciels open source relèvent d’un régime spécifique et allégé.
Combien de temps un fabricant doit-il fournir des mises à jour de sécurité ?

La période de support doit correspondre à la durée d’utilisation attendue du produit et ne peut généralement pas être inférieure à cinq ans, sauf si le produit est raisonnablement destiné à être utilisé moins longtemps. Pour un équipement industriel conçu pour durer dix ou quinze ans, le support doit refléter cette réalité.
Une mise à jour logicielle est-elle toujours une modification substantielle ?

Non. Une mise à jour devient substantielle si elle affecte la conformité aux exigences essentielles de cybersécurité ou modifie la destination prévue du produit. Une correction de sécurité ordinaire n’entraîne pas automatiquement une nouvelle évaluation complète.
La plateforme SRP propose-t-elle une API ?

Pas à son lancement. L’ENISA indique qu’aucune API ne sera disponible dans un premier temps. Les fabricants peuvent automatiser leur collecte et leur workflow internes, mais la soumission devra être effectuée dans l’interface prévue.

Sources officielles

Règlement (UE) 2024/2847 : texte du Cyber Resilience Act
Commission européenne : présentation du Cyber Resilience Act
Commission européenne : guide pratique publié le 27 juillet 2026
Commission européenne : synthèse du texte législatif
Commission européenne : obligations de reporting
ENISA : plateforme unique de notification CRA
ENISA : FAQ de la plateforme SRP, mise à jour le 31 août 2026

Partagez cet article sur...

Gad

Gad est un auteur passionné et spécialisé dans la rédaction d'articles de blog depuis 2018. Son expertise se concentre sur des thématiques à la croisée de la technologie et de l'industrie, notamment l'Internet des objets (IoT), l'IoT industriel, et la cybersécurité pour les systèmes OT (Operational Technology).

Nos articles récents

Normes et réglementations

Cyber Resilience Act : ce qui change dès le 11 septembre 2026

Gad

Sep 07, 2026

Convergence IT/OT

Cybersécurité OT & IA : Le combo catalyseur de la convergence IT/OT

Gad

Mar 22, 2026

Normes et réglementations

IEC 62443-4-2 : Un impératif pour la cybersécurité OT

Gad

Mar 17, 2026

Cybersécurité OT

Attaques supply chain dans l’OT : comprendre et se préparer

Gad

Déc 09, 2025

Solutions de cybersécurité OT

SOC OT : La tour de contrôle pour vos réseaux industriels

Gad

Oct 05, 2025