Cyber Resilience Act (CRA) : obligations, calendrier, sanctions

Mise à jour (juin 2026) : Le Digital Omnibus Package, publié par la Commission en novembre 2025, ne remet pas en cause les obligations structurantes du CRA. Il cherche principalement à simplifier les mécanismes de notification, à réduire les doublons administratifs entre textes et à clarifier le rôle de l’ENISA comme point d’entrée unique. Les obligations de fond restent intactes.

Le CRA est le premier cadre réglementaire européen horizontal qui impose des exigences de cybersécurité aux produits numériques. Il ne s’adresse pas aux organisations en tant que telles : il s’adresse aux produits qu’elles fabriquent, éditent, importent ou distribuent sur le marché de l’Union.

Logiciels, objets connectés, composants, firmware, bibliothèques, SDK : tout produit comportant un élément numérique et mis sur le marché européen entre dans son périmètre. Il s’inscrit dans le cadre réglementaire cyber européen aux côtés de NIS2, du RGPD, du Cybersecurity Act et de l’AI Act. Le Règlement (UE) 2024/2847 est consultable sur EUR-Lex.

Image de juriste étudiant NIS2, DORA, le cadre cyber européen

CRA : ce qu’une entreprise doit comprendre immédiatement :

Le CRA vise les produits numériques, pas seulement les systèmes d’information internes de l’entreprise.
Il concerne les fabricants, éditeurs, importateurs et distributeurs de produits numériques mis sur le marché européen, y compris quand c’est depuis hors UE.
Un logiciel est un produit au sens du CRA, qu’il soit autonome ou embarqué dans un équipement physique.
La cybersécurité devient une condition de conformité produit, au même titre que la conformité électrique ou la sécurité mécanique.
Le marquage CE intégrera la dimension cybersécurité CRA pour tous les produits concernés.
Les vulnérabilités activement exploitées et les incidents graves devront être notifiés à partir du 11 septembre 2026.
L’application complète du règlement est fixée au 11 décembre 2027.
Les produits devront être conçus sécurisés par défaut, pas simplement mis à jour après coup.
Les fabricants devront maintenir un processus de gestion des vulnérabilités pendant toute la durée de support, au minimum 5 ans.
Les sanctions peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial.

Qui est concerné ?

Situation	Concerné par le CRA ?	Niveau d’attention
Fabricant de produits connectés (IoT, équipements réseau, terminaux)	Oui	Très élevé
Éditeur de logiciels distribués dans l’UE	Oui	Très élevé
Importateur de produits numériques fabriqués hors UE	Oui	Élevé
Distributeur / revendeur de produits numériques	Oui (obligations allégées)	Modéré à élevé
Intégrateur incorporant des composants numériques dans un produit finald’un modèle IA	Oui, en tant que fabricant du produit final	Élevé
Fournisseur de bibliothèques, SDK, composants tiers	Oui si commercialisé	Élevé
Acteur open source non commercial	Non (exclusion explicite)	Faible, à vérifier
Entreprise utilisatrice de produits numériques (sans fabrication)	Pas directement assujettie	Modéré (impact achats, contrats)
Fournisseur SaaS pur (logiciel en tant que service uniquement)	Non (exclusion explicite)	Faible, à vérifier

Les entreprises utilisatrices (y compris celles non assujetties comme les fabricants) devront intégrer le CRA dans leurs achats, leurs contrats fournisseurs et leurs processus d’homologation. Acheter un produit non conforme peut exposer l’organisation à des risques opérationnels et contractuels réels.

Nature juridique du texte

Consulter directement le Règlement (UE) 2024/2847 sur EUR-Lex.

Le CRA est un règlement européen : il s’applique directement dans tous les États membres sans transposition nationale. Publié au Journal officiel de l’Union européenne le 20 novembre 2024, entré en vigueur le 10 décembre 2024. Sa base légale est l’article 114 du TFUE (marché intérieur).

Comme le RGPD, il a un effet horizontal : il traverse tous les secteurs, toutes les tailles d’entreprise, tous les types de produits numériques. Seules exceptions explicites : dispositifs médicaux, aviation civile, équipements marins, défense et sécurité nationale, logiciels fournis uniquement comme service (SaaS), logiciels open source développés et distribués hors cadre commercial.

Les États membres désigneront leurs autorités de surveillance du marché. En France, l’ANSSI joue le rôle de coordinateur pour la gestion des vulnérabilités et la certification, et l’ANFR est l’autorité de surveillance du marché pour les produits numériques.

Présentation générale

Avant le CRA, vendre un objet connecté ou un logiciel présentant des failles structurelles n’exposait quasiment à aucune sanction réglementaire spécifique sur le plan cybersécurité. Les règles existantes protégeaient les utilisateurs de données personnelles (RGPD), les opérateurs de services essentiels (NIS2), mais les produits eux-mêmes n’avaient pas de cadre horizontal de cybersécurité obligatoire.

Le CRA comble ce vide. Il impose quatre exigences centrales :

sécuriser les produits dès leur conception ;
réduire les vulnérabilités exploitables ;
maintenir la sécurité pendant tout le cycle de vie ;
donner aux utilisateurs des informations claires sur le support et les mises à jour.

La logique est celle de la conformité produit. Le fabricant devra démontrer que son produit respecte les exigences essentielles de cybersécurité, via une documentation technique, une évaluation de conformité, une déclaration UE de conformité et un marquage CE. Pour les produits classés « importants » ou « critiques », des exigences d’évaluation renforcées s’appliquent, pouvant aller jusqu’à la certification par un organisme notifié.

Le règlement introduit une classification des produits en trois niveaux — standard, important (classe I et II), critique — qui détermine le niveau d’évaluation de conformité requis. La grande majorité des produits relève de la catégorie standard et peut faire l’objet d’une auto-évaluation.

Contexte et champ d’application

Le règlement a été proposé par la Commission européenne en septembre 2022 dans un contexte marqué par l’explosion du nombre d’attaques exploitant des vulnérabilités de produits numériques : routeurs compromis par des botnets, firmware industriel non patché, bibliothèques open source non maintenues, objets connectés grand public livrés avec des mots de passe par défaut identiques pour tous. La guerre en Ukraine a accéléré la prise de conscience européenne sur la dépendance aux produits numériques et sur leur exposition.

Le champ d’application est très large. Il couvre tout produit comportant un élément numérique mis à disposition sur le marché de l’UE, dès lors qu’il peut être connecté directement ou indirectement à un autre appareil ou à un réseau. Cela inclut :

logiciels autonomes (applications, systèmes d’exploitation, suites bureautiques) ;
matériels connectés (smartphones, caméras IP, montres intelligentes, réfrigérateurs connectés, téléviseurs, clés USB) ;
objets IoT industriels et professionnels ;
équipements réseau (routeurs, switchs, pare-feux) ;
composants numériques (modules, puces, cartes mères, firmwares) ;
briques logicielles (SDK, bibliothèques, APIs commercialisées) ;
certains traitements distants nécessaires au fonctionnement du produit.

La notion de « mise à disposition sur le marché » est large : un produit fabriqué en dehors de l’UE et vendu à un client européen entre dans le périmètre. Le critère géographique du fabricant ne suffit pas à se placer hors champ.

Produits critiques : Certains produits sont classés « importants » (classe I et II) ou « critiques » dans les annexes du règlement : systèmes d’exploitation, hyperviseurs, navigateurs web, gestionnaires de mots de passe, logiciels de sécurité, microcontrôleurs, cartes à puce, équipements réseau industriels, entre autres. Ces produits sont soumis à des exigences d’évaluation renforcées et, pour les plus critiques, à un schéma européen de certification.

L’AI Act a été proposé en avril 2021, à une époque où l’IA générative grand public n’existait pas. ChatGPT est arrivé en novembre 2022, en plein milieu des négociations. Le texte a été massivement réécrit en 2023 pour intégrer les modèles d’IA à usage général, ce qui a retardé son adoption mais lui a permis de rester pertinent.

Les obligations s’appliquent dès la conception et tout au long du cycle de vie du produit. Elles varient selon le rôle de l’acteur dans la chaîne de valeur.

Pour les fabricants et éditeurs

Obligation	Ce que cela implique concrètement
Sécurité par conception et par défaut Art. 13 et Annexe I	Le produit doit être conçu avec un niveau de sécurité adapté aux risques. Les configurations initiales ne doivent pas exposer l’utilisateur inutilement (pas de mots de passe génériques, ports inutiles fermés, chiffrement activé par défaut).
Évaluation des risques de cybersécurité Art. 13 §2	Réaliser une analyse de risques cybersécurité documentée, fondée sur les actifs critiques du produit et les menaces réalistes. Cette évaluation est intégrée à la documentation technique.
Gestion des vulnérabilités Art. 13 §6 et Annexe I, partie II	Mettre en place un processus permettant de détecter, documenter, corriger et divulguer les vulnérabilités. Inclut un canal de signalement public et une politique de divulgation coordonnée des vulnérabilités (CVD).
Mises à jour de sécurité Art. 13 §8 et §9	Fournir des correctifs pendant toute la durée de support annoncée, avec une information claire à l’utilisateur. Durée minimale de 5 ans, sauf indication différente et justifiée par la nature du produit.
Documentation technique Art. 31 et Annexe VII	Constituer et conserver le dossier de conformité : architecture, analyse de risques, tests, liste des vulnérabilités connues, historique des correctifs. Doit être disponible pendant 10 ans après la mise sur le marché.
Déclaration UE de conformité Art. 28 et Annexe V	Formaliser la conformité du produit aux exigences essentielles du CRA par une déclaration écrite. Le contenu minimal de cette déclaration est défini en annexe.
Marquage CE Art. 30	Apposer le marquage CE sur le produit et dans la documentation. Ce marquage atteste de la conformité aux exigences du CRA et des autres règlements applicables.
Notification des vulnérabilités exploitées et incidents graves Art. 14	À partir du 11 septembre 2026 : notifier à l’ENISA via la Plateforme Unique de Signalement (SRP) sous 24 heures toute vulnérabilité activement exploitée et tout incident grave impactant la sécurité du produit.
Information des utilisateurs Art. 13 §18 et Annexe II	Informer les utilisateurs de façon compréhensible sur les risques de cybersécurité, la durée de support, les mises à jour disponibles et les risques résiduels connus.

Pour les importateurs

S’assurer que le fabricant a bien respecté ses obligations avant de mettre le produit sur le marché européen. Conserver la documentation technique, vérifier la présence du marquage CE, signaler les produits non conformes aux autorités de surveillance. En cas de risque sérieux, retirer ou rappeler le produit.

Pour les distributeurs

Vérifier avant la mise à disposition que le produit porte bien le marquage CE et que la documentation est disponible. Ne pas mettre sur le marché des produits dont ils savent ou soupçonnent qu’ils ne sont pas conformes. Coopérer avec les autorités de surveillance du marché.

Le CRA ne se résume pas à une politique de sécurité. Il implique des mesures techniques précises, documentées, et auditables. Les équipes produit, développement et sécurité devront travailler ensemble sur :

Analyse de risques produit fondée sur les usages prévus et les menaces réalistes ;
Secure by design : intégration des exigences de sécurité dès les phases de conception ;
Secure by default : durcissement des configurations initiales, réduction de la surface d’attaque ;
Mécanismes d’authentification robuste et de contrôle d’accès ;
Protection de la confidentialité et de l’intégrité des données traitées ;
Journalisation utile à la sécurité et à la traçabilité des incidents ;
Sécurité du mécanisme de mise à jour : signature des composants, vérification de l’intégrité des mises à jour ;
Gestion des dépendances : inventaire des composants tiers, bibliothèques open source, modules ;
SBOM (Software Bill of Materials) : liste des composants logiciels, lorsque pertinent pour la traçabilité et la gestion des vulnérabilités ;
Politique de divulgation coordonnée des vulnérabilités (CVD) et canal public de signalement ;
Processus de correction et de documentation des vulnérabilités corrigées ;
Prise en compte des composants obsolètes ou non maintenus dans la chaîne de dépendances ;
Documentation du cycle de vie de support et des engagements de maintenance.

Le point structurant est la traçabilité. Un fabricant qui ne sait pas quels composants sont dans son produit, ni quelles vulnérabilités le touchent, ni comment les corriger, ne peut pas satisfaire aux exigences du CRA. C’est là que la plupart des entreprises ont encore du travail à faire.

Date	Étape
15 septembre 2022	Proposition initiale de la Commission européenne
23 octobre 2024	Adoption définitive du règlement par le Parlement européen et le Conseil
20 novembre 2024	Publication au Journal officiel de l’UE
10 décembre 2024	Entrée en vigueur du règlement
11 juin 2026	Application des dispositions relatives à la notification des organismes d’évaluation de la conformité
11 septembre 2026	Application des obligations de notification des vulnérabilités activement exploitées et des incidents graves à l’ENISA (via la plateforme SRP)
11 décembre 2027	Application intégrale du CRA pour tous les produits concernés
Après 2027	Montée en charge des contrôles, de la surveillance du marché, des évaluations de conformité et des sanctions

Point de réalisme : Le délai jusqu’au 11 décembre 2027 est plus court qu’il n’y paraît pour les fabricants qui doivent revoir leur processus de développement, constituer leur documentation technique, mettre en place la gestion des vulnérabilités et préparer la notification. Les entreprises qui attendent 2027 pour commencer auront du mal à tenir.

Les obligations de notification, elles, entrent en vigueur dès septembre 2026.

DORA : DORA impose aux entités financières une maîtrise des risques TIC. Le CRA améliore la sécurité des produits et composants numériques que ces entités acquièrent. Un équipement réseau ou un logiciel conforme CRA réduit mécaniquement une partie du risque TIC DORA. Pour la conformité DORA, voir Conformité DORA.

AI Act : L’AI Act encadre les systèmes d’IA selon les niveaux de risque. Le CRA peut s’appliquer aux produits numériques intégrant de l’IA : un logiciel embarqué avec une brique IA relève des deux textes. Les exigences se cumulent.

RGPD : Le RGPD protège les données personnelles. Le CRA protège les produits numériques. Les deux convergent dès qu’une faille produit expose des données personnelles, ce qui est très fréquent pour les objets connectés et les applications grand public.

Cybersecurity Act (CSA) : Le CSA établit les schémas européens de certification cybersécurité. Pour les produits CRA classés « importants » ou « critiques », la certification sous un schéma CSA peut devenir un outil de preuve de conformité ou une exigence directe.

eIDAS 2 / EUDI Wallet : Les wallets et leurs composants logiciels relèvent indirectement du CRA. Un composant numérique dans la chaîne de confiance de l’identité numérique européenne devra être conforme CRA.

Data Act : Le Data Act organise l’accès aux données issues des objets connectés. Le CRA impose que ces produits soient conçus avec un niveau de sécurité adapté. Les deux textes s’appliquent souvent aux mêmes objets.

DSA / DMA : Le DSA vise les plateformes et services en ligne, le DMA les grands contrôleurs d’accès. Le CRA est centré sur les produits et composants. Des recoupements peuvent exister pour des produits logiciels distribués dans ces écosystèmes.

Le Digital Omnibus Package, publié par la Commission européenne en novembre 2025, ne remet pas en cause les obligations de fond du CRA. Son objectif est différent : rationaliser l’empilement des textes numériques européens, réduire les doublons administratifs et simplifier les mécanismes de reporting pour les entreprises soumises simultanément à plusieurs régimes.

Pour le CRA, les effets attendus portent sur plusieurs points :

La simplification des obligations de notification : l’omnibus prévoit la création d’un Single Entry Point (SEP) géré par l’ENISA, permettant à un acteur soumis à plusieurs régimes de notification (NIS2, CRA, DORA, RGPD) de notifier une même vulnérabilité ou un même incident une seule fois. Pour un fabricant qui est aussi une entité essentielle NIS2, c’est un allègement attendu.
L’harmonisation des délais de notification : l’omnibus cherche à aligner les délais entre textes, ce qui peut modifier les fenêtres actuellement prévues par le CRA (24 heures pour la notification initiale).
La clarification des interactions entre autorités : ANSSI, ENISA, autorités de surveillance du marché. La répartition des rôles et des flux d’information devrait être précisée.
La réduction des doubles déclarations pour les entreprises soumises à la fois au CRA et à NIS2 ou à DORA.

Le message à retenir est celui-là : le Digital Omnibus simplifie le comment, pas le quoi. Les obligations structurantes du CRA (sécurité par conception, gestion des vulnérabilités, documentation technique, marquage CE) restent entières. Il serait contre-productif d’attendre une hypothétique réduction des exigences pour lancer les travaux de conformité.

Pour une PME ou une ETI qui fabrique, édite ou intègre des produits numériques, le CRA n’est pas un sujet abstrait de mise en conformité réglementaire. C’est un chantier technique et organisationnel concret, avec des échéances fixes et des conséquences réelles en cas de retard.

Voici les étapes structurantes, dans un ordre qui a du sens opérationnellement.

01 : Cartographier les produits concernés

La première question n’est pas « comment se conformer » mais « à quoi ». L’entreprise doit identifier l’ensemble des produits comportant des éléments numériques qu’elle fabrique, édite, importe ou distribue sur le marché européen. Cela inclut les logiciels embarqués dans des équipements physiques, les SDK et bibliothèques commercialisés, les firmwares, les applications distribuées. Un tableur suffit pour commencer : nom du produit, nature (matériel, logiciel, composant), marché cible, rôle de l’entreprise dans la chaîne.

02 : Qualifier son rôle dans la chaîne de valeur

Fabricant, éditeur, importateur, distributeur, intégrateur ou fournisseur de composant : le niveau d’obligation n’est pas le même selon la position dans la chaîne. Une entreprise qui incorpore un composant tiers dans son propre produit devient fabricant du produit final au sens du CRA. Une entreprise qui revend un produit fabriqué hors UE sans le modifier est importateur. Les deux statuts peuvent coexister dans une même organisation selon les gammes de produits.

03 : Classer les produits par catégorie de risque

Le CRA distingue trois catégories : produits standard, importants (classe I et II), critiques. Cette classification détermine le niveau d’évaluation de conformité requis. Pour les produits standard, une auto-évaluation interne suffit. Pour les produits importants, un organisme tiers intervient dans certains cas. Pour les produits critiques, une certification formelle est exigée. La grande majorité des produits d’une PME relève de la catégorie standard. Mais un logiciel de gestion réseau, un système d’accès distant, un hyperviseur ou un gestionnaire de mots de passe tombent dans la catégorie importante, avec des exigences renforcées.

04 : Réaliser une analyse de risques produit

Pour chaque produit concerné, l’entreprise doit documenter les usages prévus, les usages raisonnablement prévisibles, les menaces associées, les vulnérabilités potentielles et leurs impacts. Ce n’est pas une analyse de risques organisationnelle classique : elle porte sur le produit lui-même, ses composants, ses interfaces, ses dépendances. Une PME qui n’a jamais fait cet exercice découvrira souvent qu’une partie significative de son produit repose sur des bibliothèques open source dont personne ne maîtrise vraiment le niveau de maintenance.

05 : Mettre en place un cycle de développement sécurisé

Le CRA exige que la sécurité soit intégrée dès la conception, pas ajoutée après coup. Pour une PME, cela se traduit par des pratiques concrètes dans le cycle de développement : prise en compte des exigences de sécurité dans les spécifications, revues de code orientées sécurité, tests d’intrusion ou de vulnérabilité avant chaque version majeure, gestion des dépendances, politique de release. Ces pratiques n’impliquent pas nécessairement des ressources importantes, mais elles supposent que quelqu’un en soit responsable et que les décisions soient documentées.

06 : Gérer les dépendances et produire un SBOM

Identifier les bibliothèques, frameworks, composants open source, firmwares et modules tiers intégrés dans chaque produit. Pour beaucoup de PME éditrices, c’est le chantier le plus sous-estimé. Un produit logiciel commercial peut embarquer plusieurs centaines de dépendances, dont certaines ne sont plus maintenues activement. Le SBOM (Software Bill of Materials) est la liste structurée de ces composants, avec leurs versions et leurs licences. Il devient l’outil central de la gestion des vulnérabilités : quand une CVE est publiée sur une bibliothèque, l’entreprise doit pouvoir savoir en quelques minutes quels produits elle affecte.

07 : Organiser la gestion des vulnérabilités

Le CRA impose un processus formalisé, pas juste une bonne volonté. Cela implique : un canal de signalement public permettant à des tiers de remonter des vulnérabilités, une procédure interne de triage et de priorisation, des délais de correction documentés, une politique de divulgation coordonnée et un historique des vulnérabilités traitées par produit. Pour une PME, ce dispositif peut être léger, mais il doit exister et être traçable. Un formulaire de contact dédié sur le site web, un responsable identifié et une procédure écrite constituent un point de départ sérieux.

08 : Constituer la documentation technique

La documentation technique CRA est le dossier qui prouve la conformité du produit. Elle comprend : la description du produit et de ses composants, l’analyse de risques, les mesures de sécurité mises en oeuvre, les tests réalisés, la liste des vulnérabilités connues et traitées, les informations sur la durée de support et les mises à jour. Ce dossier doit être conservé pendant dix ans après la mise sur le marché. Pour une PME, la tentation est de traiter cela comme un exercice bureaucratique. C’est une erreur : ce dossier est aussi le support naturel de la réponse en cas de contrôle, de litige ou d’incident grave.

09 : Préparer les notifications à partir du 11 septembre 2026

À partir de cette date, toute vulnérabilité activement exploitée et tout incident grave devront être notifiés à l’ENISA via la plateforme SRP sous 24 heures pour la notification initiale, avec un rapport plus détaillé dans les 72 heures. Pour une PME, cette obligation suppose d’avoir identifié au préalable : qui décide qu’un incident est « grave » au sens du règlement, qui fait la notification, sur quel outil, avec quel contenu. Un exercice de simulation avant septembre 2026 est fortement conseillé.

10 : Adapter les contrats avec les tiers

Le CRA a des implications contractuelles directes sur plusieurs fronts. Les contrats avec les fournisseurs de composants ou de bibliothèques doivent prévoir des engagements de maintenance et de notification des vulnérabilités. Les contrats avec les clients (notamment les distributeurs ou intégrateurs) doivent clarifier les responsabilités en cas de non-conformité. Les contrats de sous-traitance de développement doivent intégrer les exigences de développement sécurisé. Une PME qui n’a jamais revu ses modèles contractuels sous l’angle CRA prend un risque réel : en cas d’incident, la question de qui répond sera la première posée.

11 : Former les équipes concernées

Le CRA n’est pas un sujet réservé aux équipes sécurité ou juridiques. Il touche les développeurs (secure by design, gestion des dépendances), les chefs de produit (classification, durée de support, documentation), les achats (sélection des composants tiers, clauses contractuelles), le support (gestion des signalements de vulnérabilités, information des utilisateurs) et la direction (responsabilité, budgets, arbitrages). Une demi-journée de sensibilisation ciblée par équipe vaut mieux qu’une formation généraliste d’une journée pour tout le monde.

12 : Ordre de priorité pour une PME qui démarre :

Pour une PME / ETI qui démarre, l’ordre est un peui plus réduit : cartographie des produits, qualification du rôle, SBOM et inventaire des dépendances, analyse de risques du produit principal, organisation de la gestion des vulnérabilités. Ces cinq étapes couvrent l’essentiel du risque de non-conformité à court terme et constituent le socle sur lequel tout le reste s’appuie.

Le CRA prévoit un régime gradué selon la nature du manquement.

Type de manquement	Sanction maximale
Non-respect des exigences essentielles de cybersécurité ou mise sur le marché de produits non conformes	15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial (le plus élevé des deux)
Manquements aux obligations des importateurs et distributeurs (documentation, traçabilité, coopération avec les autorités)	10 millions d’euros ou 2 % du CA annuel mondial
Fourniture d’informations inexactes, incomplètes ou trompeuses aux autorités ou aux organismes notifiés	5 millions d’euros ou 1 % du CA annuel mondial

Au-delà des amendes, les risques les plus concrets pour une entreprise sont probablement ailleurs. Le retrait forcé d’un produit du marché européen, l’interdiction de mise à disposition, le rappel de produits déjà distribués : ce sont ces mesures qui produisent les impacts opérationnels et réputationnels les plus immédiats. La publication des sanctions, avec le nom de l’entreprise et la nature du manquement, ajoute une dimension de risque commercial non négligeable.

La responsabilité des dirigeants peut être engagée en cas de non-conformité persistante ou délibérée. C’est un signal clair que le règlement ne vise pas uniquement les organisations : il vise ceux qui décident.

Le CRA est probablement le texte européen qui aura l’impact le plus profond sur la cybersécurité opérationnelle des fabricants et éditeurs. Il ne s’agit plus de recommandations, de bonnes pratiques ou de référentiels volontaires. La cybersécurité des produits devient une exigence réglementaire avec des sanctions, un marquage et une responsabilité documentée.

Concrètement, le CRA donne une valeur juridique à des pratiques que les équipes sécurité réclament depuis des années dans leurs organisations : développement sécurisé, inventaire des composants logiciels, gestion des vulnérabilités, mises à jour fiables, documentation technique et sécurité par défaut. Beaucoup d’entreprises avaient ces exigences dans leurs politiques internes sans jamais les appliquer faute de contrainte externe. Le CRA constitue cette contrainte.

Pour une PME ou une ETI fabricant des produits numériques, le CRA n’est pas uniquement un sujet juridique ou de conformité. C’est un sujet produit, développement, achats, support, contrats et responsabilité. Il touche les équipes qui conçoivent, celles qui maintiennent, celles qui vendent et celles qui achètent des composants tiers. Si votre organisation est aussi soumise à NIS2, à DORA ou à l’AI Act, la conformité CRA s’intègre dans un effort plus large qu’il est utile de piloter de façon coordonnée. La politique de sécurité des systèmes d’information (PSSI) de votre organisation est le bon endroit pour ancrer cet effort.

À partir du 11 décembre 2027, vendre un produit numérique vulnérable, mal maintenu ou insuffisamment documenté sur le marché européen ne sera plus seulement une faiblesse technique. Ce sera un risque réglementaire mesurable, avec des amendes, des retraits de marché et une responsabilité de direction engagée. Les entreprises qui auront traité ce sujet en amont auront un avantage concurrentiel réel sur celles qui l’auront négligé.

Où en êtes-vous sur le CRA ?

Le CRA change la façon dont les produits numériques doivent être conçus, documentés et maintenus. Si vous fabriquez, éditez, importez ou distribuez des produits comportant des éléments numériques dans l’UE, la question n’est pas de savoir si vous êtes concerné. C’est de savoir à quel stade vous en êtes.

Radical-SSI vous accompagne sur :

La cartographie de vos produits numériques et la qualification de votre rôle au sens du CRA ;
L’analyse de risques produit et l’évaluation des écarts avec les exigences essentielles ;
La mise en place d’un processus de développement sécurisé (secure by design, secure by default) ;
La gestion des vulnérabilités : canal de signalement, procédures de triage et de correction, politique de divulgation ;
La constitution de la documentation technique et la préparation à l’évaluation de conformité ;
La préparation au reporting incidents à partir du 11 septembre 2026 ;
L’adaptation des contrats fournisseurs, éditeurs, intégrateurs et distributeurs ;
L’articulation CRA avec NIS2, DORA, AI Act, RGPD et le Digital Omnibus.

Prenons rendez-vous pour une consultation sans engagement.

Partagez cette page via :

Cyber Resilience Act Règlement – Règlement sur la cyber résilience