CRA et RGPD : quand cybersécurité produit rencontre protection des données

Le Cyber Résilience Act (CRA) et le RGPD opèrent sur des plans distincts – le premier vise la sécurité des produits numériques, le second la protection des données personnelles. Pourtant, des qu’un produit comportant des éléments numériques traité des données à caractère personnel, ces deux réglementations se recoupent de manière significative. Ignorer cette intersection expose à un double risque de non-conformité. Voyons en détail comment ces deux textes s’articulent et comment mettre en place une stratégie de conformité unifiée.

I. Security by design et privacy by design : une convergence structurelle

A. L’exigence de sécurité des la conception dans le CRA

Le CRA impose aux fabricants de produits comportant des éléments numériques de concevoir leurs produits selon le principe de sécurité par défaut et des la conception (security by design and by default). L’annexe I du règlement détaillé les exigences essentielles de cybersécurité : absence de vulnérabilités connues exploitables, surface d’attaque minimale, protection de la confidentialité et de l’intégrité des données stockées et transmises, ou encore minimisation des données collectées au strict nécessaire au fonctionnement du produit.

Ce dernier point est particulièrement révélateur : le CRA reprend, en matière de cybersécurité produit, un principe fondamental du droit de la protection des données.

B. L’article 25 du RGPD : la protection des données des la conception

L’article 25 du RGPD impose au responsable de traitement de mettre en oeuvre, tant au moment de la détermination des moyens du traitement qu’au moment du traitement lui-même, des mesures techniques et organisationnelles appropriées – comme la pseudonymisation – destinées a appliquer les principes de protection des données de manière effective. Le paragraphe 2 de ce même article impose que, par défaut, seules les données nécessaires à chaque finalité spécifique soient traitées.

La convergence avec le CRA est frappante. Un fabricant qui concoit un objet connecté en appliquant les exigences de l’annexe I du CRA – minimisation des données, protection de la confidentialité, chiffrement des transmissions – satisfait simultanément une partie substantielle des obligations de privacy by design du RGPD. Inversement, un produit conçu dans le respect de l’article 25 du RGPD aura déjà intègre des briques de sécurité que le CRA exigé.

C. L’article 32 du RGPD : la sécurité du traitement

L’article 32 du RGPD obligé les responsables de traitement et les sous-traitants à mettre en oeuvre des mesures techniques et organisationnelles appropriées pour garantir un niveau de sécurité adapté au risque. Le texte cite expressément le chiffrement, la pseudonymisation, la capacité a garantir la disponibilité et la résilience des systèmes, et les procédures de test et d’évaluation régulières.

Ces exigences font echo aux obligations du CRA en matière de gestion des vulnérabilités et de mises à jour de sécurité. Un produit conforme au CRA – c’est-à-dire correctement maintenu, dont les vulnérabilités sont corrigées sans délai et dont les mises à jour de sécurité sont fournies gratuitement – contribue directement à la conformité de son exploitant aux exigences de l’article 32. Dit autrement : la conformité CRA du fabricant alimente la conformité RGPD de l’utilisateur professionnel.

II. Signalement des vulnérabilités et notification de violation : deux régimes, un même incident

A. Le signalement CRA : 24 heures à l’ENISA

Le CRA impose aux fabricants de signaler à l’ENISA, dans un délai de 24 heures, toute vulnérabilité activement exploitée dans leurs produits, ainsi que tout incident grave ayant un impact sur la sécurité du produit. Le régime détaillé de signalement des vulnérabilités sous le CRA prévoit ensuite une notification complète dans les 72 heures, suivie d’un rapport final dans les 14 jours.

B. La notification RGPD : 72 heures à l’autorité de contrôle

Les articles 33 et 34 du RGPD imposent au responsable de traitement de notifier à l’autorité de contrôle (la CNIL en France) toute violation de données à caractère personnel dans les 72 heures suivant la prise de connaissance de la violation, sauf si celle-ci n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes. Lorsque la violation est susceptible d’engendrer un risque élevé, les personnes concernées doivent également être notifiées.

C. Quand les deux régimes se chevauchent

Prenons un cas concret. Un fabricant d’objets connectés découvre qu’une vulnérabilité zéro-day dans son thermostat intelligent est activement exploitée, permettant à un attaquant d’exfiltrer les données de consommation energetique des utilisateurs – qui constituent des données à caractère personnel.

Dans ce scénario, les deux régimes de notification s’appliquent simultanément :

• En tant que fabricant, il doit notifier l’ENISA sous 24 heures au titre du CRA.
• S’il agit comme responsable de traitement (ou s’il doit informer le responsable de traitement utilisateur du produit), la notification à l’autorité de contrôle doit intervenir sous 72 heures au titre du RGPD, et les personnes concernées doivent être informées si le risque est élevé.

Les délais différent, les destinataires différent, le contenu des notifications diffère. Mais l’évènement déclencheur est le même. Sans processus unifie, le risque de manquer l’un des deux signalements – ou de communiquer des informations incoherentes – est réel.

III. SBOM et analyse d’impact : deux outils complémentaires

Le CRA exigé des fabricants qu’ils produisent et maintiennent un SBOM (Software Bill of Materials) documentant l’ensemble des composants logiciels de leurs produits. Le RGPD, de son cote, impose la réalisation d’une analyse d’impact relative à la protection des données (AIPD, article 35) lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes.

Ces deux exercices sont complémentaires. Le SBOM permet d’identifier les composants logiciels qui traitent, stockent ou transmettent des données personnelles. L’AIPD permet d’évaluer les risques que ce traitement fait peser sur les personnes concernées. Concrètement, le SBOM alimente l’AIPD : un composant tiers identifie dans le SBOM comme ayant accès à des données personnelles devra faire l’objet d’une évaluation de risque dans le cadre de l’analyse d’impact.

Par exemple, si le SBOM révèle qu’un produit embarque une bibliotheque d’analytique tierce qui collecté des identifiants d’appareils, cette information doit déclencher une évaluation au titre de l’article 35 du RGPD. L’articulation entre les deux démarches n’est pas optionnelle : elle est la conséquence logique de l’application simultanee des deux textes.

IV. Quand un incident CRA est aussi une violation RGPD

Tous les incidents de sécurité au sens du CRA ne constituent pas des violations de données au sens du RGPD, et inversement. Pour qu’un incident CRA soit aussi qualifié de violation RGPD, il faut que l’incident ait conduit à une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée de données à caractère personnel, ou l’accès non autorisé a de telles données (article 4(12) du RGPD).

En pratique, le chevauchement est fréquent. Une vulnérabilité exploitée dans un objet connecté qui traité des données personnelles aboutira souvent à un accès non autorisé à ces données. Le fabricant doit alors gérer deux processus parallèles : la correction technique de la vulnérabilité (obligation CRA) et la gestion de la violation de données (obligation RGPD), avec ses volets de notification, de documentation au registre des violations, et éventuellement de communication aux personnes concernées.

V. Gérer la double conformité : approche pratique

A. Unifier la gouvernance

La première erreur serait de traiter le CRA et le RGPD en silos. L’équipe sécurité produit (CRA) et le délégué à la protection des données (RGPD) doivent travailler de concert. Chaque évaluation de risque cybersécurité au titre du CRA doit intégrer un volet “données personnelles”, et chaque AIPD au titre du RGPD doit prendre en compte le niveau de sécurité du produit.

B. Harmoniser les processus de notification

Un processus unique de gestion des incidents doit alimenter les deux chaînes de notification. Lorsqu’un incident est détecté, la qualification doit être double : s’agit-il d’une vulnérabilité activement exploitée ou d’un incident grave au sens du CRA ? S’agit-il d’une violation de données au sens du RGPD ? Les deux questions doivent être posées simultanément, par une équipe qui comprend les deux cadres juridiques.

C. Utiliser des outils adaptés

La gestion manuelle de la double conformité CRA-RGPD est rapidement impraticable des qu’un produit atteint une certaine complexité. Des outils comme Legiscope permettent de centraliser le suivi des obligations issues des deux réglementations, d’automatiser la documentation de conformité et de suivre les échéances de notification. L’intérêt d’un tel outil est de maintenir une vue unifiée des obligations croisées plutôt que de multiplier les tableurs et les processus parallèles. Un audit RGPD intégrant la dimension CRA permet d’identifier les zones de chevauchement et d’optimiser les efforts de conformité.

VI. Checklist de double conformité CRA-RGPD

Voici les actions concrètes à mettre en oeuvre pour assurer une conformité conjointe :

Phase de conception du produit :

• Intégrer les exigences de security by design (CRA, annexe I) et de privacy by design (RGPD, article 25) dans un cahier des charges unique.
• Appliquer le principe de minimisation des données, qui est commun aux deux textes.
• Prévoir le chiffrement des données personnelles en transit et au repos (exigence partagée CRA/RGPD).
• Documenter les choix de conception dans la documentation technique CRA et dans le registre des traitements RGPD.

Phase de mise sur le marché :

• Réaliser l’évaluation de risque cybersécurité (CRA) et l’AIPD (RGPD) en parallèle, en s’assurant de leur cohérence.
• Exploiter le SBOM pour identifier les composants traitant des données personnelles et les intégrer à l’AIPD.
• Vérifier que les paramètres par défaut du produit respectent à la fois le security by default et le privacy by default.

Phase d’exploitation et de maintenance :

• Mettre en place un processus unifie de gestion des incidents alimentant les deux chaînes de notification (ENISA sous 24h pour le CRA, autorité de contrôle sous 72h pour le RGPD).
• Tenir à jour un registre des violations (article 33(5) RGPD) et un journal des vulnérabilités (CRA) dans un système centralisé.
• Fournir les mises à jour de sécurité gratuites (CRA) et vérifier que ces mises à jour ne creent pas de nouveaux risques pour les données personnelles (RGPD).
• Auditer périodiquement la conformité aux deux textes via un audit RGPD elargi à la dimension cybersécurité produit.

Outils et gouvernance :

• Designer un référent double conformité CRA-RGPD ou établir une procédure de coordination entre le responsable sécurité produit et le DPO.
• Déployer un outil de suivi réglementaire comme Legiscope pour centraliser les obligations, les échéances et la documentation des deux cadres.
• Former les équipes de développement aux exigences des deux textes, en insistant sur les zones de convergence.

Conclusion

Le CRA et le RGPD ne sont pas des réglementations concurrentes : elles sont complémentaires. La sécurité des produits numériques imposée par le CRA est un prérequis de la protection des données personnelles imposée par le RGPD. Les organisations qui comprennent cette articulation et mettent en place une gouvernance unifiée gagneront en efficacité et reduiront significativement leur exposition au risque – tant le risque d’incident que le risque de sanction. Celles qui persistent a traiter ces deux sujets en silos découvert, un jour ou l’autre, qu’un incident de sécurité produit est aussi une fuite de données, et que deux non-conformités valent toujours pire qu’une seule.