Cyber Resilience Act : le 11 septembre 2026 est une vraie échéance

La plupart des règlements européens vous donnent une date de conformité et une période de grâce pendant laquelle tout le monde s'organise tranquillement. Le Cyber Resilience Act fait autre chose. Sa première obligation ferme est une horloge de signalement de 24 heures, et elle démarre le 11 septembre 2026.

On ne met pas en place progressivement une horloge de 24 heures. Soit le processus existe le jour J, soit vous manquez l'échéance.

Ce qu'est le CRA

Le règlement (UE) 2024/2847 fixe des exigences de cybersécurité pour les produits comportant des éléments numériques mis sur le marché de l'UE. Cette expression couvre bien plus qu'on ne le suppose au départ : tout produit logiciel ou matériel, et ses solutions de traitement de données à distance, dont l'utilisation prévue ou raisonnablement prévisible inclut une connexion de données directe ou indirecte.

Les appareils connectés sont dans le champ. La plupart des logiciels commerciaux aussi, ainsi que les systèmes d'exploitation, les navigateurs, les applications mobiles, les micrologiciels et les composants intégrés dans d'autres produits.

Le règlement a été publié en novembre 2024 et s'applique par étapes :

11 juin 2026 : obligations des organismes d'évaluation de la conformité.
11 septembre 2026 : obligations de signalement des vulnérabilités activement exploitées et des incidents graves.
11 décembre 2027 : application complète, incluant les exigences essentielles de cybersécurité, le marquage CE, la documentation technique et la nomenclature logicielle.

C'est la date intermédiaire qu'il faut planifier, car elle arrive en premier et parce qu'elle dépend de capacités que vous n'avez peut-être pas.

Ce qui se passe le 11 septembre 2026

À partir de cette date, les fabricants doivent signaler :

Les vulnérabilités activement exploitées dans leurs produits comportant des éléments numériques, et

les incidents graves affectant la sécurité de ces produits.

Le signalement passe par la plateforme unique de signalement du CRA, exploitée par l'ENISA, vers le CSIRT désigné dans l'État membre du principal établissement du fabricant, qui partage ensuite avec les autres CSIRT concernés et l'ENISA.

Le calendrier :

Sous 24 heures après avoir eu connaissance : une alerte précoce.
Sous 72 heures : une notification complète, incluant les mesures correctives ou d'atténuation prises.
Sous 14 jours après qu'une mesure corrective est disponible : un rapport final pour une vulnérabilité activement exploitée.
Sous un mois : un rapport final pour un incident grave.

Vingt-quatre heures à compter de la connaissance, pas de la confirmation, ni de la correction. Si une vulnérabilité d'un composant de votre produit est exploitée dans la nature un samedi, l'horloge tourne le samedi.

Pourquoi c'est plus dur qu'il n'y paraît

L'obligation de signalement en elle-même est un formulaire. La difficulté est dans tout ce qu'il faut avoir en place avant de pouvoir le remplir.

Vous devez savoir ce qu'il y a dans votre produit

Pour signaler qu'une vulnérabilité de votre produit est activement exploitée, vous devez savoir que le composant vulnérable est dans votre produit. Pour une application moderne aux centaines de dépendances transitives, aucun humain ne répond à cela de mémoire.

C'est pourquoi les équipes construisent aujourd'hui des chaînes de nomenclature logicielle, plus d'un an avant l'exigence formelle de SBOM de décembre 2027. La SBOM n'est pas l'objectif. L'objectif est de pouvoir répondre à « sommes-nous concernés ? » en quelques heures, et la SBOM rend la question répondable.

Le point délicat, c'est que cela s'applique aussi aux produits livrés il y a des années. Si vous avez des appareils supportés sur le terrain exécutant un micrologiciel construit en 2022 à partir d'un arbre de dépendances que personne n'a consigné, le reconstituer est un vrai travail.

Vous devez surveiller

La connaissance déclenche l'horloge, et elle est attendue comme active plutôt qu'accidentelle. Cela signifie surveiller les flux de vulnérabilités, s'abonner aux avis de vos composants, suivre les catalogues de vulnérabilités exploitées connues, et disposer d'un canal où des chercheurs en sécurité peuvent vous joindre et obtenir une réponse.

Vous devez avoir un chemin de décision

Quelqu'un doit pouvoir décider, à toute heure, si un incident atteint le seuil et si l'horloge a démarré. Sans rôle nommé et sans chemin d'escalade, les premières heures passent à chercher qui a le droit de trancher.

Les dépendances en fin de vie deviennent un passif

Si un composant de votre produit ne reçoit plus de mises à jour de sécurité, vous portez quand même l'obligation de signalement en cas d'exploitation, et vous n'avez aucun correctif amont à invoquer. Auditer les dépendances en fin de vie est l'une des choses les plus utiles à faire dans la phase préparatoire, car la réponse force parfois une migration qui a son propre délai.

Ce qu'apporte l'application complète en décembre 2027

Les obligations de décembre 2027 constituent le programme le plus lourd, et il faut les entamer bien avant.

Sécurité dès la conception et par défaut. Les produits doivent être conçus, développés et fabriqués pour assurer un niveau approprié de cybersécurité fondé sur le risque. Pas de mots de passe par défaut. Configuration sécurisée dès la sortie. Minimisation de la surface d'attaque. Protection des données en transit et au repos.

Traitement des vulnérabilités. Un processus documenté couvrant identification, correction, test, distribution et divulgation. Les mises à jour de sécurité doivent être fournies sans délai et gratuitement, pour une période de support reflétant la durée de vie attendue du produit, cinq ans étant une référence courante.

Nomenclature logicielle. Dans un format lisible par machine, couvrant au minimum les dépendances de premier niveau, et tenue à jour.

Documentation technique et évaluation de la conformité. La plupart des produits s'auto-évaluent. Les catégories importantes et critiques, qui incluent par exemple les gestionnaires de mots de passe, les VPN, les systèmes d'exploitation et les systèmes de contrôle industriel, exigent l'intervention d'un tiers.

Marquage CE. L'équivalent numérique du marquage physique, déclarant la conformité.

Politique de divulgation coordonnée des vulnérabilités. Publiée, avec un point de contact qui fonctionne.

Qui est réellement dans le champ

Quelques cas limites reviennent constamment.

Les logiciels libres et open source développés hors d'une activité commerciale sont largement hors champ. Le règlement introduit la notion d'intendant de logiciel open source avec des obligations allégées. Mais si vous commercialisez de l'open source, ou le livrez dans un produit que vous vendez, les obligations produit sont les vôtres.

Le logiciel en tant que service est généralement hors du CRA et relève plutôt de NIS2, même si les solutions de traitement de données à distance intégrales à un produit comportant des éléments numériques sont attirées dedans. Si votre appareil dépend de votre backend cloud pour fonctionner, ce backend voyage avec le produit.

Les importateurs et distributeurs portent aussi des obligations. Si vous mettez un produit tiers sur le marché de l'UE sous votre propre nom ou marque, vous êtes traité comme un fabricant.

Les produits déjà réglementés ailleurs, comme les dispositifs médicaux, les véhicules et les équipements aéronautiques, sont traités dans leurs cadres propres.

Les questions de périmètre sont réellement non triviales, et c'est un endroit où une heure avec vos conseils fait gagner des mois d'ingénierie mal orientée.

Ce que nous ferions dans le temps restant

Si vous êtes concerné et démarrez maintenant, voici l'ordre qui fonctionne :

D'abord, établir l'inventaire produit. Qu'avez-vous réellement sur le marché de l'UE ? Y compris les anciennes versions encore sur le terrain, les variantes en marque blanche et les produits que vous distribuez pour quelqu'un d'autre. Cette liste est généralement plus longue que prévu.

Ensuite, intégrer la génération de SBOM en CI. Générer une SBOM à chaque build, en CycloneDX ou SPDX, la stocker avec l'artefact de release, et la garder interrogeable. L'objectif est de pouvoir demander « lesquelles de nos releases livrées contiennent cette bibliothèque ? » et obtenir une réponse en minutes.

Ensuite, brancher la surveillance des vulnérabilités. Alimenter un scanner avec vos données SBOM, qui surveille les avis et les catalogues de vulnérabilités exploitées connues, et router les alertes vers un canal que quelqu'un lit.

Ensuite, écrire le runbook d'incident. Qui déclare, qui évalue, qui signale, qui communique. Personnes nommées, suppléants et contacts hors heures ouvrées. Puis le répéter une fois avec un faux avis. C'est pendant la répétition que vous découvrez que la personne détenant les identifiants de la plateforme de signalement est en vacances.

Ensuite, publier une politique de divulgation des vulnérabilités. Un fichier security.txt, une adresse surveillée et un délai de réponse annoncé. C'est un après-midi de travail et c'est la différence entre apprendre un problème par un chercheur ou par un journaliste.

Enfin, entamer le travail pour décembre 2027. Valeurs par défaut sécurisées, mécanismes de mise à jour, décisions sur la période de support et documentation sont des questions d'architecture, pas de paperasse. Les produits conçus en 2026 seront encore sur le marché en 2028.

Le recoupement que personne n'exploite

Il existe une duplication significative entre le CRA et d'autres régimes, et la plupart des entreprises traitent chacun séparément, ce qui est du gaspillage.

Une SBOM construite pour le CRA répond à la plupart des questions de chaîne d'approvisionnement de NIS2. Le runbook d'incident recoupe l'alerte précoce de 24 heures de NIS2 et la notification de violation de 72 heures du RGPD. Les processus de traitement des vulnérabilités alimentent directement les questionnaires de sécurité clients et les achats grands comptes.

Construisez cela une fois comme capacité de plateforme. L'alternative, ce sont trois équipes construisant trois versions du même inventaire d'actifs.

Où trouver de l'aide

Nous construisons et maintenons des logiciels pour des entreprises vendant dans l'UE, ce qui signifie de plus en plus construire la visibilité sur la chaîne d'approvisionnement et l'infrastructure de mise à jour que le CRA présuppose. Si vous cherchez à savoir si vous êtes concerné, ou si la date de septembre est au calendrier sans aucune surveillance en place, écrivez à office@c9group.dev.

Notre service de maintenance des systèmes existants est souvent le point de départ, car les produits avec la plus mauvaise visibilité sur leurs dépendances sont généralement les plus anciens. L'image réglementaire d'ensemble est dans notre guide de la conformité numérique européenne 2026.

Nous sommes ingénieurs plutôt que juristes. Les décisions de périmètre et de qualification appartiennent à vos conseils, et nous construisons selon la réponse qu'ils donnent.