Le règlement (UE) 2024/2847, dit « Cyber Resilience Act », impose une cybersécurité intégrée dès la conception à l’ensemble des produits numériques mis sur le marché européen. Présenté comme un texte de sécurité produit, il constitue aussi, pour le responsable de traitement comme pour le sous-traitant, un appui concret à la conformité au RGPD.
Adopté par le Parlement européen et le Conseil sur proposition de la Commission, le CRA précise qu’il s’applique sans préjudice du RGPD, tout en revendiquant une complémentarité assumée : en protégeant les produits contre les risques de cybersécurité, ses exigences « doivent également contribuer à renforcer la protection des données à caractère personnel et de la vie privée des personnes » (considérant 32).
Autrement dit, là où le RGPD impose une obligation de sécurité au responsable de traitement et à son sous-traitant, le CRA agit en amont, sur l’outil lui-même.
Une asymétrie réglementaire que le CRA vient corriger
En s’adressant au fabricant, à l’éditeur, à l’importateur et au distributeur du produit, il impose des exigences de sécurité indépendamment de l’usage qui en sera fait. Le responsable de traitement n’est plus seul à supporter une exigence de sécurité.
Le règlement appelle des synergies entre la Commission, l’ENISA, le Comité européen de la protection des données et les autorités nationales de contrôle, et prévoit une coopération entre autorités de surveillance du marché et autorités « données personnelles ».
Une sécurité-produit qui nourrit directement l’article 32 du RGPD
C’est là que l’apport devient tangible. Les exigences essentielles de l’annexe I du CRA recoupent largement les mesures que l’article 32 du RGPD attend d’un responsable de traitement. Le produit conforme au CRA doit notamment :
- être mis sur le marché sans vulnérabilité exploitable connue et dans une configuration sécurisée par défaut ;
- protéger la confidentialité des données traitées, par exemple par le chiffrement au repos et en transit ;
- garantir l’intégrité des données et des configurations contre toute modification non autorisée ;
- ne traiter que les données adéquates, pertinentes et limitées à la finalité, une exigence de minimisation directement reprise du vocabulaire du RGPD ;
- protéger la disponibilité des fonctions essentielles, y compris face aux attaques par déni de service ;
- permettre la suppression sécurisée et définitive des données et paramètres de l’utilisateur.
Pour le responsable de traitement, déployer un produit marqué CE au titre du CRA revient à intégrer une brique de sécurité déjà documentée, qu’il pourra valoriser dans sa propre démonstration de conformité.
Le CRA crée des présomptions de conformité à ses propres exigences, non à celles du RGPD. Le responsable de traitement reste tenu de sa propre analyse, au regard du traitement concret, de ses finalités et des risques pour les personnes. Le produit conforme au CRA est un point d’appui, pas une dispense.
« Privacy by design »
L’article 25 du RGPD a souvent souffert d’un défaut d’effectivité : la protection des données dès la conception relevait largement de l’engagement du responsable de traitement, sans prise réelle sur les produits du marché. Le CRA déplace le curseur.
En imposant la sécurité dès la conception et par défaut au niveau du fabricant, l’architecture même du produit devant être pensée pour limiter les vulnérabilités, et la sécurité ne pouvant plus être un correctif appliqué après coup, il fait descendre l’exigence dans le produit lui-même. Le responsable de traitement qui sélectionne ses outils dispose d’un standard objectif, le marquage CE cyber, pour étayer le choix d’un produit « protecteur » au sens de l’article 25.
Cet effet est renforcé par les obligations d’information du CRA (annexe II) : le fabricant doit documenter l’environnement de sécurité, les propriétés de sécurité du produit et la durée pendant laquelle des mises à jour seront fournies. Autant d’éléments que le responsable de traitement pourra verser à son analyse d’impact (AIPD) lorsque celle-ci est requise.
Un enjeu de sécurité durable
Le CRA rompt avec une pratique longtemps répandue : commercialiser un produit puis réduire l’effort de maintenance une fois la vente conclue. Le fabricant doit désormais surveiller les vulnérabilités découvertes après la mise sur le marché et fournir des correctifs pendant toute la période d’assistance, au minimum cinq ans, sauf durée de vie plus courte du produit, les mises à jour de sécurité et la documentation technique devant rester accessibles dix ans.
Ce point a une traduction directe en matière de protection des données. La sécurité exigée par l’article 32 du RGPD n’est pas une donnée figée au jour du déploiement : elle s’apprécie dans le temps. Déployer un produit arrivé en fin de période d’assistance, donc privé de mises à jour de sécurité, pourrait devenir un indice de défaut de sécurité au sens du RGPD.
Vulnérabilités et violations de données : deux régimes de notification à coordonner
Le CRA crée un régime de signalement en trois temps à destination de l’ENISA et du CSIRT coordinateur, via une plateforme européenne de notification. Pour les vulnérabilités activement exploitées comme pour les incidents graves affectant la sécurité du produit, le fabricant doit soumettre une alerte précoce dans les 24 heures, suivie d’une notification complète dans les 72 heures, puis d’un rapport final dans les 14 jours suivant la mise à disposition d’un correctif.
Les deux régimes ne se confondent pas, l’un vise la sécurité du produit, l’autre l’atteinte aux données personnelles, mais ils peuvent se déclencher à partir d’un même événement. Une vulnérabilité exploitée dans un produit qui traite des données personnelles peut, selon les cas, ouvrir simultanément les deux obligations, avec des délais, des destinataires et des critères différents.
Conscient de ce risque de double charge, le législateur invite d’ailleurs les États membres à étudier la mise en place de points d’entrée uniques pour assembler ces différentes notifications. En attendant, il revient à chaque organisation d’articuler en interne ses procédures.
Composants open source
Le règlement réserve un sort particulier aux logiciels libres et ouverts : seuls ceux distribués ou utilisés dans le cadre d’une activité commerciale entrent dans son champ, les projets communautaires sans finalité commerciale en étant exclus. Le texte crée par ailleurs la catégorie d’« intendant de logiciels ouverts », soumis à un régime allégé.
Un point mérite l’attention du responsable de traitement : lorsqu’un fabricant intègre un composant open source dans un produit commercial, il en demeure pleinement responsable au regard du CRA.
Ce que cela change pour la pratique de la conformité
Pour un responsable de traitement ou un DPO, le CRA modifie la façon de raisonner la sécurité.
Le choix des produits devient un acte de conformité « données personnelles ». Privilégier des outils conformes au CRA, et exiger des fournisseurs la documentation de sécurité que le règlement met à leur charge, alimente directement la démonstration attendue au titre des articles 25 et 32 du RGPD.
Cette logique se prolonge naturellement dans les contrats : l’accord de sous-traitance (DPA) de l’article 28 du RGPD gagne à intégrer des engagements précis sur la conformité CRA du fournisseur, la durée de la période d’assistance, les délais de correction des vulnérabilités et l’information en cas de faille.
Le calendrier, enfin, invite à anticiper. Depuis le 11 juin 2026, les États membres peuvent désigner les organismes chargés d’évaluer la conformité des produits ; les obligations de signalement s’appliqueront le 11 septembre 2026, et l’ensemble du règlement deviendra contraignant le 11 décembre 2027. À noter qu’aucun seuil d’exonération n’est prévu : grands groupes comme PME sont concernés.
Loin de redoubler le RGPD, le Cyber Resilience Act en consolide l’effectivité : il fait peser sur le produit une part de la sécurité que le RGPD n’imposait jusqu’ici qu’à son utilisateur. Pour les organisations déjà engagées dans une démarche de conformité « données personnelles », c’est moins une contrainte nouvelle qu’un levier à intégrer dans une gouvernance d’ensemble.
