Le Cyber Resilience Act de l'UE

Le CRA couvre le matériel et les logiciels dont l'utilisation prévue comprend une connexion de données directe ou indirecte à un appareil ou à un réseau – y compris les composants mis sur le marché séparément. Les obligations pèsent en premier lieu sur les fabricants dès qu'un produit est mis à disposition sur le marché de l'UE ; les importateurs et les distributeurs sont soumis à des obligations graduées de vérification et de coopération. Sont exclus les domaines de produits régis par des réglementations sectorielles propres – notamment les dispositifs médicaux, les véhicules à moteur, l'aviation et le transport maritime – ainsi que les logiciels libres et open source en dehors d'une activité commerciale.

Le règlement classe les produits selon leur niveau de risque : la grande majorité relève des produits standard et fait l'objet d'une auto-évaluation par le fabricant. Les produits importants au sens de l'annexe III sont répartis entre la classe I (19 catégories, dont les gestionnaires de mots de passe, les navigateurs, les produits VPN, les systèmes d'exploitation, les routeurs et les systèmes SIEM) et la classe II (4 catégories : hyperviseurs et environnements d'exécution de conteneurs, pare-feu et systèmes de détection/prévention d'intrusion, ainsi que microprocesseurs et microcontrôleurs résistants à la manipulation). Pour les produits critiques au sens de l'annexe IV – notamment les passerelles de compteurs intelligents ainsi que les cartes à puce et les éléments sécurisés – une certification européenne de cybersécurité obligatoire peut être imposée. Le règlement d'exécution (UE) 2025/2392 du 28 novembre 2025 précise les descriptions techniques des catégories ; la fonctionnalité principale du produit est déterminante pour la classification.

L'annexe I définit les exigences essentielles de cybersécurité en deux parties. La partie I concerne les propriétés du produit : les produits doivent être développés sur la base d'une évaluation des risques, mis à disposition sans vulnérabilités exploitables connues et livrés avec une configuration sécurisée par défaut ; les vulnérabilités doivent être corrigées par des mises à jour de sécurité – installables automatiquement par défaut, avec possibilité de refus (opt-out). La partie II exige des processus de gestion des vulnérabilités : une nomenclature logicielle (SBOM) dans un format courant et lisible par machine couvrant au moins les dépendances de premier niveau, une politique de divulgation coordonnée, un point de contact pour les signalements de vulnérabilités, ainsi que des tests réguliers et la diffusion sans délai et gratuite des mises à jour de sécurité. Le CRA n'exige pas la publication de la SBOM ; comme aide pratique de démarrage, la directive technique BSI TR-03183 précise notamment les contenus et formats de SBOM.

À partir du 11 septembre 2026, les fabricants devront notifier les vulnérabilités activement exploitées ainsi que les incidents graves ayant un impact sur la sécurité du produit – simultanément au CSIRT désigné comme coordinateur et à l'ENISA via la plateforme unique de notification prévue à l'art. 16. Une procédure en trois étapes s'applique : alerte précoce dans les 24 heures suivant la prise de connaissance, notification détaillée dans les 72 heures, rapport final au plus tard 14 jours après la disponibilité d'une mesure corrective ou d'atténuation pour les vulnérabilités, et un mois après la notification de l'incident pour les incidents. Ces délais supposent des processus de détection, d'évaluation et de notification préparés à l'avance – en particulier la capacité d'établir de manière fiable une exploitation active.

Selon la classe, la preuve de conformité s'effectue par le contrôle interne (module A), l'examen UE de type suivi du contrôle de la production (modules B et C), une assurance qualité complète (module H) ou un schéma européen de certification de cybersécurité (art. 32). Les produits importants de classe I ne peuvent être déclarés conformes par auto-évaluation que si les normes harmonisées ou schémas pertinents sont appliqués dans leur intégralité ; pour la classe II, l'intervention d'un organisme notifié est obligatoire. À partir du 11 décembre 2027, les produits comportant des éléments numériques ne pourront être mis sur le marché de l'UE qu'avec le marquage CE (art. 29–30), qui attestera alors également la conformité au CRA – à démontrer par la déclaration UE de conformité et la documentation technique. En cas de violation des exigences de l'annexe I ou des obligations des art. 13 et 14, des amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial sont encourues, et jusqu'à 10 millions d'euros ou 2 % pour les autres manquements (art. 64).

Les fabricants doivent déterminer une période d'assistance pendant laquelle les vulnérabilités sont traitées efficacement ; elle est en principe d'au moins cinq ans (art. 13). Une fois mises à disposition, les mises à jour de sécurité doivent rester disponibles pendant au moins dix ans après leur publication ou pour le reste de la période d'assistance – la durée la plus longue étant retenue – et doivent être proposées gratuitement pendant la période d'assistance. Le CRA déplace ainsi l'attention d'un contrôle de conformité ponctuel vers des processus exploités en continu : développement sécurisé, gestion des vulnérabilités et des correctifs, et documentation permanente. Depuis le 11 juin 2026 s'appliquent en outre les dispositions relatives à la notification des organismes d'évaluation de la conformité (chapitre IV), et la Commission européenne a publié en juillet 2026 des lignes directrices pratiques pour la mise en œuvre.

Depuis le 30 juillet 2026, l'ENISA propose avec le « Secure by Design and Default Playbook » (v1.0) une aide gratuite à la mise en œuvre visant précisément les obligations des fabricants prévues à l'annexe I du CRA : 22 principes – des trust boundaries à l'accès initial restrictif jusqu'aux mises à jour automatiques – chacun sous forme de playbook d'une page avec check-list, preuves minimales et release gate pour la chaîne CI/CD. L'annexe C du document rattache chaque principe de manière indicative aux exigences essentielles du CRA ; cela ne crée pas de preuve de conformité, mais constitue un pont d'ingénierie solide du règlement vers la pratique de développement – avec un concept de preuves de sécurité lisibles par machine. Sous licence CC BY 4.0, disponible en PDF et dépôt GitHub.