CRA : qui est concerné par le Cyber Résilience Act ?

Le Cyber Résilience Act (règlement (UE) 2024/2847) est entre en vigueur le 10 décembre 2024. Ce texte impose des exigences de cybersécurité à l’ensemble de la chaîne de valeur des produits comportant des éléments numériques. La question centrale pour toute organisation opérant sur le marché européen est donc simple : êtes-vous concerné ?

La réponse est rarement triviale. Le champ d’application du CRA est volontairement large, et les mécanismes d’exemption sont précis. Cet article décortique méthodiquement qui est visé, ce qui est couvert, et ce qui ne l’est pas.

Les trois catégories d’opérateurs économiques

Le CRA ne se limite pas aux seuls fabricants. Il structuré ses obligations autour de trois catégories d’opérateurs économiques, chacune soumise à des obligations distinctes mais complémentaires.

1. Les fabricants (manufacturers)

Le fabricant est l’acteur central du dispositif. Il s’agit de toute personne physique ou morale qui développé ou fait développer un produit comportant des éléments numériques et le commercialise sous son propre nom ou sa propre marque (article 3, point 13).

Concrètement, si votre entreprise concoit un objet connecté, développé un firmware, ou édite un logiciel distribue sur le marché européen – même à titre gratuit dans certains cas – vous êtes fabricant au sens du CRA.

Les obligations du fabricant sont les plus lourdes : évaluation de conformité, gestion des vulnérabilités pendant toute la durée de vie du produit (et au minimum 5 ans), documentation technique, déclaration de conformité et marquage CE.

Exemple pratique : une entreprise française qui développé des capteurs IoT industriels et les vend sous sa marque est fabricant. Mais une ESN qui développé un firmware pour le compte d’un donneur d’ordre qui le commercialise sous sa propre marque n’est pas fabricant – c’est le donneur d’ordre qui l’est.

2. Les importateurs

L’importateur est toute personne physique ou morale établie dans l’Union qui met sur le marché un produit comportant des éléments numériques provenant d’un fabricant établi hors de l’UE (article 3, point 16).

L’importateur doit vérifier que le fabricant a bien realise l’évaluation de conformité, que la documentation technique est disponible, et que le marquage CE a été appose. Il engagé sa propre responsabilité.

Exemple pratique : un distributeur français qui importe des caméras IP d’un fabricant chinois pour les revendre en France est importateur au sens du CRA. Il doit s’assurer que le fabricant a respecté l’ensemble des exigences avant la mise sur le marché. Consultez notre article sur les responsabilités des importateurs et distributeurs sous le CRA pour le détail des obligations.

3. Les distributeurs

Le distributeur est toute personne physique ou morale dans la chaîne d’approvisionnement, autre que le fabricant ou l’importateur, qui met un produit à disposition sur le marché (article 3, point 17).

Ses obligations sont plus legeres mais réelles : il doit vérifier que le produit porte le marquage CE, que le fabricant et l’importateur ont respecté leurs obligations d’identification, et que les informations d’utilisation sont fournies. Le distributeur doit aussi coopérer avec les autorités de surveillance du marché. Lorsque les produits distribues traitent des données personnelles, les exigences de sécurité des données au titre du RGPD s’appliquent également.

Exemple pratique : un revendeur informatique qui distribue des routeurs Wi-Fi déjà importes en France est distributeur. S’il constate qu’un produit ne respecte pas les exigences, il ne doit pas le mettre à disposition sur le marché.

Qu’est-ce qu’un “produit comportant des éléments numériques” ?

La notion est définie à l’article 3, point 1, du CRA. Il s’agit de tout produit logiciel ou matériel, ainsi que de ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels mis sur le marché séparément.

Cela couvre un spectre extrêmement large :

• Produits matériels avec logiciel embarque : routeurs, caméras IP, capteurs IoT, automates industriels, terminaux de paiement, systèmes domotiques.
• Logiciels autonomes : systèmes d’exploitation, navigateurs, gestionnaires de mots de passe, clients VPN, applications de bureau.
• Composants : bibliotheques logicielles, microcontroleurs, modules de communication vendus séparément.

Le critère déterminant est la présence d’une connexion logique ou physique à un réseau ou à un dispositif. Un logiciel qui ne se connecté a rien et ne traité aucune donnée provenant de l’extérieur peut échapper au champ d’application, mais ces cas sont aujourd’hui marginaux.

Ce qui est exclu du champ

Le CRA exclut explicitement certaines catégories :

• Les services cloud purs (SaaS) ne sont pas directement couverts en tant que “produits”, sauf si le composant logiciel distant fait partie intégrante d’un produit comportant des éléments numériques. En pratique, si votre SaaS est indissociable du fonctionnement d’un objet connecté, il entre dans le champ. Notre analyse des obligations CRA pour les éditeurs SaaS détaille les zones grises.
• Les logiciels développés exclusivement pour un usage interne à l’organisation, sans mise sur le marché.
• Les produits déjà couverts par des réglementations sectorielles spécifiques (voir ci-dessous).

Classification des produits : criticité et catégories

Le CRA distingué trois niveaux de risque, avec des conséquences directes sur les procédures d’évaluation de conformité.

Catégorie	Description	Exemples	Évaluation de conformité
Produits par défaut (non critiques)	La grande majorité des produits numériques	Logiciels de traitement de texte, jeux vidéo, enceintes connectées, disques durs	Auto-évaluation par le fabricant (module A)
Produits importants – Classe I	Produits présentant un risque de cybersécurité significatif	Gestionnaires de mots de passe, interfaces réseau, microcontroleurs, systèmes domotiques, routeurs domestiques, OS non couverts par la Classe II	Application d’une norme harmonisee (auto-évaluation possible) ou évaluation par un tiers
Produits importants – Classe II	Produits a risque élevé de cybersécurité	Pare-feux industriels, systèmes de détection d’intrusion, routeurs industriels, modules cryptographiques, OS pour serveurs/desktops, hyperviseurs, PKI, microprocesseurs sécurisés	Évaluation de conformité par un tiers obligatoire (organisme notifie)
Produits critiques	Produits dont la compromission aurait des conséquences systémiques	Dispositifs physiques de type smartcard, secure élément, HSM, passerelles intelligentes de compteurs (smart meter gateways)	Certification européenne de cybersécurité (schéma EUCC ou équivalent)

Classe I vs Classe II : la distinction clé

La différence entre Classe I et Classe II ne porte pas uniquement sur le type de produit, mais sur le niveau de risque lie à son exploitation. Un routeur Wi-Fi domestique est Classe I ; un routeur industriel utilise dans une infrastructure critique est Classe II. Un système d’exploitation embarque dans un objet grand public est Classe I ; un OS serveur est Classe II.

La conséquence pratique majeure : en Classe II, l’intervention d’un organisme notifie (tiers évaluateur) est obligatoire. Impossible de s’auto-certifier. Pour un CTO, cela signifie des délais et des coûts supplémentaires dans le processus de mise sur le marché.

En Classe I, le fabricant peut encore s’auto-évaluer à condition d’appliquer une norme harmonisee couvrant l’ensemble des exigences essentielles. A défaut, il devra lui aussi passer par un organisme notifie.

Les exemptions sectorielles

Le CRA a été conçu pour éviter les doublons réglementaires, dans une logique similaire à l’articulation entre la directive NIS2 et le CRA. Plusieurs catégories de produits sont exclues de son champ d’application lorsqu’elles sont déjà soumises à des exigences de cybersécurité dans le cadre de réglementations sectorielles :

• Dispositifs médicaux : les produits couverts par les règlements (UE) 2017/745 (dispositifs médicaux) et (UE) 2017/746 (dispositifs médicaux de diagnostic in vitro) sont exclus. Si vous développez un logiciel qualifié de dispositif médical, c’est le cadre MDR/IVDR qui s’applique.

• Véhicules a moteur : les produits relevant du règlement (UE) 2019/2144 relatif à la sécurité générale des véhicules sont exclus. Le règlement UNECE R155 sur la cybersécurité automobile continue de s’appliquer.

• Aviation : les produits couverts par le règlement (UE) 2018/1139 (règles communes dans le domaine de l’aviation civile) sont exclus.

• Équipements marins : les produits couverts par la directive 2014/90/UE sont exclus.

Attention : l’exemption ne vaut que si le produit est effectivement couvert par la législation sectorielle. Un composant logiciel utilise dans un véhicule mais vendu aussi séparément pour d’autres usages peut rester dans le champ du CRA pour ces autres usages.

Le cas particulier de l’open source

Le CRA a fait l’objet de débats intenses concernant les logiciels open source. Le texte final introduit une distinction importante :

• Les logiciels open source développés dans un cadre commercial (c’est-à-dire mis sur le marché dans le cadre d’une activité commerciale) sont soumis aux mêmes obligations que les logiciels propriétaires. Le simple fait qu’un logiciel soit open source ne l’exclut pas du CRA.

• Les logiciels open source développés hors activité commerciale sont exclus. Un développeur benevole qui contribue à un projet open source sans rémunération et sans cadre commercial n’est pas considéré comme fabricant.

• Les intendants de logiciels open source (open source software stewards), c’est-à-dire les fondations et organisations qui soutiennent le développement de logiciels open source sans les commercialiser directement, sont soumis à un régime allégé. Ils doivent mettre en place une politique de cybersécurité, coopérer avec les autorités et signaler les vulnérabilités activement exploitées, mais ne sont pas soumis aux obligations de conformité complètes.

Exemple pratique : une entreprise qui distribue une distribution Linux commerciale est fabricant. La fondation communautaire qui maintient le noyau Linux en amont est potentiellement intendant. Un développeur individuel qui contribue au noyau sur son temps libre n’est pas concerné.

Pour un CISO, cela signifie que l’utilisation de composants open source dans vos produits n’exonère pas votre organisation de ses responsabilités en tant que fabricant. Vous devez évaluer et gérer les vulnérabilités de l’ensemble de vos composants, y compris ceux issus de l’open source.

Comment déterminer si vous êtes concerné

Voici une grille d’analyse rapide :

1. Vous développez un produit logiciel ou matériel qui se connecté à un réseau ou à un autre dispositif ? Vous êtes probablement fabricant au sens du CRA.

2. Vous importez des produits numériques de fabricants hors UE pour les vendre sur le marché européen ? Vous êtes importateur.

3. Vous revendez ou distribuez des produits numériques sans les modifier ? Vous êtes distributeur.

4. Votre produit est un SaaS pur, sans composant logiciel local et sans lien avec un produit physique ? Vous êtes probablement hors champ – mais vérifiez attentivement les cas limités.

5. Votre produit est déjà couvert par une réglementation sectorielle (médical, automobile, aviation) ? Vérifiez si l’exemption couvre l’intégralité de votre produit.

6. Vous contribuez à un projet open source sans activité commerciale ? Vous n’êtes pas concerné en tant que fabricant – mais votre employeur peut l’être s’il intègre votre contribution dans un produit commercial.

Calendrier d’application

Les obligations du CRA s’appliquent de manière progressive :

• 11 septembre 2026 : obligation de signalement des vulnérabilités activement exploitées et des incidents gravés.
• 11 juin 2027 : règles relatives aux organismes notifies et à l’évaluation de conformité.
• 11 décembre 2027 : application de l’ensemble des obligations, y compris les exigences essentielles de cybersécurité et les obligations de gestion des vulnérabilités.

Conclusion

Le Cyber Résilience Act à un champ d’application délibérément large. Fabricants, importateurs et distributeurs de produits comportant des éléments numériques sont tous concernés à des degrés divers. La classification en produits par défaut, Classe I et Classe II déterminé le niveau de contrainte pour l’évaluation de conformité – et donc les ressources a mobiliser.

Pour les organisations qui developpent ou distribuent des produits numériques sur le marché européen, l’analyse de conformité au CRA doit débuter sans attendre. Les délais de mise en conformité sont significatifs, en particulier pour les produits de Classe II nécessitant l’intervention d’un organisme notifie.

Pour une vue d’ensemble du règlement, consultez notre guide complet sur le Cyber Résilience Act.