Aller au contenu principal

Signalement d’incidents et de vulnérabilités (art. 14)

Les obligations de déclaration du fabricant au titre de l’article 14 du règlement (UE) 2024/2847 s’appliquent depuis le 11 septembre 2026, y compris aux produits déjà sur le marché.

Cette page est la collection destinée aux clients et opérateurs. Le triage interne : politique Security Incident (Notion ; accès éventuellement requis).

Quoi déclarer​

Uniquement :

  • Vulnérabilités activement exploitées — éléments fiables qu’un acteur malveillant a exploité une vulnérabilité du produit sans permission du propriétaire du système.
  • Incidents graves ayant un impact sur la sécurité du produit (art. 14(5)) : ils affectent (ou peuvent affecter) la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou fonctions sensibles ou importantes, ou ils ont conduit (ou peuvent conduire) à l’introduction de code malveillant dans le produit ou les systèmes de l’utilisateur.

Les bugs courants et correctifs ordinaires ne sont pas des événements art. 14.

Comment le fabricant dépose​

Une notification via la plateforme unique de déclaration ENISA : https://portal.cra-srp.enisa.europa.eu.

  • Adressée au CSIRT désigné coordinateur de l’établissement principal dans l’Union (où les décisions de cybersécurité sont principalement prises ; sinon l’établissement avec le plus de salariés dans l’Union), simultanément accessible à l’ENISA (art. 14(7), art. 16).
  • Les Assigned Representatives utilisent un EU Login personnel avec authentification multifactorielle. FAQ SRP ENISA (3 oct. 2026) : la validation de l’association fabricant peut se faire en parallèle d’une première notification.
  • Si la SRP est indisponible : attendre puis déposer. Un contact CSIRT direct ne remplace pas le dépôt SRP.
  • Les déclarations volontaires art. 15 ne sont pas dans la première version de la SRP.
  • Le règlement délégué (UE) 2026/881 permet seulement au CSIRT destinataire de retarder la diffusion vers d’autres CSIRT. Il ne suspend pas les délais fabricant.

La personne Primary Assigned Representative reste TBD (ne pas inventer de nom). La ligne CSIRT reste TBD jusqu’à confirmation de l’entité juridique / établissement principal. États membres de mise à disposition : tous les EU-27 (ci-dessous).

Assigned Representative, EU Login, CSIRT, SRP — de quoi s’agit-il​

Quatre choses distinctes. Aucune n’est un paramètre produit.

TermeCe que c’estQue faire
Assigned Representative (AR)Une personne physique nommée qui peut déposer les notifications art. 14 pour le fabricant. ENISA attend un AR Primary et recommande un Secondary. Ce n’est pas le mandataire art. 19 (personne morale, seulement sans établissement dans l’Union).Nommer les personnes (TBD). Les mettre d’astreinte CRA.
EU Login + MFALe compte personnel Commission européenne (EU Login) avec authentification multifactorielle. Pas le login partagé de info@.Chaque AR crée son EU Login, active le MFA, s’inscrit sur la SRP. ENISA CRA SRP Guidance — AR User Registration.
CSIRT de l’établissement principal dans l’UELe CSIRT national désigné coordinateur de l’État membre de l’établissement principal (art. 14(7)) : lieu où les décisions de cybersécurité du produit sont principalement prises ; sinon l’établissement de l’Union au plus grand effectif. Sans établissement dans l’Union : cascade art. 14(7).Choisir la ligne dans la liste ENISA des CSIRT désignés coordinateurs (4 sept. 2026 ; aussi le menu du portail). Ne pas deviner (pas même la Belgique) tant que l’entité / l’établissement principal n’est pas confirmé. Un mauvais coordinateur peut invalider le dépôt alors que le délai de 24 h court.
Portail SRPportal.cra-srp.enisa.europa.eu — seul chemin art. 14 valable. Une notification est visible du CSIRT choisi et d’ENISA.Le mettre dans le playbook. Déposer même si la validation CSIRT de l’association fabricant est en cours (FAQ ENISA 9).

États membres de mise à disposition​

Position de travail (6 oct. 2026) : le produit est mis à disposition dans tous les États membres de l’UE. Utiliser cette liste pour l’alerte précoce 24 h.

Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden.

Délais (art. 14(2) et (4))​

  1. 24 heures après prise de connaissance — alerte précoce, y compris les États membres où le produit a été mis à disposition (le cas échéant).
  2. 72 heures — notification plus complète : produit, nature de l’exploit ou de l’incident, mesures prises, mesures pour les utilisateurs, sensibilité des informations.
  3. Rapport final — vulnérabilité activement exploitée : au plus tard 14 jours après qu’une mesure corrective ou d’atténuation est disponible. Incident grave : dans un mois après la notification à 72 heures.

Informer les utilisateurs (art. 14(8))​

Après prise de connaissance, le fabricant informe les utilisateurs concernés (et le cas échéant tous les utilisateurs) de la vulnérabilité ou de l’incident et, si nécessaire, des mesures d’atténuation qu’ils peuvent appliquer.

Comment Roasthubs le fait :

  1. Identifier les produits et sites impactés.
  2. E-mail aux contacts opérateurs/admins de ces sites. Ne pas attendre la validation CSIRT de la SRP.
  3. Publier un GitHub Security Advisory sur roasthubs-os et une ligne sur avis de sécurité — immédiatement si les utilisateurs doivent agir avant un correctif ; sinon dès que le correctif est disponible (annexe I partie II §4).
  4. Suivi sur l’adresse CVD surveillée info@roasthubs.com.
  5. Consigner qui a été informé, quand, par quel canal — pour le champ SRP 72 h « mesures que les utilisateurs peuvent prendre ».

Les changelogs fonctionnels ne sont pas le canal art. 14(8). Les bugs ordinaires ne sont pas des événements art. 14.

Manuels officiels : ENISA SRP et Commission déclaration CRA.