Le runbook CRA d’une PME : qui fait quoi dans les 24 heures

14 septembre 2026

Les Tontons

Le runbook CRA d’une PME : qui fait quoi dans les 24 heures

On vous a dit de « désigner un responsable » et de « vérifier l’accès à la plateforme ». C’est une checklist. Un runbook, c’est autre chose : la réponse à la question « qui a le droit de déclarer à 2 h du matin, un vendredi ». Depuis le 11 septembre 2026, elle n’est plus théorique.

Les obligations de signalement du Cyber Resilience Act s’appliquent désormais aux fabricants de produits comportant des éléments numériques, alors que les obligations principales du règlement n’arriveront qu’en décembre 2027.[2][4] Cet article décrit le processus qu’une équipe de cinq à cinquante personnes peut réellement tenir.

H-0 : le compteur démarre quand vous savez, pas quand vous découvrez

Le délai de 24 heures court à compter du prend connaissance de la vulnérabilité activement exploitée ou de l’incident grave, pas au moment de la découverte technique ni à la fin de l’analyse.[1] Un signalement client non lu dans une boîte partagée, une alerte restée trois jours dans un fil Slack : c’est déjà de la prise de connaissance.

Deuxième réflexe à installer : distinguer les deux objets, qui n’ont ni les mêmes champs ni la même horloge finale.

Vulnérabilité activement exploitée : il existe une preuve fiable qu’un acteur malveillant l’exploite dans un système sans l’autorisation de son propriétaire. Le proof-of-concept d’un chercheur ne suffit pas ; l’exploitation réelle, oui.[1][3]
Incident grave : il affecte, ou peut affecter, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes. Il est également qualifié de grave s’il a conduit, ou peut conduire, à l’introduction ou à l’exécution de code malveillant dans le produit ou dans les systèmes d’un utilisateur.[1]

Concrètement : quelqu’un doit être d’astreinte, joignable sept jours sur sept, avec l’autorité de dater le H-0. Pas d’enquêter : de déclencher. Cette personne et son suppléant figurent nommément dans le runbook.

L’early warning : 24 heures, et surtout pas une analyse complète

L’alerte précoce doit partir sans délai injustifié et en tout état de cause dans les 24 heures de la prise de connaissance, en indiquant le cas échéant les États membres où le produit a été mis à disposition. Pour un incident grave, elle doit préciser au minimum si l’incident est soupçonné d’être causé par des actes illicites ou malveillants.[1]

Tous les champs ne sont pas exigés au même stade : certains ne deviennent obligatoires qu’à la notification de 72 heures ou au rapport final.[3] L’early warning signale une existence, il ne conclut pas. Un envoi imparfait à l’heure vaut mieux qu’un rapport parfait en retard.

Dans la version actuelle de la plateforme, le compteur des 72 heures affiche une échéance 48 heures après la soumission de l’early warning. Une notification peut donc apparaître « en retard » avant que les 72 heures légales soient écoulées. L’outil sera corrigé ; en attendant, l’obligation qui compte est celle de l’article 14, pas l’affichage du compteur.[3]

La notification de 72 heures : passer de l’instinct à l’analyse

Pour une vulnérabilité activement exploitée, elle doit fournir les informations générales disponibles sur le produit, la nature générale de l’exploit et de la vulnérabilité, les mesures correctives ou d’atténuation prises, celles que les utilisateurs peuvent appliquer, et le degré de sensibilité que vous attribuez à l’information transmise.[1]

Pour un incident grave, le contenu diffère : nature de l’incident, évaluation initiale, mesures correctives ou d’atténuation prises et celles applicables par les utilisateurs, plus l’indication de sensibilité.[1]

C’est aussi pendant cette fenêtre que se joue une décision peu anticipée : celle des circonstances exceptionnelles. Si au moins une des conditions de l’article 16(2) est remplie, la diffusion vers les autres États membres peut être différée.[3] À comprendre avant de cocher la case : quand ces circonstances sont invoquées, ENISA ne reçoit pas immédiatement le contenu complet ; elle n’a qu’une information partielle jusqu’à ce que le CSIRT destinataire fasse le nécessaire.[3] Ce n’est pas un bouton de confort, et la décision appartient à quelqu’un qui en mesure la portée.

Le rapport final : deux horloges distinctes

Les deux obligations n’ont pas le même point de départ dans le temps.

Vulnérabilité activement exploitée : rapport final au plus tard 14 jours après qu’une mesure corrective ou d’atténuation est devenue disponible.[1] Le délai court dès qu’un contournement existe, pas quand le correctif définitif est prêt.
Incident grave : rapport final dans le mois suivant la soumission de la notification de 72 heures.[1] Horloge fixe, indépendante de la disponibilité du correctif.

Le contenu diverge aussi. Pour une vulnérabilité : description, sévérité, impact, informations disponibles sur l’acteur malveillant, détails de la mise à jour de sécurité.[1] Pour un incident grave : description détaillée, type de menace ou cause racine probable, mesures d’atténuation appliquées et en cours.[1]

La plateforme ne propose aujourd’hui aucun compteur pour le rapport final d’une vulnérabilité activement exploitée, puisque l’échéance dépend de la disponibilité de la mesure corrective.[3] Cette horloge-là, c’est votre runbook qui la tient.

Le rapport intermédiaire : une demande qui peut tomber à tout moment

L’article 14(6) prévoit que le CSIRT destinataire peut demander un rapport intermédiaire sur l’état d’avancement.[1] Ce n’est ni automatique ni planifié : c’est une demande qui tombe, à laquelle il faut répondre avec des faits. Donc avec un pilote identifié qui sait où en est le correctif.

ENISA et CSIRT : qui est qui

Deux sigles reviennent dans toute la procédure, et ils ne désignent pas la même chose.

ENISA est l’Agence de l’Union européenne pour la cybersécurité.[7] Le CRA lui confie l’établissement et l’exploitation de la plateforme unique de signalement, le traitement des notifications, la rédaction de rapports de tendance biennaux, la tenue d’un service d’assistance destiné en particulier aux PME, et la publication des vulnérabilités corrigées dans la base européenne EUVD.[3]

CSIRT signifie Computer Security Incident Response Team : l’équipe nationale de réponse aux incidents de cybersécurité. Chaque État membre en désigne un ou plusieurs, et le réseau des CSIRT, qui réunit ces équipes et CERT-EU, est animé par ENISA, qui en assure le secrétariat.[7] Le CRA ne vise pas un CSIRT au hasard : il cible le CSIRT désigné comme coordinateur, celui prévu par l’article 12(1) de la directive NIS2.[6]

Concrètement, une notification unique déposée sur la plateforme arrive simultanément au CSIRT coordinateur et à ENISA. C’est le CSIRT qui la reçoit qui la rediffuse ensuite, sans délai, aux autres CSIRT des États membres où le produit est disponible, ainsi qu’aux autorités de surveillance du marché.[3]

Qui déclare, et devant quel CSIRT

Une seule soumission via la plateforme : la notification est adressée au CSIRT désigné comme coordinateur et simultanément accessible à ENISA.[2][3] Une seule notification est requise par vulnérabilité ou incident, même avec plusieurs filiales dans l’UE ou une maison mère hors UE : la coordination interne est votre problème.[3]

Le bon CSIRT est celui de l’État membre où sont principalement prises les décisions relatives à la cybersécurité de vos produits. À défaut, celui où vous comptez le plus d’employés dans l’UE. Sans établissement principal dans l’Union, l’ordre de repli est : représentant autorisé, puis importateur, puis distributeur, puis l’État où se trouvent le plus grand nombre d’utilisateurs.[1][3]

Un mauvais CSIRT peut entraîner l’invalidation de la notification, qu’il faut resoumettre.[3] Vérifiez ce point avant l’incident.

Préparer l’accès à la plateforme

La plateforme est opérée par ENISA, à l’adresse portal.cra-srp.enisa.europa.eu.[3] À régler à froid :

Un compte EU Login avec authentification multifacteur est obligatoire, et les comptes sont personnels.[3]
Un représentant désigné primaire par fabricant, jusqu’à 20 secondaires. Le primaire doit avoir une association validée avant d’inviter des secondaires.[3]
La vérification se déroule en parallèle et ne bloque pas la soumission : jusqu’à 20 notifications restent possibles. ENISA conseille de ne s’inscrire qu’au moment de déclarer : quelques minutes suffisent si le compte EU Login existe déjà.[3]
Plateforme en anglais uniquement, et aucune API dans cette première version : tout passe par l’interface.[3]
Si la plateforme est indisponible : attendre son retour puis soumettre. Contacter son CSIRT directement reste possible, mais ne dispense pas de la soumission via la plateforme.[3]

Après le signalement : vos utilisateurs

Obligation souvent oubliée : le fabricant doit informer les utilisateurs concernés, et le cas échéant tous, ainsi que les mesures d’atténuation qu’ils peuvent appliquer, « le cas échéant dans un format structuré, lisible par machine et facilement traitable automatiquement ».[1] S’il ne le fait pas en temps utile, le CSIRT peut informer les utilisateurs à sa place.[1]

Ce que coûte un retard

La non-conformité avec les obligations des articles 13 et 14 est passible d’amendes administratives allant jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial de l’exercice précédent, le montant le plus élevé étant retenu.[5] Nuance importante pour les structures plus petites : la taille de l’opérateur, notamment pour les microentreprises et les PME, y compris les start-ups, est explicitement un critère d’appréciation du montant de l’amende.[5]

Où trouver l’interprétation officielle

Trois documents à mettre dans le dossier du runbook, parce qu’ils répondent aux cas limites que votre équipe rencontrera : la page de la Commission sur les obligations de signalement, la FAQ de la Commission sur la mise en oeuvre du CRA, et le guide publié le 27 juillet 2026 dont la section 9.1 détaille les obligations de signalement des fabricants.[2] Côté plateforme, la FAQ d’ENISA et le glossaire des champs de la SRP précisent, champ par champ, ce qui est requis à chaque étape.[3]

Le runbook minimal, en cinq lignes

Un qualificateur d’astreinte, joignable 7 j/7, qui date le H-0 et porte l’autorité de déclarer.
Un rédacteur de notification qui connaît les champs, avec un compte EU Login MFA déjà fonctionnel.
Un décideur habilité à trancher les circonstances exceptionnelles de l’article 16(2).
Un canal utilisateurs prêt à l’emploi.
Une trace horodatée de la prise de connaissance : elle définit le point de départ de tout le reste.

Le test qui dit si votre runbook existe : simulez une exploitation active découverte un vendredi à 23 h. Combien de temps avant que l’early warning soit soumis, et qui précisément l’a soumis ?

Notre point de vue

Le CRA a une réputation de paperasse. Mais regardez ce que le signalement vous force à construire : un inventaire produit à jour, une veille capable de repérer une exploitation réelle, un canal d’information utilisateurs, une chaîne de décision qui tient un week-end. C’est l’infrastructure dont une équipe hardware a besoin le jour où un composant de sa BOM fait la une.

Le vrai sujet n’est pas le formulaire. C’est de répondre en moins d’une heure à trois questions : ce composant est-il dans un de nos produits ? Ce produit est-il encore supporté ? Qui décide de déclarer ?

Si la troisième réponse est un nom flou, vous n’avez pas un runbook : vous avez une intention.

Vous concevez ou industrialisez des produits connectés pour le marché européen ? Nous aidons les startups et PME hardware à transformer ces obligations en processus tenables. Évaluez votre maturité industrielle et réglementaire avec notre audit gratuit.

Et vous, votre processus de signalement tiendrait-il un vendredi soir ?