Cyber Resilience Act (CRA) : les nouvelles obligations pour les fabricants et éditeurs de logiciels

Depuis le 11 septembre 2026, tout fabricant d’objet connecté et tout éditeur de logiciel qui vend dans l’Union européenne a une nouvelle obligation légale : signaler sous 24 heures toute vulnérabilité activement exploitée touchant son produit. C’est la première échéance concrète du Cyber Resilience Act (CRA), un règlement européen qui impose pour la première fois des exigences de cybersécurité harmonisées à tout produit comportant des éléments numériques vendu dans l’UE, qu’il s’agisse d’un routeur, d’une caméra connectée, d’un firmware industriel ou d’une simple application SaaS.

Contrairement à une idée répandue, le CRA ne vise pas seulement les grands fabricants d’électronique grand public. Il s’applique à toute PME française qui conçoit, édite ou fait fabriquer un produit numérique destiné au marché européen, sans exemption de taille. Ce guide détaille le calendrier d’application, les exigences essentielles de sécurité par conception, la classification des produits selon leur niveau de risque, le régime spécifique des logiciels libres, et les aménagements prévus pour les PME et les startups.

Cet article complète notre guide complet des nouvelles obligations réglementaires 2026, qui couvre également NIS2, DORA et la migration vers la cryptographie post-quantique.

Qu’est-ce que le Cyber Resilience Act ?

Le Cyber Resilience Act, ou règlement UE 2024/2847, est entré en vigueur le 10 décembre 2024. Il impose pour la première fois un socle harmonisé d’exigences de cybersécurité à tout « produit comportant des éléments numériques » mis sur le marché de l’Union européenne. Cette notion couvre à la fois le matériel connecté (routeurs, caméras, objets IoT industriels, équipements réseau) et les logiciels autonomes, y compris les applications SaaS, les firmwares et les composants logiciels intégrés à un produit plus large.

Le règlement ne prévoit aucune exemption liée à la taille de l’entreprise : une PME ou une startup qui édite un logiciel ou fait fabriquer un objet connecté est soumise aux mêmes exigences de fond qu’un grand groupe industriel, avec toutefois des aménagements de documentation présentés plus loin dans ce guide. Selon une étude relayée par L’Usine Digitale, 66 % des PME françaises disent déjà connaître le Cyber Resilience Act, mais la majorité d’entre elles restent bloquées sur sa mise en œuvre concrète, faute de méthode claire.

Le calendrier d’application : ce qui est déjà obligatoire

Le CRA s’applique de façon échelonnée sur trois ans, ce qui explique une partie de la confusion actuelle chez les fabricants et éditeurs français.

• 10 décembre 2024 : entrée en vigueur du règlement, début du compte à rebours vers les échéances suivantes.
• 11 juin 2026 : entrée en application des obligations pesant sur les organismes notifiés chargés de l’évaluation de conformité.
• 11 septembre 2026 : obligation de signaler à l’ENISA et au CSIRT national compétent, sous 24 heures, toute vulnérabilité activement exploitée, et sous 72 heures tout incident grave affectant un produit comportant des éléments numériques, y compris pour des produits déjà commercialisés.
• 11 décembre 2027 : application complète des exigences essentielles de sécurité, de la documentation technique et du marquage CE pour tout nouveau produit mis sur le marché.

Concrètement, dès aujourd’hui, toute PME éditrice de logiciel doit avoir mis en place un point de contact sécurité identifié, un circuit de traitement des signalements de vulnérabilités, et engagé la constitution de sa nomenclature logicielle (SBOM), avant même l’échéance de décembre 2027 sur les exigences essentielles complètes.

Les exigences essentielles : sécurité par conception et SBOM

L’annexe I du règlement détaille les exigences essentielles que tout produit comportant des éléments numériques doit respecter. Elles reposent sur le principe de sécurité par conception et par défaut (« security by design and by default ») : la sécurité ne doit plus être une option ajoutée après coup, mais une propriété intégrée dès la phase de conception du produit.

Parmi les obligations concrètes les plus structurantes figurent :

• Une configuration sécurisée par défaut, sans identifiants ou mots de passe génériques préconfigurés
• Une protection des données stockées, transmises ou traitées par des mécanismes de chiffrement appropriés
• Un contrôle des accès non autorisés via des mécanismes d’authentification et de gestion des identités adaptés
• Un processus de traitement des vulnérabilités tout au long du cycle de vie du produit, avec des mises à jour de sécurité disponibles pendant une durée de support clairement annoncée
• Une nomenclature logicielle, ou SBOM (Software Bill of Materials), qui documente au minimum les dépendances de premier niveau du produit dans un format lisible par machine

Le SBOM mérite une attention particulière : c’est l’une des obligations les plus nouvelles et les plus techniques du règlement. Pour chaque composant logiciel intégré à un produit, qu’il s’agisse d’une bibliothèque open source ou d’un module tiers, le fabricant doit documenter son nom, sa version exacte et son fournisseur d’origine. Cette nomenclature permet, en cas de vulnérabilité découverte sur un composant largement réutilisé, d’identifier rapidement tous les produits concernés, un peu à la manière dont la crise Log4Shell avait révélé l’absence de visibilité de nombreuses entreprises sur leurs propres dépendances logicielles.

Classification des produits : par défaut, importants, critiques

Tous les produits ne sont pas soumis au même niveau de contrôle. Le CRA distingue quatre niveaux de risque, qui déterminent la procédure d’évaluation de conformité à suivre avant la mise sur le marché.

Une PME qui édite un gestionnaire de mots de passe ou un routeur domestique doit donc anticiper une évaluation par un tiers si elle ne peut pas s’appuyer sur une norme harmonisée déjà publiée, tandis qu’un éditeur de pare-feu ou de système d’exploitation sait d’emblée qu’un organisme notifié devra intervenir. Identifier sa catégorie le plus tôt possible dans le cycle de développement évite des surprises coûteuses à l’approche de l’échéance de décembre 2027.

Logiciels libres : le régime spécifique des stewards open source

Le CRA a fait l’objet d’un débat nourri dans l’écosystème du logiciel libre, qui craignait de voir peser sur de simples contributeurs bénévoles les mêmes obligations que sur un éditeur commercial. Le texte final distingue deux situations bien différentes.

Un développeur individuel ou un projet communautaire qui publie du code en dehors de toute activité commerciale reste entièrement hors du champ d’application du CRA : partager un projet développé bénévolement sur une plateforme d’hébergement de code ne déclenche aucune obligation. En revanche, un « steward » open source, c’est-à-dire une entité qui héberge, administre ou pilote commercialement le développement d’un logiciel libre (fondations, plateformes d’hébergement, éditeurs qui monétisent du support autour d’un projet libre), est soumis à un régime allégé mais bien réel : désigner un point de contact sécurité, coopérer avec les autorités de surveillance du marché, mettre à disposition la documentation de sécurité sur demande, signaler depuis le 11 septembre 2026 les vulnérabilités activement exploitées, corriger les failles sans délai injustifié, et encourager le signalement volontaire de vulnérabilités par les contributeurs. Ces stewards sont dispensés du marquage CE, de l’évaluation de conformité formelle et des sanctions financières prévues par le règlement.

PME et startups : documentation simplifiée et aides financières

Consciente du poids que représente le CRA pour les plus petites structures, la Commission européenne a prévu plusieurs aménagements spécifiques. L’article 33, paragraphe 5, du règlement permet aux microentreprises et aux PME, startups comprises, de produire une documentation technique simplifiée par rapport au dossier complet exigé des grandes entreprises. La Commission a par ailleurs publié un guide de mise en œuvre incluant plus de 60 exemples pratiques, des logigrammes et des cas d’usage destinés à rendre le chemin vers la conformité plus lisible pour les équipes qui n’ont pas de service juridique dédié.

Sur le plan financier, le projet SECURE (Strengthening EU SMEs Cyber Resilience), financé par le programme Europe numérique, propose un soutien pouvant atteindre 30 000 euros par entreprise pour financer la mise en conformité des micro, petites et moyennes entreprises, distribué via un mécanisme de financement en cascade et une procédure de candidature simplifiée. Une part significative des PME interrogées lors des consultations européennes citent d’ailleurs l’aide financière et les modèles de documentation comme leurs deux priorités absolues pour avancer sereinement.

Pour structurer votre démarche de mise en conformité et documenter votre gouvernance, consultez notre modèle de politique de sécurité informatique pour PME. Si votre produit intègre de l’intelligence artificielle, le générateur de charte IA de SIAC Media permet de formaliser vos règles d’usage en complément de vos obligations CRA.

Sanctions et responsabilité en cascade

Le CRA prévoit une architecture de sanctions graduée en trois paliers. Le manquement le plus grave, à savoir la mise sur le marché d’un produit qui ne respecte pas les exigences essentielles de l’annexe I ou les procédures d’évaluation de conformité, expose à une amende pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial de l’exercice précédent, le montant le plus élevé étant retenu. Des paliers inférieurs sanctionnent les autres manquements, comme le défaut de documentation ou l’absence de marquage CE.

Le règlement responsabilise également l’ensemble de la chaîne de distribution, pas seulement le fabricant. Les importateurs doivent vérifier que le fabricant a bien établi la documentation technique requise et apposé le marquage CE avant de commercialiser le produit dans l’UE. Les distributeurs doivent, de leur côté, contrôler la présence des informations obligatoires, notamment la durée de support annoncée par le fabricant. Au-delà des amendes, les autorités de surveillance du marché disposent d’un pouvoir de mise en conformité forcée, de restriction de commercialisation, de rappel de produit, voire d’interdiction pure et simple sur le marché européen.

Plan d’action CRA pour PME

Que vous fabriquiez un objet connecté ou que vous éditiez un logiciel destiné au marché européen, voici la marche à suivre pour avancer méthodiquement d’ici l’échéance de décembre 2027.

1. Déterminez si votre produit entre dans le champ d’application du CRA et identifiez sa catégorie de risque : par défaut, important classe I, important classe II ou critique.
2. Désignez un point de contact sécurité et mettez en place un circuit de réception et de traitement des signalements de vulnérabilités, dès maintenant si ce n’est pas déjà fait.
3. Constituez la nomenclature logicielle (SBOM) de vos produits, en commençant par vos dépendances de premier niveau, dans un format lisible par machine.
4. Auditez votre configuration par défaut pour éliminer tout identifiant générique préconfiguré et vérifier vos mécanismes de chiffrement et de contrôle d’accès. Un audit cybersécurité pour PME réalisé par notre partenaire SIAC Media permet de structurer cette étape.
5. Si vous êtes une microentreprise ou une PME, renseignez-vous sur le dispositif de documentation simplifiée de l’article 33.5 et sur les aides du programme SECURE avant de lancer votre dossier de conformité.
6. Budgétez le coût de mise en conformité et anticipez, le cas échéant, le recours à un organisme notifié si votre produit relève de la classe importante II ou critique. Consultez notre guide sur le budget cybersécurité pour PME.

Foire aux questions sur le Cyber Resilience Act

Une PME qui édite un simple logiciel SaaS est-elle concernée par le CRA ?

Oui, dès lors que ce logiciel constitue un « produit comportant des éléments numériques » commercialisé dans l’Union européenne. Le CRA ne se limite pas aux objets connectés physiques : les logiciels autonomes, y compris les applications SaaS, entrent pleinement dans son champ d’application.

Dois-je déjà avoir le marquage CE pour mon produit ?

Pas encore : l’obligation de marquage CE et de documentation technique complète n’entre pleinement en application que le 11 décembre 2027. En revanche, l’obligation de signaler sous 24 heures les vulnérabilités activement exploitées s’applique déjà depuis le 11 septembre 2026, y compris pour des produits déjà commercialisés.

Mon projet open source bénévole est-il concerné par le CRA ?

Non, si votre participation reste strictement non commerciale. Le CRA exclut de son champ les développeurs individuels et les projets communautaires qui ne sont pas monétisés. Seuls les « stewards » qui hébergent ou pilotent commercialement un projet libre sont soumis à un régime allégé, sans marquage CE ni sanction financière.

Comment savoir si mon produit nécessite l’intervention d’un organisme notifié ?

Cela dépend de sa classification. Les produits de la catégorie « par défaut » et une partie de la classe importante I peuvent faire l’objet d’une auto-évaluation, notamment si des normes harmonisées existent. Les produits de la classe importante II, comme les pare-feux ou les systèmes d’exploitation généralistes, nécessitent systématiquement l’intervention d’un organisme notifié.

Existe-t-il des aides pour financer la mise en conformité CRA de ma PME ?

Oui, le projet européen SECURE, financé par le programme Europe numérique, propose un soutien financier pouvant atteindre 30 000 euros par entreprise pour les micro, petites et moyennes entreprises, via un mécanisme de candidature simplifié.

Conclusion

Le Cyber Resilience Act marque un changement de logique profond pour les fabricants et éditeurs français : la cybersécurité n’est plus un argument commercial optionnel, mais une condition légale de mise sur le marché européen, sous peine de sanctions qui peuvent atteindre 15 millions d’euros. Entre l’obligation de signalement des vulnérabilités déjà en vigueur, la constitution progressive de votre SBOM et l’échéance de décembre 2027 sur les exigences essentielles, mieux vaut avancer dès maintenant, mesure par mesure, plutôt que de découvrir votre non-conformité au moment de la mise sur le marché d’un nouveau produit.

Pour une vue d’ensemble des autres textes qui structurent 2026 et 2027, consultez notre guide complet des nouvelles obligations réglementaires cybersécurité. Notre guide complet de la cybersécurité pour PME et notre panorama des technologies IA de cybersécurité complètent utilement cette lecture.