Foire aux questions sur le règlement de l’UE sur la cyberrésilience

Oui, si les conditions d’application du CRA sont réunies. Un produit comportant des éléments numériques peut être un logiciel, un matériel, une solution de traitement de données à distance faisant partie du produit, ou un composant logiciel ou matériel mis séparément sur le marché.

Un logiciel fourni en tant que produit peut entrer dans le champ d’application s’il répond à la définition du CRA et aux conditions relatives au marché. Cela comprend les applications autonomes et les micrologiciels. Appliquez les mêmes critères aux outils de développement et aux composants logiciels au lieu de vous prononcer d’après leur seul nom.

En savoir plus dans Produits dans le champ d’application.

Un SaaS autonome ou un service cloud développé en dehors de la responsabilité du fabricant ne constitue pas automatiquement un produit comportant des éléments numériques. Une fonction cloud relève du CRA lorsqu’elle répond à la définition du traitement de données à distance.

Le traitement de données à distance fait partie du produit lorsqu’il a lieu à distance, que le produit en a besoin pour remplir l’une de ses fonctions et que le logiciel de traitement a été conçu ou développé par le fabricant ou sous sa responsabilité.

En savoir plus dans Produits dans le champ d’application.

Non. Le CRA s’appuie sur la notion de connexion de données, et non sur une règle simple d’accès à Internet. Une connexion peut être logique, physique, directe ou indirecte.

Voici quelques exemples pertinents :

• les connexions logiques via des API, des sockets réseau, des pipes, des fichiers, des sessions HTTPS dans un navigateur ou des protocoles de messagerie électronique ;
• les connexions physiques via USB, Ethernet, fibre optique, bus de terrain, Wi-Fi, Bluetooth, NFC ou d’autres liaisons radio ;
• les connexions indirectes via un système hôte lui-même susceptible d’être connecté à un appareil ou à un réseau.

En savoir plus dans Produits dans le champ d’application.

En règle générale, non. Le Guide bleu précise qu’il n’y a pas de mise sur le marché lorsqu’un produit est fabriqué pour son propre usage. La FAQ de la Commission applique ce principe à des exemples relevant du CRA, tels que les outils de développement et de configuration qu’un fabricant crée pour son usage propre.

La réponse change si l’outil est ensuite mis sur le marché en tant que produit distinct. Il doit alors être évalué comme tout autre produit logiciel ou matériel comportant des éléments numériques.

En savoir plus dans Mise sur le marché.

Les produits mis sur le marché avant le 11 décembre 2027 ne sont pas soumis à l’ensemble des exigences du CRA au seul motif que cette date arrive. Ils y seront soumis s’ils font l’objet d’une modification substantielle à compter de cette date.

L’obligation de signalement prévue à l’article 14 est différente. Elle s’applique à partir du 11 septembre 2026 aux produits comportant des éléments numériques relevant du champ d’application du CRA, y compris ceux mis sur le marché avant le 11 décembre 2027.

En savoir plus dans Mise sur le marché et Signalement des vulnérabilités.

La FAQ de la Commission distingue les unités déjà mises sur le marché de celles qui y sont nouvellement mises. Les unités déjà mises sur le marché peuvent continuer à être mises à disposition après l’expiration de la période d’assistance déclarée.

Le cas des unités nouvellement mises sur le marché est différent. Si le fabricant met des unités supplémentaires sur le marché, il doit fixer pour celles-ci une période d’assistance conformément à l’article 13, paragraphe 8.

En savoir plus dans Période d’assistance.

Non. La gratuité de la fourniture ne suffit pas à trancher. Le CRA distingue le développement non commercial de logiciels libres et open source de la mise sur le marché de logiciels dans le cadre d’une activité commerciale.

Les lignes directrices de juillet 2026 distinguent l’accès payant aux logiciels ou à leur maintenance des services facultatifs proposés autour de logiciels disponibles gratuitement. Les éditions payantes peuvent constituer une fourniture commerciale ; des services de conseil facultatifs, à eux seuls, ne rendent pas la version gratuite commerciale. La monétisation de services par l’intermédiaire du logiciel, ou l’obligation de traiter des données à caractère personnel au-delà de ce qui est nécessaire pour améliorer la sécurité, la compatibilité ou l’interopérabilité du logiciel comme condition d’utilisation, peut également conférer un caractère commercial à la fourniture.

En savoir plus dans Rôles et obligations et Produits dans le champ d’application.

Oui, mais uniquement dans le cadre de la règle relative aux tests prévue à l’article 4, paragraphe 3. Le logiciel doit être mis à disposition uniquement pendant la durée limitée nécessaire aux tests et indiquer clairement qu’il n’est pas conforme au CRA et qu’il ne sera pas disponible à d’autres fins que les tests.

La FAQ de la Commission renvoie également au considérant 37 : le fabricant ne devrait publier ce type de logiciel qu’après une évaluation des risques et devrait respecter, dans la mesure du possible, les exigences en matière de sécurité et de traitement des vulnérabilités.

Oui. L’article 13, paragraphe 11, autorise les archives logicielles publiques qui améliorent l’accès des utilisateurs aux versions historiques. Les utilisateurs doivent être clairement informés, d’une manière facilement accessible, des risques liés aux logiciels qui ne sont plus pris en charge.

Une archive n’équivaut pas à une assistance active. Il s’agit de savoir si l’utilisateur peut comprendre que la version archivée n’est plus prise en charge et présente un risque pour la sécurité.

Non. La FAQ de la Commission indique que le CRA n’exige pas des fabricants qu’ils garantissent qu’un produit soit exempt de toute vulnérabilité.

Au moment de la mise sur le marché, l’exigence pertinente de l’annexe I porte sur les vulnérabilités exploitables connues, compte tenu de l’évaluation des risques de cybersécurité du fabricant et des faits disponibles à ce moment-là.

En savoir plus dans Exigences essentielles en matière de cybersécurité et Évaluation des risques de cybersécurité.

Non. Le fabricant doit évaluer si la vulnérabilité concerne le produit et quel risque elle présente. La mesure corrective doit être adaptée à ce risque.

Une mesure corrective peut être un correctif, mais aussi une autre mesure, comme un avis, des instructions de configuration, une solution de contournement, une mise à jour des informations destinées aux utilisateurs ou une mise à jour logicielle ultérieure. Le CRA exige que les vulnérabilités soient traitées et corrigées sans délai, au regard des risques qu’elles présentent pour les produits comportant des éléments numériques.

En savoir plus dans Registres de traitement des vulnérabilités.

Non. Cinq ans constituent une garantie minimale, et non la durée par défaut de tous les produits. Une période d’assistance plus longue peut être nécessaire lorsque l’on peut raisonnablement s’attendre à ce que le produit soit utilisé plus longtemps.

Une période d’assistance plus courte n’est autorisée que si le produit est censé être utilisé pendant moins de cinq ans. Dans ce cas, elle correspond à la durée d’utilisation prévue.

En savoir plus dans Période d’assistance.

Un fabricant signale toute vulnérabilité activement exploitée présente dans son produit. Si la vulnérabilité provient d’un composant intégré et peut être exploitée dans le produit, le fabricant du produit la signale. Le fabricant du composant la signale également si celui-ci a été mis sur le marché en tant que produit propre.

Si la vulnérabilité du composant ne peut pas être exploitée dans le produit du fabricant, cette situation ne déclenche pas l’obligation de signalement prévue à l’article 14. Le fabricant peut néanmoins avoir des obligations de coordination en amont ou de traitement des vulnérabilités.

En savoir plus dans Signalement des vulnérabilités.

Non. La FAQ de la Commission précise qu’un fabricant peut intégrer des composants dépourvus de marquage CE, notamment des composants qui n’ont pas été mis sur le marché et des composants mis sur le marché avant l’application du CRA.

Le fabricant doit néanmoins faire preuve de diligence raisonnable afin que le composant ne compromette pas la cybersécurité du produit final.

En savoir plus dans Registres SBOM et composants.

En général, non. Selon la FAQ de la Commission, il n’existe aucune obligation générale de mettre la documentation technique à la disposition des clients ou du public.

L’exception importante concerne les logiciels gratuits et open source de classe I ou II de l’annexe III lorsque le fabricant souhaite recourir à l’autoévaluation prévue à l’article 32, paragraphe 5. Dans ce cas, la documentation technique doit être rendue publique.

En savoir plus dans Documentation technique et Évaluation de la conformité.

Non. Les projets de normes peuvent être utiles pour la préparation, mais ils ne confèrent pas la présomption de conformité prévue à l’article 27. Celle-ci dépend d’une norme harmonisée dont la référence a été publiée au Journal officiel de l’Union européenne.

La même distinction s’applique aux projets prEN 40000 et aux projets de normes propres à un produit. Les fabricants peuvent s’en servir pour préparer leurs preuves tout en vérifiant séparément leur statut de publication et de citation.

En savoir plus dans Normes harmonisées et présomption de conformité.