Le Cyber Resilience Act européen entre dans sa phase critique

De la législation à l’application : le calendrier du CRA

Après des années de rédaction, de négociation et de compromis politiques, le Cyber Resilience Act de l’Union européenne (Règlement (UE) 2024/2847) passe du papier à la pratique. Le règlement — qui établit les premières exigences de cybersécurité complètes pour tous les produits matériels et logiciels comportant des « éléments numériques » vendus sur le marché de l’UE — est entré en vigueur le 10 décembre 2024. Mais 2026 est l’année où ses dispositions les plus conséquentes commencent à s’activer.

Le CRA fonctionne selon un calendrier de mise en œuvre échelonné conçu pour laisser aux fabricants et éditeurs de logiciels le temps de s’adapter. Mais le rythme de ces échéances a pris de nombreuses organisations au dépourvu, et les exigences de conformité sont plus exigeantes que les lectures initiales ne le suggéraient.

Trois jalons critiques définissent 2026 et 2027. Le 11 juin 2026, le cadre de notification des organismes d’évaluation de la conformité prend effet — ce qui signifie que les États membres de l’UE doivent désigner les autorités notifiantes responsables de l’évaluation, de la désignation et de la notification des organismes qui évalueront la conformité des produits. Le 11 septembre 2026, l’obligation pour les fabricants de signaler les vulnérabilités activement exploitées et les incidents de sécurité graves prend effet via la plateforme de signalement unique (Single Reporting Platform) de l’ENISA, introduisant des délais de notification serrés qui mettront à l’épreuve la préparation des organisations. Et le 11 décembre 2027, les obligations principales — y compris les exigences complètes d’évaluation de la conformité — s’appliquent, après quoi les produits non conformes ne pourront plus être mis sur le marché de l’UE.

Ce que couvre le CRA — et qui est concerné

La portée du CRA est délibérément large. Il s’applique aux « produits comportant des éléments numériques » — définis comme tout produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels destinés à être mis sur le marché séparément. Cela englobe tout, des appareils IoT grand public et systèmes d’exploitation aux systèmes de contrôle industriel et plateformes logicielles d’entreprise.

Le règlement divise les produits en trois catégories selon le risque. La catégorie par défaut couvre environ 90 % des produits et permet aux fabricants d’auto-évaluer leur conformité. Les produits « importants » sont divisés en deux classes : la classe I comprend les systèmes de gestion d’identité, les gestionnaires de mots de passe, les VPN, les outils de gestion réseau, les routeurs et les assistants virtuels de maison intelligente ; la classe II couvre les pare-feu, les systèmes de détection et de prévention d’intrusion, les microprocesseurs résistants à la manipulation et les systèmes d’exploitation — tous nécessitant une évaluation de conformité par un tiers ou l’application de normes harmonisées. Les produits « critiques » — modules de sécurité matériels, passerelles de compteurs intelligents, éléments sécurisés et cartes à puce — font face aux exigences d’évaluation les plus strictes, incluant une évaluation obligatoire par un organisme notifié tiers.

Le règlement s’applique aux fabricants, importateurs et distributeurs, créant des obligations tout au long de la chaîne d’approvisionnement. Les fabricants supportent la charge principale de conformité, mais les importateurs et distributeurs doivent vérifier que les produits qu’ils mettent sur le marché répondent aux exigences du CRA, créant effectivement une chaîne de responsabilité qui s’étend du développeur original au point de vente.

Point crucial, le CRA s’applique à toute entreprise qui met des produits sur le marché de l’UE, indépendamment de l’endroit où l’entreprise a son siège. Cela confère au règlement une portée mondiale — une entreprise de logiciels aux États-Unis, en Inde ou en Chine qui vend des produits à des clients de l’UE doit se conformer ou se retirer du marché.

Le mandat de signalement des vulnérabilités

L’exigence peut-être la plus difficile sur le plan opérationnel est le régime de signalement obligatoire des vulnérabilités et incidents du CRA, qui s’active le 11 septembre 2026.

Les fabricants doivent signaler les vulnérabilités activement exploitées à l’équipe nationale de réponse aux incidents de sécurité informatique (CSIRT) désignée et à l’Agence de l’Union européenne pour la cybersécurité (ENISA) via une nouvelle plateforme de signalement unique, dans des délais agressifs. La structure de signalement suit un processus en plusieurs étapes.

La première étape exige une « alerte précoce » dans les 24 heures suivant la prise de connaissance qu’une vulnérabilité d’un produit est activement exploitée. Cette alerte précoce doit inclure des informations de base sur la vulnérabilité, le produit affecté et la nature de l’exploitation. Le délai de 24 heures commence à partir de la prise de connaissance, et non de la confirmation — ce qui signifie que les organisations ne peuvent pas retarder en menant une investigation interne prolongée avant de signaler.

La deuxième étape exige une notification de vulnérabilité complète dans les 72 heures. Celle-ci doit inclure une évaluation technique détaillée de la vulnérabilité, des informations sur la gravité et l’impact potentiel, une évaluation de l’impact sur les utilisateurs de l’UE, et des informations préliminaires sur les mesures d’atténuation.

La troisième étape exige un rapport final au plus tard 14 jours après la disponibilité d’une mesure corrective ou d’une mise à jour de sécurité. Celui-ci doit fournir une analyse complète de la vulnérabilité, la cause racine, tout schéma d’exploitation observé, les mesures correctives prises et une évaluation du risque résiduel.

Pour les incidents de sécurité graves — distincts des vulnérabilités individuelles — un régime de notification parallèle s’applique avec les mêmes fenêtres initiales de 24 et 72 heures, mais le délai du rapport final s’étend à un mois après la notification initiale.

Ce cadre de signalement crée plusieurs défis pratiques. Les organisations doivent disposer de processus internes capables de détecter l’exploitation active en quelques heures — pas en jours ou semaines. Elles ont besoin de canaux de communication avec les CSIRT nationaux et l’ENISA activables rapidement. Elles doivent être en mesure de produire des évaluations techniques détaillées des vulnérabilités sous pression temporelle. Et l’obligation de signalement s’applique à tous les produits comportant des éléments numériques déjà sur le marché de l’UE, indépendamment de leur date de mise sur le marché.

Évaluation de conformité et course aux normes

Les exigences d’évaluation de conformité établissent les normes de cybersécurité substantielles que les produits doivent respecter avant de pouvoir porter le marquage CE et être mis sur le marché de l’UE. La pleine conformité est requise d’ici le 11 décembre 2027.

Au cœur du CRA, les exigences essentielles imposent que les produits soient conçus et développés avec la sécurité comme paramètre par défaut. Cela inclut des exigences de configuration sécurisée par défaut, de contrôles d’accès authentifiés et autorisés, de protection de la confidentialité et de l’intégrité des données, de minimisation de la surface d’attaque, et de la capacité à recevoir et installer des mises à jour de sécurité.

Pour la catégorie de produits par défaut, les fabricants peuvent auto-évaluer leur conformité en appliquant des normes harmonisées — une fois ces normes publiées. Le 3 février 2025, la Commission européenne a officiellement demandé aux trois organisations européennes de normalisation (CEN, CENELEC et ETSI) de développer 41 normes harmonisées dans le cadre du CRA : 15 normes horizontales alignées sur les exigences essentielles de cybersécurité (échéance : 30 août 2026) et 26 normes verticales adaptées à des catégories de produits spécifiques (échéance : 30 octobre 2026). Les premières normes harmonisées finalisées sont attendues au troisième trimestre 2026, et après citation au Journal officiel de l’UE, les fabricants pourront les utiliser pour les évaluations de conformité afin de bénéficier d’une présomption de conformité.

Sans normes harmonisées finalisées, les fabricants font face à une incertitude quant à la manière exacte de démontrer la conformité, et le recours à l’évaluation interne augmente à la fois les coûts et les risques.

Pour les produits « importants » et « critiques », l’évaluation par un tiers introduit une couche supplémentaire de complexité et de coût. La disponibilité d’organismes notifiés qualifiés pour mener ces évaluations est un goulot d’étranglement que la Commission a reconnu. L’échéance du 11 juin 2026 — date à laquelle les États membres doivent avoir désigné les autorités notifiantes et établi des procédures d’évaluation des organismes d’évaluation de la conformité — est la condition préalable critique au fonctionnement de l’ensemble du dispositif. Les organisations qui tardent à s’engager avec les organismes notifiés risquent de se trouver dans l’incapacité de terminer les évaluations avant l’échéance de décembre 2027.

L’évaluation de conformité exige également des fabricants qu’ils maintiennent une documentation technique, conduisent des évaluations de risque de cybersécurité, et établissent des procédures de traitement des vulnérabilités tout au long du cycle de vie du produit — y compris la fourniture de mises à jour de sécurité pendant la durée de vie attendue du produit ou pendant une période de cinq ans à compter de la mise sur le marché, selon la durée la plus courte. Les fabricants doivent déterminer et communiquer cette « période de support » aux clients.

Intersection avec NIS2 et le paysage réglementaire plus large

Le CRA ne fonctionne pas isolément. Il fait partie d’une architecture réglementaire européenne plus large en matière de cybersécurité qui comprend la Directive sur la sécurité des réseaux et des systèmes d’information 2 (NIS2), le Digital Operational Resilience Act (DORA) pour le secteur financier, et diverses réglementations sectorielles pour les dispositifs médicaux, l’automobile et l’aviation.

L’interaction entre le CRA et NIS2 est particulièrement significative. NIS2, que les États membres de l’UE devaient transposer en droit national d’ici le 17 octobre 2024, impose des obligations de cybersécurité aux entités « essentielles » et « importantes » — opérateurs d’infrastructures critiques, fournisseurs de services numériques et entreprises manufacturières au-delà de certains seuils de taille. Cependant, le processus de transposition a connu des retards importants : seuls quatre États membres ont respecté l’échéance, et la Commission européenne a ouvert des procédures d’infraction contre 23 États membres en novembre 2024. Les organisations soumises à la fois à NIS2 et au CRA font face à des exigences qui se chevauchent mais ne sont pas identiques en matière de gestion des risques, de signalement des incidents et de sécurité de la chaîne d’approvisionnement.

En janvier 2026, la Commission européenne a présenté un nouveau paquet de cybersécurité de l’UE incluant des amendements ciblés à la directive NIS2 ainsi qu’une proposition de refonte du Cybersecurity Act (CSA2). Le paquet vise à simplifier la conformité à travers les cadres de cybersécurité qui se chevauchent, à rationaliser le signalement via un point d’entrée unique proposé dans l’initiative Digital Omnibus, et à faciliter la supervision transfrontalière avec un rôle de coordination renforcé pour l’ENISA. Dans le cadre de l’alignement proposé NIS2-CSA2, les certifications de cybersécurité de l’UE pourraient être utilisées pour démontrer la conformité aux obligations de gestion des risques de NIS2, éliminant les audits de sécurité redondants. Les deux propositions entrent maintenant en négociations en trilogue avec un accord politique visé pour début 2027.

Les implications mondiales s’étendent au-delà de l’UE. Les exigences de sécurité des produits du CRA sont susceptibles de devenir des normes mondiales de facto, car les fabricants trouvent plus efficace d’intégrer la sécurité dans les produits une seule fois plutôt que de maintenir des gammes de produits séparées conformes et non conformes à l’UE. Cet « effet Bruxelles » — où la réglementation de l’UE façonne les pratiques mondiales du marché — a déjà été observé avec le RGPD et devrait se répéter avec le CRA.

Défis de conformité et réponse de l’industrie

La transition de la législation CRA à la conformité CRA s’avère plus difficile que beaucoup d’organisations ne l’avaient anticipé.

L’exigence SBOM

L’une des exigences les plus discutées est l’obligation pour les fabricants de produire et maintenir une nomenclature logicielle (Software Bill of Materials, SBOM) pour leurs produits. Le SBOM doit être dans un format couramment utilisé et lisible par machine, et doit identifier au minimum les dépendances de premier niveau du produit, y compris les numéros de version et les informations de licence. Bien que le CRA n’exige pas des fabricants qu’ils rendent le SBOM public, ils doivent l’inclure dans la documentation technique du produit et le fournir aux autorités de surveillance du marché sur demande. Pour les produits logiciels complexes comportant des centaines ou des milliers de dépendances, la mise en œuvre pratique nécessite un outillage, des processus et une expertise que beaucoup d’organisations ne possèdent pas encore.

Les complications de l’open source

Le traitement des logiciels open source par le CRA a été un point de contentieux depuis la première proposition du règlement. Le texte final exempte les logiciels libres et open source qui ne sont pas mis sur le marché dans le cadre d’une activité commerciale. Cependant, la frontière entre activité commerciale et non commerciale est définie de manière large : fournir une plateforme logicielle par laquelle le fabricant monétise d’autres services, facturer le support technique, ou utiliser des données personnelles à des fins dépassant l’amélioration de la sécurité, de la compatibilité ou de l’interopérabilité du logiciel peuvent tous constituer une activité commerciale.

Le règlement introduit une nouvelle catégorie juridique de « responsable de logiciel open source » (open-source software steward) — des organisations qui fournissent systématiquement un soutien durable au développement de logiciels libres et open source spécifiques destinés à des activités commerciales et assurent la viabilité de ces produits logiciels. Les responsables font face à des obligations plus légères que les fabricants commerciaux — ils ne sont pas soumis à des amendes administratives et leurs obligations commencent en décembre 2027 — mais doivent néanmoins mettre en œuvre des politiques de cybersécurité, coopérer avec les autorités de surveillance du marché et participer au signalement des vulnérabilités.

Un rapport de recherche de la Linux Foundation a constaté que beaucoup dans la communauté open source restent peu informés ou incertains concernant les exigences du CRA, soulevant des préoccupations sur la préparation à travers la chaîne d’approvisionnement logicielle plus large.

Responsabilité de la chaîne d’approvisionnement

Les dispositions du CRA relatives à la chaîne d’approvisionnement exigent des fabricants qu’ils exercent une diligence raisonnable sur les composants tiers, y compris les bibliothèques open source. Cela crée une chaîne de responsabilité en cascade où une vulnérabilité dans une dépendance profondément imbriquée peut déclencher des obligations de conformité pour chaque produit qui l’incorpore. La gestion de cette responsabilité nécessite un suivi robuste des dépendances, une surveillance des vulnérabilités et des processus de propagation des mises à jour qui transcendent les frontières organisationnelles.

Lacunes en ressources et expertise

Pour les petites et moyennes entreprises, les exigences du CRA représentent une charge de conformité significative. Les coûts de l’évaluation de conformité, de la maintenance des SBOM, de la gestion des vulnérabilités et de l’infrastructure de signalement des incidents peuvent être prohibitifs pour les plus petites entreprises de logiciels et les fabricants de matériel. La Commission a reconnu cette préoccupation et inclus des dispositions pour des procédures simplifiées et des mesures de soutien pour les PME, mais l’efficacité pratique de ces mesures reste à démontrer.

Préparer la conformité : un cadre pratique

Les organisations qui n’ont pas encore commencé la préparation à la conformité CRA sont déjà en retard. Une approche pratique comprend plusieurs priorités.

Premièrement, réaliser un inventaire des produits pour identifier tous les produits comportant des éléments numériques mis sur le marché de l’UE, et classifier chaque produit par catégorie de risque (par défaut, important classe I/II, ou critique). Deuxièmement, effectuer une analyse des écarts par rapport aux exigences essentielles du CRA pour identifier les domaines où les pratiques actuelles de sécurité des produits sont insuffisantes. Troisièmement, établir ou renforcer les processus de gestion des vulnérabilités pour respecter les délais de signalement de septembre 2026 — cela signifie non seulement une capacité technique mais aussi des procédures organisationnelles, des contacts désignés et des modèles de communication compatibles avec la plateforme de signalement unique de l’ENISA. Quatrièmement, investir dans l’outillage et les processus SBOM pour tous les produits concernés, en assurant des formats lisibles par machine et un suivi automatisé des dépendances. Cinquièmement, s’engager tôt avec les organismes notifiés si une évaluation de conformité par un tiers est requise — l’échéance de décembre 2027 pour la pleine conformité laisse moins de marge qu’il n’y paraît.

Le CRA représente la réglementation de cybersécurité des produits la plus significative de l’histoire, et son impact s’étendra bien au-delà des frontières de l’UE. Les organisations qui investissent dans la conformité dès maintenant se trouveront mieux positionnées — non seulement pour la conformité réglementaire, mais pour la réalité du marché où la sécurité des produits devient un différenciateur concurrentiel et une attente des clients.

Sources et lectures complémentaires

• Regulation (EU) 2024/2847 — Cyber Resilience Act Summary — European Commission
• CRA Reporting Obligations and Single Reporting Platform — ENISA
• EU Cyber Resilience Act: Key 2026 Milestones Toward CRA Compliance — Hogan Lovells
• CRA and Open Source: What Developers Need to Know — Linux Foundation
• European Commission Proposes NIS2 Simplification and Cybersecurity Act 2 — Global Policy Watch
• SBOM Requirements in the EU’s Cyber Resilience Act — FOSSA