Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Mardi 29 septembre 2026
Cyber Resilience Act

Cyber Resilience Act : obligations et calendrier CRA

CRA : produits concernés, responsabilités, assistance de sécurité, notifications déjà applicables et préparation des obligations de décembre 2027.

Le Cyber Resilience Act, ou CRA, encadre la cybersécurité des produits comportant des éléments numériques commercialisés dans l’Union européenne. Au 26 septembre 2026, les fabricants concernés doivent déjà organiser les signalements de vulnérabilités activement exploitées et d’incidents graves. Les exigences générales de conception, de conformité et de mise sur le marché s’appliqueront principalement le 11 décembre 2027.

Ce guide explique comment déterminer votre rôle, préparer les preuves attendues et éviter de confondre le CRA avec une certification générale de votre entreprise. Source centrale : règlement (UE) 2024/2847.

Quels produits sont concernés par le CRA ?

L’Art. 2(1) vise les produits comportant des éléments numériques dont l’usage prévu ou raisonnablement prévisible comprend une connexion logique ou physique, directe ou indirecte, à un dispositif ou à un réseau. Cela peut concerner du matériel, des logiciels et des composants commercialisés séparément. Certaines solutions de traitement de données à distance font partie du produit, selon les définitions de l’Art. 3(1)–(2).

Le périmètre comporte des exclusions sectorielles : notamment les dispositifs relevant des règlements européens sur les dispositifs médicaux, certains véhicules, les produits aéronautiques certifiés dans le cadre visé et les équipements marins couverts par leur directive. Les produits développés ou modifiés exclusivement pour la défense ou la sécurité nationale sont également exclus dans les conditions de l’Art. 2. Une simple étiquette « secteur sensible » ne suffit donc pas à exclure un produit.

Pour documenter un cas concret, partez du guide de champ d’application CRA. Les logiciels libres demandent une analyse de la mise à disposition commerciale et, le cas échéant, du statut distinct d’intendant : « open source » n’est pas une exemption universelle.

Fabricant, importateur ou distributeur : qui fait quoi ?

Rôle Travail principal à préparer
Fabricant Évaluation des risques, exigences de sécurité, vulnérabilités, documentation, procédure de conformité et déclaration UE
Importateur Vérifications préalables, identification, traitement des non-conformités, coopération et disponibilité des pièces
Distributeur Vérifications avant mise à disposition, remontée des vulnérabilités et actions face aux non-conformités
Opérateur commercialisant sous sa marque ou modifiant substantiellement le produit Examiner la reprise des obligations du fabricant

Les obligations sont détaillées aux Art. 13 et 18–23. Elles ne se répartissent pas uniquement selon celui qui écrit le code : faire développer puis commercialiser sous son nom peut caractériser le fabricant. L’acheteur qui utilise un produit doit distinguer ses exigences contractuelles de celles directement imposées aux opérateurs par le CRA.

Les principales obligations du fabricant

L’Art. 13 et l’annexe I relient la sécurité aux risques du produit et à son utilisation prévue ou raisonnablement prévisible. Le dossier doit expliquer les décisions prises, pas simplement accumuler des attestations.

  1. Évaluer les risques de cybersécurité. Décrire le produit, ses fonctions, ses dépendances et les conséquences possibles d’une compromission.
  2. Concevoir et configurer la sécurité. Appliquer les exigences pertinentes : absence de vulnérabilité exploitable connue à la mise à disposition, configuration sûre, contrôle des accès, protection des données et limitation de la surface d’attaque.
  3. Organiser les vulnérabilités. Prévoir leur réception, analyse, correction, divulgation coordonnée et distribution des mises à jour.
  4. Identifier les composants. La nomenclature logicielle doit couvrir au minimum les dépendances de niveau supérieur, dans un format couramment utilisé et lisible par machine ; le CRA n’impose pas sa publication générale.
  5. Justifier la conformité. Maintenir la documentation technique et effectuer la procédure adaptée avant la mise sur le marché.

La gestion des vulnérabilités au titre du CRA permet de transformer ces exigences en responsabilités et pièces vérifiables.

Assistance de sécurité : le piège des cinq ans

La période d’assistance doit refléter la durée d’utilisation attendue. L’Art. 13(8) fixe un minimum de cinq ans, sauf lorsque le produit est censé être utilisé moins de cinq ans : l’assistance correspond alors à cette durée attendue. Ce n’est pas une règle permettant de retenir systématiquement la durée la plus courte entre cinq ans et la durée d’utilisation.

La fin d’assistance doit être communiquée clairement au moment de l’achat. L’Art. 13(9) distingue une autre durée : chaque mise à jour de sécurité déjà diffusée doit rester disponible au moins dix ans après sa diffusion, ou jusqu’à la fin de l’assistance si celle-ci est plus longue. Une disponibilité au téléchargement ne signifie pas que le fabricant doit développer de nouveaux correctifs pendant dix ans dans tous les cas.

Classification et procédure de conformité

Catégorie Point de vigilance
Produits hors annexes III–IV Plusieurs procédures possibles, dont le contrôle interne module A
Produits importants classe I Conditions particulières d’utilisation du contrôle interne ; autre procédure lorsque les exigences ne sont pas couvertes comme le prévoit l’Art. 32(2)
Produits importants classe II Procédures Art. 32(3), avec intervention tierce ou schéma européen admissible ; exception spécifique pour certains logiciels libres à l’Art. 32(5)
Produits critiques Certification selon les conditions prévues par les actes délégués de l’Art. 8 ; à défaut, procédure de l’Art. 32(3)

Les systèmes d’exploitation figurent en classe I, tandis que les pare-feu et systèmes de détection ou prévention d’intrusion figurent en classe II. Intégrer un composant important ne classe pas automatiquement le produit entier dans la même catégorie. Le guide de classification CRA explique les fonctions essentielles et les descriptions techniques du règlement d’exécution 2025/2392.

Le marquage CE résulte de la procédure de conformité applicable ; il ne prouve pas une certification universelle par une autorité publique. Pour le logiciel, son emplacement suit les modalités particulières de l’Art. 30(1).

Notification : ce qui s’applique déjà

Depuis le 11 septembre 2026, l’Art. 14 organise deux parcours fabricant :

Événement Premières étapes après connaissance Rapport final
Vulnérabilité activement exploitée Alerte sous 24 heures, notification sous 72 heures Au plus tard 14 jours après disponibilité d’une mesure corrective ou d’atténuation
Incident grave affectant la sécurité du produit Alerte sous 24 heures, notification sous 72 heures Dans le mois suivant la notification à 72 heures

Les signalements sont adressés simultanément au CSIRT coordonnateur et à l’ENISA via la plateforme unique prévue par l’Art. 16. Un rapport final universel à quatorze jours serait donc une mauvaise consigne. Le guide de notification CRA précise la qualification et les informations à préparer.

Calendrier et produits déjà commercialisés

L’Art. 71 prévoit trois étapes : chapitre IV sur les organismes d’évaluation depuis le 11 juin 2026 ; Art. 14 depuis le 11 septembre 2026 ; application générale le 11 décembre 2027.

Les produits mis sur le marché avant le 11 décembre 2027 relèvent de la transition de l’Art. 69 : les obligations générales les concernent en cas de modification substantielle à compter de cette date, tandis que les signalements Art. 14 s’appliquent aussi aux produits antérieurs entrant dans le champ. Le rectificatif du 2 juillet 2025 corrige notamment cette formulation française.

Sanctions et autres textes

L’Art. 64 prévoit notamment un plafond de 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial pour les manquements à l’annexe I et aux Art. 13–14, le montant le plus élevé étant retenu. D’autres catégories ont leurs propres plafonds. Les exceptions, la proportionnalité et les dates d’application doivent être examinées : le régime général d’amendes ne doit pas être présenté comme déjà pleinement applicable en septembre 2026. Voir les sanctions CRA.

La conformité CRA ne remplace ni la sécurité des traitements au titre du RGPD, ni les obligations d’une entité relevant de NIS2, ni l’analyse applicable à un système d’IA. Chaque périmètre, responsabilité et calendrier doit rester identifiable.

Feuille de travail pour démarrer

Créez une ligne par produit et version avec : rôle de l’entreprise, justification du périmètre, fonctions, catégorie, procédure envisagée, responsable du dossier, fin d’assistance et prochain point de contrôle. Reliez ensuite les preuves et ouvrez les actions manquantes. Testez d’abord le circuit de réception et de qualification des incidents : son échéance est déjà passée.

Ce qu’il faut retenir

  • Qualifiez le produit, son marché et le rôle de chaque opérateur.
  • Les notifications Art. 14 s’appliquent depuis septembre 2026.
  • Préparez les exigences générales pour décembre 2027, en tenant compte des transitions.
  • Ne confondez pas durée d’assistance, disponibilité des correctifs et certification.

FAQ

Le CRA concerne-t-il uniquement les objets connectés ?

Non. Il peut également concerner des logiciels et des composants commercialisés séparément, selon les conditions de connexion et de mise à disposition prévues par le texte.

Faut-il une certification tierce pour chaque produit ?

Non. La procédure dépend de sa classification et des conditions de l’Art. 32. Certains produits peuvent relever du contrôle interne.

Peut-on attendre décembre 2027 pour commencer ?

Non pour les signalements Art. 14, déjà applicables depuis septembre 2026. Les autres travaux demandent aussi d’anticiper les choix de conception, de support et de preuve avant la mise sur le marché concernée.

Recevez nos analyses sur la conformité numérique.

Thiébaut Devergranne, docteur en droit, fondateur de donneespersonnelles.fr et de Legiscope, travaille depuis plus de vingt ans sur le droit des technologies.

Thiébaut Devergranne
Docteur en droit des nouvelles technologies (Paris II)

Docteur en droit, Thiébaut Devergranne travaille en droit des nouvelles technologies et en protection des données personnelles depuis plus de 20 ans. Il a accompagné des centaines d'organisations dans leur mise en conformité RGPD et est le fondateur de Legiscope, logiciel de conformité RGPD.

En savoir plus sur l'auteur →