Depuis le 11 septembre 2026, les fabricants de produits comportant des éléments numériques vendus dans l’Union européenne doivent signaler les vulnérabilités activement exploitées et les incidents graves dans un délai de 24 heures. C’est la première obligation du Cyber Resilience Act (CRA, règlement (UE) 2024/2847) à devenir applicable, quinze mois avant l’entrée en application complète du texte, le 11 décembre 2027.
Le CRA vise d’abord les fabricants. Mais pour un exploitant de bâtiment, de site industriel ou de parc IoT, il change la relation avec les fournisseurs d’automates, de passerelles, de contrôleurs GTB et de logiciels de supervision. Cet article reprend ce qui s’applique, pour qui, et les conséquences côté infrastructure.
Ce qui s’applique depuis le 11 septembre 2026
Le règlement est entré en vigueur le 10 décembre 2024 avec une application échelonnée. Les obligations de signalement de l’article 14 sont la première étape. Pour une vulnérabilité activement exploitée dans un de ses produits, le fabricant doit transmettre :
- une alerte précoce sous 24 heures après en avoir pris connaissance ;
- une notification sous 72 heures, avec les informations disponibles sur le produit, la nature de l’exploitation et les mesures correctives ou d’atténuation ;
- un rapport final au plus tard 14 jours après la mise à disposition d’une mesure corrective.
Pour un incident grave affectant la sécurité du produit, le rythme est le même pour les deux premières étapes (24 heures, 72 heures), avec un rapport final sous un mois. Les signalements passent par la plateforme unique de signalement (Single Reporting Platform) opérée par l’ENISA, qui les transmet au CSIRT désigné comme coordinateur dans l’État membre concerné.
À noter : ces obligations de signalement concernent aussi les produits déjà mis sur le marché avant le 11 décembre 2027. Un contrôleur ou une passerelle installé depuis plusieurs années reste donc dans le périmètre de signalement de son fabricant.
Le calendrier complet du CRA
- 10 décembre 2024 : entrée en vigueur du règlement.
- 11 juin 2026 : application des dispositions sur les organismes d’évaluation de la conformité.
- 11 septembre 2026 : obligations de signalement des vulnérabilités activement exploitées et des incidents graves.
- 11 décembre 2027 : application de l’ensemble des exigences essentielles (sécurité dès la conception, gestion des vulnérabilités, mises à jour, documentation, marquage CE).
À partir de décembre 2027, un produit comportant des éléments numériques devra donc répondre aux exigences de cybersécurité du CRA pour porter le marquage CE. Parmi elles : une configuration sécurisée par défaut, des mises à jour de sécurité fournies pendant une période de support déclarée (en principe au moins cinq ans, sauf durée d’utilisation attendue plus courte), un point de contact pour le signalement des vulnérabilités et une nomenclature des composants logiciels (SBOM) tenue par le fabricant.
Pourquoi c’est un sujet pour la GTB et l’IoT industriel
Un bâtiment tertiaire ou un site industriel accumule des dizaines de produits concernés : contrôleurs et automates communicants, passerelles KNX/IP ou BACnet/IP, convertisseurs Modbus, capteurs et actionneurs connectés, brokers MQTT, postes de supervision, caméras, contrôle d’accès. Beaucoup ont été conçus à une époque où la cybersécurité n’était pas un critère d’achat, et beaucoup restent en service quinze ans ou plus.
Sur le terrain, j’y retrouve presque toujours les mêmes constats :
- des équipements de GTB sur le même réseau que la bureautique, voire joignables depuis Internet pour la télémaintenance ;
- des identifiants par défaut ou partagés entre intervenants ;
- des micrologiciels jamais mis à jour, faute de savoir qui en est responsable ;
- aucun inventaire fiable des versions installées, ce qui rend inutile la lecture des avis de sécurité.
Le CRA ne résout pas ces problèmes à la place de l’exploitant : il ne s’applique pas directement à l’utilisateur d’un produit. Mais il crée enfin, côté fournisseurs, une obligation de suivre les vulnérabilités, de les signaler et de les corriger. Encore faut-il être en mesure de recevoir l’information et d’agir dessus.
Intégrateurs : attention au statut de fabricant
Le règlement distingue fabricants, importateurs et distributeurs. Un intégrateur qui commercialise sous son propre nom un produit assemblé, ou qui apporte une modification substantielle à un produit déjà sur le marché, peut être considéré comme fabricant et hériter des obligations correspondantes, y compris le signalement sous 24 heures. C’est un point à faire vérifier, au cas par cas, pour les intégrateurs GTB qui livrent des automates programmés, des boîtiers de passerelle ou des applications de supervision à leur marque.
Ce que l’exploitant peut faire dès maintenant
1. Inventorier les produits connectés
Marque, modèle, version de micrologiciel, emplacement, réseau de rattachement, fournisseur et contrat de maintenance. Sans cet inventaire, un avis de sécurité publié par un fabricant ne déclenche aucune action. C’est le même prérequis que pour NIS2 : la cartographie des actifs.
2. Intégrer le CRA dans les achats
Pour tout nouvel équipement, demander par écrit : la période de support de sécurité annoncée, le point de contact pour les vulnérabilités, la politique de mise à jour et la disponibilité d’une SBOM. Ces éléments deviendront des exigences réglementaires pour le fabricant en 2027 ; les intégrer dès aujourd’hui au cahier des charges évite d’acheter un produit qui sortira du support peu après la réception du chantier.
3. Segmenter les réseaux techniques
La segmentation reste la mesure la plus efficace face à une vulnérabilité exploitée avant la publication d’un correctif. En pratique, cela passe par un ou plusieurs VLAN dédiés à la GTB et aux automates, un filtrage explicite des flux entre zones (seuls les protocoles et les hôtes nécessaires), aucun accès direct depuis Internet, et une télémaintenance passant par un point d’entrée unique, authentifié et journalisé. C’est l’application aux réseaux techniques des principes d’une architecture Zero Trust.
4. Organiser la veille et la mise à jour
Désigner qui suit les avis de sécurité des fabricants et du CERT-FR, qui évalue l’exposition réelle à partir de l’inventaire, et qui applique les correctifs, avec quelle fenêtre de maintenance. Sur un site industriel, une mise à jour d’automate se prépare : sauvegarde de la configuration, test sur un équipement de recette ou un environnement simulé, retour arrière prévu.
5. Superviser les flux
Centraliser les journaux des pare-feu et des passerelles, superviser la disponibilité des équipements et repérer les communications inhabituelles (un contrôleur qui contacte une adresse externe, un nouveau protocole sur un segment). Les outils déjà présents dans beaucoup d’infrastructures, supervision de type Zabbix et SIEM de type Wazuh, couvrent une bonne partie du besoin s’ils intègrent le périmètre technique.
Le jumeau numérique comme banc d’essai
Un jumeau numérique de bâtiment relié aux équipements en KNX, BACnet, Modbus et MQTT oblige à recenser précisément chaque point communicant et chaque flux, ce qui produit de fait l’inventaire et la matrice de flux dont la sécurisation a besoin. Il permet aussi de vérifier, après une mise à jour ou un changement de règle de filtrage, que la remontée des données et les commandes fonctionnent toujours.
CRA et NIS2 : deux textes complémentaires
Le CRA porte sur la sécurité des produits, NIS2 sur la sécurité des organisations. Pour une entité qui sera soumise à NIS2, la sécurité de la chaîne d’approvisionnement fait partie des mesures exigées : choisir des produits dont le fabricant respecte le CRA et organiser la réception de ses avis de sécurité en est une traduction directe. Le report de la loi Résilience transposant NIS2 ne change rien à ce calendrier européen : le CRA est un règlement, directement applicable sans transposition.
Par où commencer
- Dresser l’inventaire des équipements connectés de la GTB et des réseaux industriels.
- Identifier, pour chacun, le fabricant, la version installée et le canal de publication des avis de sécurité.
- Ajouter aux cahiers des charges les exigences de support, de mise à jour et de SBOM.
- Vérifier la segmentation et les accès de télémaintenance par un audit de l’infrastructure.
- Formaliser la procédure de veille, d’évaluation et de déploiement des correctifs.
Sources
- Règlement (UE) 2024/2847 (Cyber Resilience Act), texte officiel sur EUR-Lex
- ENISA : fiche d’information sur la plateforme unique de signalement (PDF, en français)
- Next : les obligations de signalement du CRA entrent en vigueur le 11 septembre
- Siècle Digital : certaines failles doivent être signalées sous 24 heures
- Jones Day : EU Cyber Resilience Act, 24-hour reporting duties start September 11, 2026
- NCSC Irlande : EU Cyber Resilience Act