Le 11 septembre 2026 marque une nouvelle étape dans l’application du Cyber Résilience Act. À partir de cette date, les fabricants concernés devront notamment signaler les vulnérabilités activement exploitées et certains incidents graves affectant leurs produits numériques. Au-delà de la conformité, cette échéance pose une question très concrète : votre organisation est-elle réellement capable de réagir dans les délais imposés ?

 

Le 11 septembre change la nature du problème

Le Cyber Résilience Act est déjà largement connu des fabricants de produits numériques. Les exigences de sécurité dès la conception, la gestion des vulnérabilités et le suivi du produit sur son cycle de vie font désormais partie des sujets à anticiper.

Mais le 11 septembre 2026 fait entrer une nouvelle dimension dans le dispositif : la capacité à réagir rapidement lorsqu’un problème de sécurité est identifié.

À partir de cette date, les fabricants devront utiliser la Single Reporting Platform (SRP) mise en place au niveau européen pour déclarer les vulnérabilités activement exploitées ainsi que les incidents graves ayant un impact sur la sécurité de leurs produits.

En France, les notifications seront notamment transmises au CERT-FR, le CSIRT coordinateur désigné auprès de l’ANSSI.

Le sujet n’est donc plus seulement :

« Notre produit est-il sécurisé ? »

Il devient aussi :

« Sommes-nous capables de comprendre et de gérer rapidement ce qui se passe lorsqu’une vulnérabilité est découverte ? »

 

24 heures pour lancer l’alerte

Le CRA prévoit un calendrier particulièrement court.

Lorsqu’un fabricant prend connaissance d’une vulnérabilité activement exploitée, une alerte précoce doit être transmise dans les 24 heures.

Une notification plus complète doit ensuite être effectuée dans un délai de 72 heures. Des rapports complémentaires sont également prévus selon la nature de l’événement et l’avancement des mesures correctives.

Ces délais changent considérablement la façon dont une entreprise doit organiser sa réponse.

Un fabricant ne peut plus dépendre uniquement de quelques personnes capables de retrouver manuellement les informations nécessaires.

Il doit disposer d’un processus défini à l’avance.

 

Le vrai défi : savoir si l’on est concerné

Imaginons une situation désormais très réaliste.

Une vulnérabilité critique est découverte dans une bibliothèque open source utilisée par de nombreux produits.

Le fabricant reçoit l’information.

La première question n’est pas encore :

« Comment corriger la vulnérabilité ? »  Elle est :

« Quels sont les produits TEKIN concernés ? »

Pour répondre rapidement, il faut disposer d’une bonne visibilité sur les composants utilisés dans les produits, leurs versions et leurs dépendances.

C’est ici que des outils comme le SBOM (Software Bill of Materials) prennent tout leur intérêt.

Le SBOM n’est pas une réponse au CRA à lui seul. Mais il peut devenir un élément essentiel pour accélérer l’identification des produits affectés.

Plus la chaîne logicielle est complexe, plus cette visibilité devient importante.

 

Une vulnérabilité ne doit pas devenir une chasse à l’information

Dans une organisation peu préparée, la découverte d’une vulnérabilité peut déclencher une succession de questions :

 

• • Qui a reçu l’alerte ?

 

• • Qui est responsable du produit concerné ?

 

• • Quelle version du logiciel est utilisée ?

 

• • Quels clients utilisent cette version ?

 

• • Le produit est-il réellement vulnérable ?

 

• • La vulnérabilité est-elle activement exploitée ?

 

• • Qui décide de la notification ?

 

• • Qui prépare le correctif ?

Ce fonctionnement peut rapidement devenir problématique lorsque le délai de première notification se compte en heures.

L’enjeu du CRA est donc aussi organisationnel : les responsabilités et les circuits de décision doivent être connus avant l’incident.

 

La question des fournisseurs et composants tiers

Autre difficulté : les fabricants ne maîtrisent pas toujours l’ensemble des composants présents dans leurs produits.

Un produit peut intégrer :

 

• • Des bibliothèques open source ;

 

• • Des logiciels tiers ;

 

• • Des composants firmware ;

 

• • Des briques cloud ;

 

• • Des modules matériels ;

 

• • Des dépendances développées par des fournisseurs.

Une vulnérabilité peut donc être découverte à l’extérieur de l’entreprise tout en ayant des conséquences directes sur ses propres produits.

Cela rend la gestion de la chaîne d’approvisionnement logicielle et matérielle particulièrement importante.

La question à se poser est simple :

Si une vulnérabilité critique est annoncée demain dans un composant que nous utilisons, combien de temps nous faudrait-il pour savoir si nous sommes concernés ?

Si la réponse est « plusieurs jours », c’est probablement un signal qu’il faut renforcer les processus internes.

 

Être conforme ne signifie pas seulement savoir remplir un formulaire

La mise en place de la Single Reporting Platform simplifie la procédure de déclaration, mais elle ne résout pas le problème en amont.

La plateforme permet de transmettre l’information.

Elle ne permet pas à l’entreprise de :

 

• • Détecter une vulnérabilité ;

 

• • Identifier les produits affectés ;

 

• • Qualifier sa criticité ;

 

• • Déterminer si elle est activement exploitée ;

 

• • Coordonner les équipes ;

 

• • Préparer un correctif ;

 

• • Informer les parties prenantes.

Ces capacités doivent être organisées avant qu’un incident ne survienne.

La Commission européenne prévoit d’ailleurs une période de test avant la mise en service de la plateforme, qui doit être opérationnelle le 11 septembre 2026.

 

Êtes-vous prêts ? 7 questions à vous poser

À quelques semaines de cette nouvelle échéance, un premier état des lieux peut commencer par sept questions simples :

 

1. Avons-nous identifié tous les produits concernés par le CRA ?

 

2. Savons-nous qui est responsable de la gestion d’une vulnérabilité ?

 

3. Sommes-nous capables d’identifier rapidement les produits affectés par une vulnérabilité ?

 

4. Disposons-nous d’une visibilité suffisante sur nos composants logiciels et leurs versions ?

 

5. Avons-nous défini les critères permettant de qualifier une vulnérabilité comme activement exploitée ?

 

6. Savons-nous qui prend la décision de notifier et dans quel délai ?

 

7. Avons-nous déjà testé notre processus de réaction ?

Cette dernière question est probablement la plus importante.

Un processus peut sembler parfaitement fonctionnel sur le papier. C’est lorsqu’il est testé qu’on découvre réellement ses points faibles.

 

De la conformité à la cyber-résilience

L’échéance du 11 septembre 2026 illustre finalement une évolution plus profonde portée par le CRA.

La cybersécurité d’un produit ne peut plus être considérée comme un état figé au moment de sa commercialisation.

Elle devient un processus continu :

Surveiller → détecter → qualifier → corriger → notifier → maintenir

Cette logique rapproche directement les équipes produit, R&D, software, hardware et cybersécurité.

Pour les fabricants, l’enjeu est donc autant technique qu’organisationnel.

Le CRA impose un cadre réglementaire. La véritable cyber-résilience repose, elle, sur la capacité de l’entreprise à transformer ce cadre en processus opérationnels.

 

📅 À retenir

11 septembre 2026

Les obligations de déclaration du Cyber Resilience Act commencent à s’appliquer.

Les fabricants concernés devront notamment être capables de signaler les vulnérabilités activement exploitées et certains incidents graves dans les délais prévus par le règlement.

La question à se poser dès maintenant n’est donc plus seulement :

« Sommes-nous conformes au CRA ? »

Mais plutôt :

« Si une vulnérabilité critique est découverte demain matin, sommes-nous capables de réagir dans les 24 heures ? »

 

Sources

Commission européenne — Cyber Resilience Act : obligations de déclaration

ANSSI — Cadre réglementaire du Cyber Resilience Act

ANSSI — FAQ sur le CRA

ENISA — Single Reporting Platform

 

Étape	Délai
Alerte précoce	24 h
Notification complète	72 h
Rapport final – vulnérabilité activement exploitée	14 jours maximum après disponibilité d’une mesure corrective
Rapport final – incident grave	1 mois après la notification à 72 h