Questions fréquentes

La classification dépend de la fonctionnalité principale du produit, et non de chacune de ses fonctions. Si la fonction principale correspond à une catégorie de l’annexe III, le produit est « important » (classe I ou II) ; si elle correspond à l’annexe IV, il est « critique » ; sinon, il est « par défaut ». Une fonction comme la gestion des identités ou un VPN, présente seulement comme fonctionnalité, ne rend pas le produit « important », sauf si c’est sa finalité première. Lorsque plusieurs catégories pourraient s’appliquer, c’est la classe la plus stricte qui prévaut. Art. 7

Les logiciels libres non commerciaux développés en dehors d’une activité commerciale sont largement exclus du champ d’application. Les « gestionnaires » de logiciels libres ont des obligations allégées et adaptées. Les composants open source fournis dans le cadre d’une activité commerciale peuvent, eux, être concernés.

Les services autonomes sont en général en dehors du champ du CRA. Toutefois, les solutions de traitement de données à distance qui sont nécessaires à un produit pour remplir ses fonctions sont considérées comme faisant partie de ce produit et relèvent du champ d'application. Être en dehors du CRA ne signifie pas être non réglementé : les services web et cloud peuvent relever d'autres règles de l'UE, notamment NIS2 (Directive (EU) 2022/2555) pour les entités moyennes et grandes des secteurs couverts, et le GDPR pour les données personnelles. Art. 3(2)

Oui. Le CRA s’applique aux produits mis sur le marché de l’UE, quel que soit le lieu d’établissement du fabricant. Les fabricants hors de l’UE doivent veiller à ce qu’un opérateur économique établi dans l’Union soit responsable des obligations concernées.

Elles se répartissent en deux parties de l’annexe I : les propriétés de sécurité que le produit doit présenter (sécurité par défaut, confidentialité, intégrité, disponibilité, surface d’attaque réduite, mises à jour de sécurité) et les processus de gestion des vulnérabilités que le fabricant doit mettre en œuvre (SBOM, correction, divulgation coordonnée). Annexe I

Oui. Les fabricants doivent identifier et documenter les composants contenus dans le produit, notamment en établissant une nomenclature logicielle dans un format courant et lisible par machine. Annexe I · II(1)

La période de support est la durée pendant laquelle un fabricant doit fournir des mises à jour de sécurité. Elle doit refléter la durée pendant laquelle le produit est raisonnablement censé être utilisé : cinq ans par défaut, plus courte lorsque l'utilisation prévue est plus courte et plus longue lorsqu'elle est plus longue. Art. 13(8)

Les vulnérabilités activement exploitées et les incidents graves affectant la sécurité du produit doivent être notifiés à l’ENISA et au CSIRT compétent. Une alerte précoce est due dans les 24 heures suivant la prise de connaissance, suivie d’une notification plus complète puis d’un rapport final. Art. 14

Le règlement est entré en vigueur le 10 décembre 2024. Les obligations de signalement s’appliquent à partir de septembre 2026 (21 mois plus tard) et l’essentiel des obligations à partir de décembre 2027 (36 mois plus tard). Art. 71

Les manquements aux exigences essentielles ou aux obligations des fabricants peuvent entraîner des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu. Des plafonds inférieurs s’appliquent aux autres infractions et à la communication d’informations inexactes.

Oui, depuis le 11 septembre 2026, jour où l'obligation de l'Art. 14 elle-même a pris effet. La plateforme est en service à l'adresse portal.cra-srp.enisa.europa.eu ; vous sélectionnez le rôle de mandataire désigné et vous vous connectez avec un compte EU Login pour lequel l'authentification multifactorielle est activée. L'ENISA a publié l'adresse dans sa FAQ sur la SRP le 10 septembre 2026, avec un manuel utilisateur pour les mandataires et les conditions générales de la plateforme. Quatre éléments n'ont pas été livrés avec elle : la notification volontaire au titre de l'Art. 15, une API de notification, un champ de prise de connaissance pour les vulnérabilités activement exploitées, et un compteur de 72 heures qui part de la prise de connaissance et non de la soumission de votre alerte précoce, ce qui signifie que l'horloge affichée à l'écran peut indiquer un dépôt comme en retard avant que le délai légal ne soit écoulé. La plateforme fonctionne uniquement en anglais pour le moment. Consultez le guide de notification. Art. 14 · 16

La demande de normalisation M/606 de la Commission a été acceptée par le CEN, le CENELEC et l'ETSI en 2025 et couvre une quarantaine de normes (horizontales et propres aux produits). À la suite du projet de modification de la Commission de juillet 2026 relatif au M/606, qui a repoussé les échéances de 2026 de deux mois, les deux normes horizontales fondamentales (développement sécurisé et gestion des vulnérabilités) sont désormais attendues pour le 31 octobre 2026, les normes verticales de produits pour le 31 décembre 2026 et les normes horizontales restantes pour le 30 octobre 2027, avant l'application complète en décembre 2027. Le respect d'une norme harmonisée citée confère une présomption de conformité. Annexe I

Suivez la procédure d’évaluation de la conformité correspondant à la classe de votre produit, constituez la documentation technique, rédigez et signez la déclaration UE de conformité, puis apposez le marquage CE. Les produits par défaut peuvent s’auto-évaluer ; les produits importants et critiques exigent des procédures plus strictes. Art. 28 · 32

Commencez par le Test rapide CRA pour confirmer le champ d’application et la classe, suivez le guide correspondant à votre rôle, puis utilisez la matrice de conformité pour suivre les exigences essentielles jusqu’à leur réalisation.

Les obligations de notification de l'article 14 deviennent exécutoires. À compter de cette date, les fabricants doivent notifier à ENISA et au CSIRT compétent les vulnérabilités activement exploitées et les incidents sévères par l'intermédiaire de la plateforme de notification unique. Il s'agit de la première des principales obligations du CRA à entrer en vigueur, bien avant l'application complète au 11 décembre 2027. Consultez le guide de notification. Art. 14 · 71

Non. Seuls vulnérabilités activement exploitées et incidents sévères affectant la sécurité de votre produit sont soumises à obligation de notification en vertu de l'article 14. Les vulnérabilités que vous détectez et corrigez avant qu'elles soient exploitées sont gérées dans le cadre de votre processus ordinaire de gestion des vulnérabilités, et non par ce canal de notification. Le guide de notification expose le test et les délais. Art. 14

Via la plateforme de notification unique de l'ENISA, en service depuis le 11 septembre 2026 à l'adresse portal.cra-srp.enisa.europa.eu, qui achemine votre notification vers l'ENISA et le CSIRT national compétent. Vous envoyez une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification plus complète dans les 72 heures, et un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective pour une vulnérabilité, ou dans le mois suivant la notification de 72 heures pour un incident sévère. La connexion se fait via EU Login avec authentification multifactorielle. Consultez le guide pas à pas guide de notification. Art. 14 · 16

En général, non, pas à lui seul. Les Conseils de la Commission précisent qu'un logiciel qui s'exécute sur l'appareil de l'utilisateur (une application téléchargée, une extension de navigateur, un client installé localement) est un produit comportant des éléments numériques, tandis qu'une application web utilisée uniquement via un navigateur, ou un site web qui se borne à présenter des informations, n'en est pas un. Un service à distance n'est couvert que s'il s'agit d'un traitement de données à distance nécessaire à un produit pour remplir ses fonctions. Être en dehors du champ du CRA ne signifie pas être non réglementé : un service uniquement web peut toujours relever de NIS2 (pour les fournisseurs moyens et grands) et du GDPR. Art. 3 Voir le Aperçu des conseils de la Commission.

Cela peut changer la réponse, car le CRA réglemente les produits, et non les services. Le même code empaqueté sous forme d'application installable (y compris une version Capacitor, Electron ou similaire) s'exécute sur l'appareil de l'utilisateur et constitue un produit comportant des éléments numériques ; le CRA s'applique donc. Livré uniquement sous forme d'application web progressive dans le navigateur, il s'agit d'un service web, en général en dehors du champ du CRA en tant que produit ; le backend avec lequel il communique n'est couvert que s'il s'agit d'un traitement de données à distance dont un produit a besoin pour remplir ses fonctions. Deux précautions : un service uniquement web n'est pas non réglementé (NIS2 peut s'appliquer aux fournisseurs moyens et grands, et le GDPR aux données personnelles), et la frontière entre produit et service peut s'estomper ; considérez donc « livrer une PWA » comme une décision d'architecture et non comme une exemption garantie. Art. 3 Voir le Aperçu des conseils de la Commission.

Seulement lorsque la mise à jour est une modification substantielle: une modification qui altère le risque de cybersécurité du produit d'une manière que votre évaluation des risques ne couvrait pas déjà. Les mises à jour de sécurité ordinaires ne constituent généralement pas des modifications substantielles. Lorsqu'une mise à jour est substantielle, le produit modifié est considéré comme nouvellement mis sur le marché et une nouvelle évaluation de la conformité est requise pour les parties concernées. Art. 3(30) Le Conseils de la Commission énonce le critère.