CRA PSIRT – Réception des vulnérabilités, signalement sous 24/72 h et chaîne de preuve | Word/PDF/Excel

Recevez, évaluez et documentez une vulnérabilité de sécurité ou un incident concret dans un produit numérique – du premier rapport jusqu’à la notification effective au titre du CRA et à l’information des clients. Ce pack spécialisé pour les fabricants de produits contenant des éléments numériques se concentre sur l’article 14 du CRA et la Single Reporting Platform (SRP) d’ENISA. Il ne remplace pas une évaluation globale des risques au titre du CRA, un SBOM ou une notification effective aux autorités.

En bref : 5 documents de travail suédois, 1 guide utilisateur suédois et 1 guide utilisateur en anglais, tous au format Word (DOCX) modifiable et PDF consultable et imprimable (sans formulaires interactifs), ainsi qu’un classeur Excel suédois de 9 onglets. Au total 15 fichiers clients : sept documents autonomes dans deux formats, plus un fichier XLSX. Livraison numérique au format ZIP lors de l’activation future.

Qui doit choisir le modèle – et quand ?

Pour les développeurs de produits et les fabricants qui vendent des logiciels, des équipements connectés ou d’autres produits contenant des éléments numériques sur le marché de l’UE et qui doivent traiter une indication d’exploitation active ou un incident de sécurité grave. Deux cas de figure : un rapporteur fournit des preuves d’attaques contre une version spécifique d’un micrologiciel ; ou un fabricant apprend l’existence d’un incident affectant gravement la sécurité du produit. Si vous êtes un simple revendeur, un fournisseur de services d’exploitation informatique ou si vous gérez uniquement des incidents informatiques internes, d’autres documents et d’autres règles peuvent être appropriés. Le statut juridique de fabricant et l’application du CRA doivent d’abord être vérifiés.

Fichier par fichier

Le classeur Excel en pratique

Le classeur comprend des enregistrements filtrables, des champs d’état, des liens d’identification et une vue d’ensemble basée sur des formules. Lorsqu’une valeur horaire UTC réelle est saisie pour le moment où le fabricant a pris connaissance d’un événement soumis à notification, le classeur indique les échéances indicatives de 24 h et 72 h. Celles-ci sont des valeurs techniques de contrôle ultime, et non un droit à attendre : notifiez sans délai inutile. La date de la notification finale est saisie manuellement car le déclencheur diffère : disponibilité d’une mesure corrective (AEV) ou transmission effective de la notification de 72 h (SI). Le registre distingue les brouillons, l’évaluation, la notification envoyée et le reçu réel.

Démarche étape par étape

1. Identifier le fabricant juridique, le produit, la version et le rôle PSIRT/SRP habilité.
2. Enregistrer les sources et les preuves sans déposer de secrets ou de code d’exploitation dans des fichiers de bureau non sécurisés.
3. Évaluer séparément l’AEV et la SI au regard de l’article 14 du CRA et documenter le moment de prise de connaissance.
4. En cas d’obligation : préparer les éléments constitutifs et notifier sans délai inutile via la plateforme officielle SRP d’ENISA.
5. Conserver les identifiants et les horodatages réels de soumission pour les notifications de 24 h, de 72 h et la notification finale applicable.
6. Documenter la mesure corrective, les utilisateurs concernés, la communication et le contrôle ultérieur.

Limites juridiques et responsabilités

L’article 14 du CRA (UE) 2024/2847 s’applique aux fabricants à partir du 11 septembre 2026. L’obligation de notifier une vulnérabilité activement exploitée exige des preuves pertinentes d’une exploitation effective ; un numéro CVE ou un niveau de risque élevé ne suffit pas automatiquement. Un incident grave doit être évalué conformément à l’article 14.5. L’alerte précoce doit être émise dans les 24 h et la notification dans les 72 h suivant la prise de connaissance pertinente, sans délai inutile. Pour l’AEV, la notification finale doit être émise au plus tard 14 jours après la disponibilité d’une mesure corrective ou limitative. Pour la SI, la notification finale doit être émise dans le mois suivant la notification effective de 72 h. L’article 14.8 traite de l’information des utilisateurs concernés.

Le FAQ de la SRP et le glossaire des champs d’ENISA doivent être vérifiés directement lors d’une notification réelle, car les champs et les fonctionnalités de la plateforme sont mis à jour. Un statut Word ou Excel ne constitue jamais une notification soumise. Les principales autres exigences du CRA entreront généralement en vigueur le 11 décembre 2027, et l’article 24.3 relatif aux responsables de logiciels libres suivra une date d’entrée en vigueur différente. Si nécessaire, une évaluation spécifique conformément, par exemple, au NIS2, au RGPD et au DORA peut être requise.

Différence avec nos autres documents

Notre pack plus large de conformité au CRA comprend l’évaluation des risques, le SBOM, les exigences de sécurité et le reporting global au titre du CRA. Ce nouveau pack est plutôt une chaîne de travail spécialisée pour un rapport ou un incident effectivement reçu, les reçus SRP, les preuves et l’information des clients.

Questions fréquentes

Chaque vulnérabilité de sécurité doit-elle être notifiée ?

Non. L’article 14 prévoit des seuils spécifiques pour les vulnérabilités activement exploitées et les incidents graves. D’autres vulnérabilités peuvent nécessiter une gestion interne, mais ne constituent pas automatiquement des notifications obligatoires à la SRP.

Le modèle envoie-t-il la notification à ENISA ?

Non. Les éléments constitutifs préparent et documentent le travail ; un représentant habilité doit soumettre la notification via la plateforme SRP réelle.

Les fichiers PDF sont-ils modifiables ?

Ils sont consultables et imprimables, mais ne sont pas des formulaires interactifs à remplir. Utilisez les fichiers Word pour les modifications.

Tout le matériel est-il traduit en anglais ?

Non. Les cinq documents de travail et le classeur Excel sont en suédois. Le guide anglais explique comment utiliser les documents suédois.

Version, sources et transparence

Version 1.0, 9 novembre 2026. Revue juridique assistée par l’IA des sources de l’article 14 du CRA, des informations de la Commission sur la notification et du matériel de la SRP d’ENISA le 9 novembre 2026. Aucune révision juridique indépendante externe, évaluation par les autorités ou certification technique du produit n’a été réalisée. Le pack est une aide administrative, et non une garantie de conformité.