Obligations de notification du CRA : séparer proprement passeport produit, notification de sécurité et historique des mises à jour

Le 11 septembre 2026 marque le début de l’une des premières obligations opérationnelles du Cyber Resilience Act (CRA) pour les fabricants de produits comportant des éléments numériques : les vulnérabilités activement exploitées et les incidents de sécurité graves doivent être signalés via la nouvelle plateforme centralisée de notification. Il ne s’agit pas simplement d’une nouvelle échéance de conformité. En quelques heures, il faut réunir l’identité du produit, les marchés concernés, l’évaluation technique et les mesures prises.

Un passeport produit numérique ou une page produit associée à un QR code peut aider à identifier clairement un appareil et à informer ultérieurement les utilisateurs d’une mise à jour. Il ne constitue toutefois ni le canal légal de notification ni le lieu de stockage approprié pour les détails confidentiels d’une exploitation. Les fabricants doivent donc dès maintenant séparer trois flux de données : la notification aux autorités, l’information produit publique et l’historique interne des mises à jour.

Le nouvel élément déclencheur : les lignes directrices des 27 et 31 juillet

La Commission européenne a publié le 27 juillet 2026 ses premières lignes directrices complètes sur le CRA. Elles traitent notamment des obligations de notification, de l’évaluation des risques, des périodes de support et des modifications substantielles. Ces lignes directrices ne sont pas contraignantes, mais elles précisent, à l’aide de 67 exemples, comment les entreprises peuvent appliquer concrètement le règlement.

Quatre jours plus tard, le 31 juillet, l’ENISA a mis à jour ses informations sur la Single Reporting Platform. On y trouve désormais le processus prévu, les champs de saisie envisagés et des indications concernant l’enregistrement. La plateforme devrait être opérationnelle d’ici au 11 septembre 2026 ; selon la Commission, les tests fonctionnels et de sécurité sont déjà en cours.

Le calendrier échelonné est important : les principales obligations du CRA s’appliquent en principe à partir du 11 décembre 2027. L’article 14, qui concerne les obligations de notification, s’applique toutefois dès le 11 septembre 2026. Cela est confirmé à la fois par l’article 71 du règlement (UE) 2024/2847 et par la présentation de la Commission sur la procédure de notification du CRA, mise à jour le 31 juillet.

Trois espaces de données plutôt qu’un passeport produit surchargé

La notification au titre du CRA et une page produit publique poursuivent des objectifs différents. Qui cherche à représenter les deux dans un seul jeu de données risque soit de fournir trop peu d’informations à l’équipe chargée des incidents, soit d’exposer trop de détails sensibles sur le Web public.

1. Notification confidentielle à la SRP, au CSIRT et à l’ENISA

La Single Reporting Platform est le canal d’entrée légal. Deux types d’événements doivent être signalés : une vulnérabilité activement exploitée, pour laquelle il existe des indices fiables d’une exploitation non autorisée, et un incident de sécurité grave qui porte atteinte à la disponibilité, à l’authenticité, à l’intégrité ou à la confidentialité des données ou des fonctions.

La notification ne contient pas seulement une désignation du produit. L’ENISA mentionne notamment les États membres concernés, une première évaluation, les contre-mesures déjà prises, les mesures que les utilisateurs pourraient prendre et la sensibilité de l’information parmi les champs prévus. Les étapes ultérieures peuvent contenir le niveau de gravité, les conséquences, les informations sur l’attaquant et les détails techniques de la mise à jour de sécurité. Ces informations ne doivent pas automatiquement figurer sur une page DPP librement accessible.

2. Informations publiques sur le produit et la sécurité

Le flux de données public répond à d’autres questions : de quel produit et de quelle version est-ce que je dispose ? Le produit est-il encore pris en charge ? Une mise à jour de sécurité est-elle disponible ? Que dois-je concrètement faire en tant qu’utilisateur ? Pour cela, une page produit stable accessible via un QR code ou un autre support peut être utile.

La page publique ne devrait présenter que des informations approuvées : gammes de modèles et de versions concernées, version sûre disponible, instructions d’installation, contact du support et date de publication. Les détails de l’exploitation, les règles internes de détection, les vecteurs d’attaque non corrigés ou les données personnelles relatives à l’incident restent dans la procédure protégée. La décision de publier un avertissement ne revient pas au QR code : en vertu de l’article 17 du CRA, le CSIRT coordinateur peut informer le public ou demander au fabricant de le faire lorsque cela est nécessaire à la prévention ou à l’endiguement.

3. Historique interne des mises à jour et des éléments probants

Le troisième flux est le dossier de travail traçable. Il relie l’identifiant du produit, les versions matérielle et logicielle, la nomenclature logicielle, le moment où l’information a été connue, les décisions de triage, les niveaux de notification, l’approbation du correctif et la communication publique. Cet historique doit versionner les modifications au lieu d’écraser discrètement les évaluations antérieures.

Pour une exploitation DPP, cette distinction est essentielle : la vue publique affiche l’état actuel approuvé ; l’historique interne démontre comment il a été établi. Les entreprises qui gèrent déjà leurs données produit selon une logique événementielle peuvent appliquer le même principe que pour les DPP-mises à jour et les webhooks : un événement déclenche des processus consécutifs, mais chaque destinataire ne reçoit que les champs prévus pour son rôle.

Le compte à rebours du CRA commence dès que l’information est connue

L’article 14 prévoit des délais échelonnés. Pour une vulnérabilité activement exploitée, une alerte précoce doit être envoyée sans retard injustifié, au plus tard dans les 24 heures suivant la prise de connaissance. Dans les 72 heures, une notification plus détaillée de la vulnérabilité doit suivre. Le rapport final doit être disponible au plus tard 14 jours après qu’une mesure corrective ou d’atténuation est disponible.

Pour un incident de sécurité grave, le délai applicable à l’alerte précoce est également de 24 heures, et celui de la notification de l’incident de 72 heures. Le rapport final suit dans le mois qui suit la notification à 72 heures. Les délais ne courent donc pas à partir de la publication d’un CVE ni de la prochaine version régulière, mais à partir du moment où le fabricant est réputé informé.

En pratique, il est recommandé de suivre un processus clair :

Enregistrer avec horodatage le signalement provenant du support, de la surveillance, de la recherche ou de la chaîne d’approvisionnement.
Rattacher le produit et la version à un identifiant produit interne stable.
Évaluer l’exploitation ou la gravité de l’incident avec l’équipe compétente.
Générer le dossier des 24 heures à partir des informations minimales confirmées et le transmettre via la SRP.
Compléter les éléments techniques jusqu’au stade des 72 heures, sans perdre l’état initial.
Approuver séparément le correctif, la mesure destinée aux utilisateurs et l’information publique.
Relier le rapport final et l’historique interne.

Cette chaîne devrait être testée sous forme d’exercice avant septembre. L’ENISA indique que les organisations peuvent automatiser leurs processus internes et leurs bases de données, mais que la plateforme ne proposera pas d’API à son lancement. Un processus d’exportation avec double contrôle est donc plus réaliste qu’une intégration directe non vérifiée.

Un identifiant produit commun, mais des droits d’accès séparés

La séparation ne signifie pas qu’il faut gérer trois copies sans lien entre elles. La meilleure approche consiste à utiliser une référence produit commune et immuable, avec des vues dépendant des rôles.

Au minimum, les correspondances suivantes devraient être disponibles :

identifiant produit interne et référence au modèle, au lot ou au numéro de série ;
versions du matériel, du firmware et des logiciels ;
États membres dans lesquels la version concernée a été mise à disposition ;
statut de l’évaluation de sécurité et moment de la prise de connaissance ;
références à la notification à 24 heures, à celle à 72 heures et au rapport final ;
mesure destinée aux utilisateurs approuvée et version cible sûre ;
statut de publication de la page produit publique.

L’autorisation doit être conçue au niveau des champs. L’équipe chargée des incidents et les responsables du CRA ont besoin du dossier complet. Le support et les ventes ont besoin d’une consigne approuvée. Les utilisateurs ne voient que la notification publique. Dans l’idéal, un QR code ne transporte qu’une adresse produit stable ; la plateforme qui se trouve derrière détermine, selon le statut et le rôle, quelles informations sont délivrées.

Ce que les fabricants devraient tester avant septembre

Un scénario de test pertinent ne nécessite pas de véritable vulnérabilité. Choisissez un produit connecté, une version de firmware concernée et trois États membres. Simulez la prise de connaissance un jour ouvré et vérifiez les points suivants :

L’équipe peut-elle confirmer en 24 heures la couverture produit et les informations minimales ?
Est-il clairement défini qui doit accéder à la SRP en tant que représentant via EU Login ?
Est-il possible d’ajouter les informations des 72 heures sans rendre publics des détails confidentiels ?
L’approbation du correctif entraîne-t-elle une information utilisateur vérifiée dans toutes les langues requises ?
L’URL publique reste-t-elle stable lorsque la version et les mesures évoluent ?
Est-il possible de déterminer qui a approuvé quelle version et à quel moment ?

Sur ce dernier point, une gestion cohérente et versionnée des données est utile. L’article de qr3 consacré à la mise à jour continue des DPP présente l’idée fondamentale : l’identité reste stable, tandis que les données métier sont mises à jour de manière contrôlée. Dans le processus CRA s’ajoute une couche plus stricte de confidentialité et d’approbation.

Conclusion : le passeport produit est un diffuseur, pas un canal de notification

Les nouvelles lignes directrices rendent concrètement applicable l’échéance de septembre. Les fabricants n’ont pas à intégrer une base de données confidentielle sur les vulnérabilités dans leur passeport produit numérique. Ils ont plutôt besoin d’une transition fiable entre trois domaines clairement séparés : la notification aux autorités, les éléments probants internes et l’information utilisateur approuvée.

Un identifiant produit commun relie ces domaines. Les rôles, les approbations et la gestion des versions empêchent que des détails confidentiels soient divulgués ou que les utilisateurs soient informés trop tard d’une mesure disponible. Le QR code reste utile, mais volontairement discret : il mène durablement au bon contexte produit. La véritable conformité au CRA se construit dans les processus qui se trouvent derrière.