Publications

Catégories

NIS2 Actualité Pratiques

Vous connaissez certainement la directive NIS 2, et si vous êtes déjà concerné vous avez même peut être déjà avancé sur la mise en œuvre. Notez que si vous pensez attendre, ce n'est pas forcément une bonne idée d'ailleurs

Mais oublions NIS 2 pour le moment : le sujet d'aujourd'hui est un autre règlement : le Cyber Resilience Act, référencé (EU) 2024/2847.

A partir de cet instant, on va parler de CRA, puisqu'on est entre nous.

L'histoire du CRA remonte à 2022, quand les états membres ont commencé à se pencher sur la meilleure manière de sécuriser les produits "comportant des composants numériques".

Objectif : garantir la sécurité, la transparence et la confiance des utilisateurs. Parce qu'il n'est plus tolérable de voir des produits faire tourner du code sans la moindre prise en compte de la cybersécurité.

Ces travaux ont donné lieu à la publication du règlement CRA le 23 octobre 2024. Notez qu'on parle bien d'un règlement. La nuance avec une directive est que le règlement est d'application immédiate dans l'intégralité des états membres sans donner lieu à une transposition locale.

En résumé, le CRA s'impose dès maintenant, avec des contrôles dès 2026 !

Applicabilité du CRA

Le CRA s’applique aux « produits comportant des éléments numériques » mis à disposition sur le marché UE, dont l’usage prévu (ou raisonnablement prévisible) implique une connexion logique ou physique à un appareil ou à un réseau. Il couvre aussi les solutions de traitement de données à distance fournies par le fabricant lorsqu’elles sont nécessaires au fonctionnement du produit (ex. fonctions cloud d’un objet connecté).

C'est encore un peu vague ? Prenons quelques exemples :

Objet	Assujetti Oui / Non	Pourquoi
Smartphone	Oui	Système d’exploitation + connexion internet + MAJ nécessaires
Logiciel commercial	Oui	Distribué sur le marché, doit être maintenu et sécurisé
Serrure connectée	Oui	Sécurité physique dépendant d’un accès numérique
Voiture connectée	Non	Déjà couverte par réglementation automobile
Dispositif médical connecté	Non	Déjà réglementé par le MDR (Medical Device Regulation)
Logiciel Open Source gratuit	Non	Pas d’activité commerciale
Logiciel Open Source avec version commerciale	Oui	Exigences allégées
Machine à laver connectée	Oui	Traitement des données, se connecte à un smartphone
Machine à laver non connectée	Non

A ce stade, vous devriez commencer à savoir si vos produits sont concernés ou pas.

Les implications du CRA

Le CRA impose un certain nombre d'exigences qui vont nécessiter un travail de fond plus ou moins important, selon votre maturité sur le sujet.

Exigences « produit » (Annexe I – Partie I)

Les produits doivent, entre autres, être sécurisés par conception et par défaut, protéger confidentialité–intégrité–disponibilité, limiter la surface d’attaque, journaliser les événements pertinents, permettre l’effacement sécurisé des données, et maintenir les fonctions essentielles même après incident.

Gestion des vulnérabilités (Annexe I – Partie II)

Le fabricant doit inventorier les composants et documenter les vulnérabilités, y compris via une SBOM (au minimum les dépendances de premier niveau) dans un format lisible par machine.

Le fabricant doit tester régulièrement la sécurité, publier des informations sur les vulnérabilités une fois corrigées, mettre en place une politique de divulgation coordonnée, et distribuer des mises à jour de sécurité, automatiquement quand c’est techniquement possible.

Période de support & mise à jour

Le fabricant doit définir une « période de support » proportionnée, au moins 5 ans (ou la durée d’usage prévue si <5 ans), et maintenir accessibles les mises à jour de sécurité ≥10 ans (ou pendant la période de support si plus longue).
L’échéance de support (mois/année) doit être communiquée au moment de l’achat.

Information à l’utilisateur, marquage et documentation

Fournir un point de contact vulnérabilités et des instructions (installation sécurisée, MAJ, fin de vie).
Préparer la déclaration UE de conformité et le marquage CE, avec dossier technique (incluant SBOM, politique CVD, analyses de risque, etc.)

Notification à ENISA / CSIRT (Article 14)

À compter de l’application de l’art. 14 (voir le calendrier plus loin) :

Vulnérabilité activement exploitée : Alerte précoce < 24 h après découverte. Notification détaillée < 72 h. Rapport final ≤ 14 jours après la mise à disposition d’une mesure corrective.
Incident grave affectant la sécurité du produit : Alerte précoce < 24 h. Notification d’incident < 72 h. Rapport final ≤ 1 mois. Notifications via la plateforme unique gérée par ENISA ; information aux utilisateurs « en temps utile ».

Classes de produits & évaluation de conformité

Produits « importants » (Annexe III) – ex. OS, routeurs, VPN, SIEM, gestion d’identités, pare-feu/IDS/IPS (classe II), etc. Les classes I/II impliquent des modules d’évaluation plus stricts (jusqu’à organisme notifié).
Produits « critiques » (Annexe IV) – ex. HSM, smartcards/secure elements, smart meter gateways : certification européenne possible/exigée à un niveau d’assurance au moins “substantiel” si un schéma existe.

On le voit, il y aura pas mal d'efforts à faire pour une prise en compte de l'ensemble des exigences, comme dans beaucoup de projets de conformité.

Et donc un véritable besoin d'anticipation pour coller au calendrier et ne pas devoir tout faire dans l'urgence (qui dit urgence, dit inconfort et hausse des coûts).

Et justement, parlons du calendrier :

Fin 2025, publication des premiers documents d'harmonisation.
11 juin 2026 : application du Chapitre IV (mise en place et notification des organismes d’évaluation de conformité). A ce jour ce point reste à mettre en place, en France.

11 sept. 2026 : application de l’Article 14 (obligations de reporting vulnérabilités/incidents via ENISA)

11 déc. 2027 : application générale du CRA (exigences produit, CVD, SBOM, CE, etc.).

Produits déjà sur le marché avant le 11 déc. 2027 : restent hors champ sauf en cas de modification substantielle (mais les obligations de l’art. 14 s’appliquent à eux aussi à partir du 11 sept. 2026).

En gros, la date la plus importante est celle du 11 septembre 2026. Car à cette date, vous devez être en mesure de pouvoir effectuer les signalements des vulnérabilités et incidents selon les contraintes données plus haut.

Et ça ne s'improvise pas. Parce que pour cela il faut une procédure en place, mais aussi (et surtout) pouvoir disposer des capacités de détection associées.

Pour vous donner une idée des implications, voici une "petite" check list ...

Les actions à anticiper :

Nommer un sponsor & un pilote CRA (produits, juridique, cyber, qualité).

Cartographier le portefeuille (hardware, software, services « à distance » du fabricant) et classer vis-à-vis des annexes III/IV.

Mesurer l'écart entre les pratiques actuelles et l'Annexe I : CIA, surface d’attaque, journaux, effacement, mises à jour, etc.

Définir la période de support (≥5 ans en principe) et le plan de patch management (y compris accessibilité des MAJ ≥10 ans).

Mettre en place une politique CVD publique, un PSIRT, une adresse de contact, et simuler la chaîne de report (24 h / 72 h / 14 j / 1 mois) vers ENISA/CSIRT.

Générer une SBOM (formats SPDX ou CycloneDX) au minimum des dépendances de premier niveau et l’intégrer à la doc technique.

Préparer la documentation : Dossier technique (Annexe VII), Déclaration UE (Annexe V), Informations utilisateur (Annexe II), marquage CE.

Surveiller les normes harmonisées & schémas de certification EUCC pour bénéficier de présomptions de conformité.

Planifier l’évaluation : si produit en classe II ou critique, anticiper l’organisme notifié (capacité limitée), conformément aux exigences de notification d’ici septembre 2026. A noter, les organismes ne sont pas encore connus pour le moment, ce qui n'empêche pas de commencer ...

Former les équipes produit/DevSecOps/Support sur les exigences et le calendrier ; aligner avec NIS2 et RGPD pour éviter les doublons de notification.

En bref, si vous vous demandez quand commencer, j'ai une réponse extrêmement claire : maintenant ! Parce que même sans les fameux documents d'harmonisation, il y a déjà beaucoup de choses qui relèvent du bon sens (disposer d'une SBOM par exemple, mais pas seulement).

Les bénéfices à se mettre en conformité

Accès plus simple au marché UE via un cadre unique (fin des exigences nationales variables selon les pays).

Réduction du risque (incidents, rappels, litiges), coûts de cycle de vie mieux maîtrisés grâce aux MAJ structurées.

Avantage concurrentiel (période de support claire, sécurité démontrée), meilleure prise en compte dans les achats publics/privé.

Ne négligez pas un aspect important : comme souvent, ce sont les partenaires qui vont rapidement vous demander où vous en êtes.

Et ils risquent de ne pas attendre la fin d'année 2026 !

En conclusion

J'ai pratiqué le développement de logiciel sur des matériels divers et pratiqué l'informatique embarquée pendant plus d'une décennie.

Je connais les contraintes associées et je suis conscient que, pour beaucoup de structures, la mise en conformité va demander un effort parfois significatif.

Mais en tant que consommateur, je suis aussi rassuré de voir que, ENFIN, cet aspect longtemps négligé de la cybersécurité va prendre de l'importance.

Si vous avez besoin d'éclaircissements sur ce sujet, n'hésitez pas à me contacter !