Un incident, deux circuits de notification : CRA et NIS2 depuis le 11 septembre 2026

L’article 14 du Cyber Resilience Act s’applique depuis le 11 septembre 2026. Les fabricants de produits comportant des éléments numériques doivent désormais notifier les vulnérabilités activement exploitées et les incidents de sécurité graves. Le reste du règlement ne s’applique qu’à partir du 11 décembre 2027 : l’obligation de notification est donc avancée de plus d’un an. Elle vise expressément aussi les produits mis sur le marché avant cette date.

Pour beaucoup d’entreprises, ce n’est pas la première obligation de ce type. Les entités essentielles et importantes au sens de la loi allemande de transposition de NIS2 notifient déjà les incidents importants au BSI depuis décembre 2025. Une entreprise qui commercialise un logiciel en tant que produit et qui est elle-même une entité NIS2 porte donc deux obligations qui se ressemblent sans se recouvrir.

Ce qu’exige le CRA

La notification passe par la plateforme unique de signalement mise en service par l’ENISA le 11 septembre. Une seule soumission parvient à la fois au CSIRT désigné comme coordinateur et à l’ENISA. Pour l’Allemagne, selon le BSI, il s’agit du CERT-Bund au sein du BSI. Aucun enregistrement préalable n’est nécessaire.

Les délais sont échelonnés :

Alerte précoce : sans retard injustifié, au plus tard 24 heures après que le fabricant en a pris connaissance.
Notification : au plus tard après 72 heures, avec de premières informations sur la nature, l’impact et les mesures correctives.
Rapport final : pour les vulnérabilités activement exploitées, au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation ; pour les incidents graves, dans le mois qui suit la notification.

S’y ajoute une obligation souvent oubliée : en vertu de l’article 14, paragraphe 8, le fabricant informe les utilisateurs concernés de la vulnérabilité ou de l’incident et des mesures d’atténuation disponibles. Les dispositions relatives aux sanctions ne s’appliquent qu’avec la pleine application du règlement à partir de décembre 2027. L’obligation elle-même, en revanche, vaut dès aujourd’hui.

Pourquoi une notification ne remplace pas l’autre

Le CRA et NIS2 n’ont pas le même objet. Le CRA vise le produit : une vulnérabilité est activement exploitée lorsqu’il existe des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation de son propriétaire. Cela peut se produire chez un client sans que l’infrastructure du fabricant soit touchée. NIS2 vise l’entité : selon l’article 2, point 11, de la loi allemande sur le BSI, un incident est important s’il cause ou peut causer une perturbation opérationnelle grave ou des pertes financières, ou un dommage considérable à des tiers.

Il en découle trois situations. Une faille exploitée dans un produit livré relève du CRA, mais pas nécessairement de NIS2. Une panne de sa propre exploitation relève de NIS2, sans concerner nécessairement un produit. Et une attaque contre son propre environnement via une vulnérabilité produit peut déclencher les deux, avec deux notifications par deux canaux : le portail du BSI pour NIS2, la plateforme de l’ENISA pour le CRA. En Allemagne, les deux aboutissent au BSI, mais pas dans le même dossier.

Une chronologie, deux évaluations

Deux canaux de notification se gèrent ; deux versions des faits, non. Tenir une chronologie distincte pour chaque obligation finit par produire des horodatages contradictoires. Ce qui fonctionne, c’est un registre d’incidents commun, avec une seule chronologie et deux examens séparés : un produit est-il concerné et y a-t-il exploitation active ? L’exploitation est-elle gravement perturbée ou un tiers a-t-il subi un dommage considérable ?

Trois points décident de la solidité du dispositif en situation réelle. D’abord, un moment de prise de connaissance clairement défini, car les deux délais de 24 heures en dépendent. Ensuite, une fonction nommée qui porte les deux évaluations et n’est pas désignée en plein incident. Enfin, des modèles pour les deux canaux, afin que l’alerte précoce n’échoue pas sur des questions de forme.

La chronologie commence presque toujours par une observation : une panne, un certificat expiré, une modification suspecte du DNS ou des en-têtes. Perstat, notre produit de supervision et de posture de sécurité, consigne ces événements avec leur horodatage et fournit ainsi le point de départ de cette chronologie. Savoir s’il faut notifier, et où, reste une décision de l’entreprise.

Deux obligations de notification n’exigent pas deux organisations. Elles exigent une chronologie qui résiste aux deux.