Cyber Resilience Act (CRA) : ce qui vient de changer pour les produits numériques utilisés dans la finance

Une échéance qui vient de tomber

Le Cyber Resilience Act — le règlement (UE) 2024/2847 — est entré en vigueur le 10 décembre 2024, mais ses obligations s’échelonnent dans le temps. La première étape opérationnelle est désormais franchie : depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de leurs produits comportant des éléments numériques. L’ENISA a mis en service le même jour la plateforme unique de signalement (Single Reporting Platform, SRP), seul canal par lequel ces notifications peuvent être déposées.

Le reste du règlement — l’essentiel des exigences de cybersécurité — s’appliquera le 11 décembre 2027. Autrement dit, la partie la plus contraignante en termes de délais est déjà en vigueur, quinze mois avant le corps du texte.

Pour les banques et les assurances, ce règlement n’a pas la visibilité de DORA, et il est souvent perçu comme un sujet d’industriels. C’est une lecture incomplète : le CRA agit d’abord sur la qualité et la transparence des produits que les établissements achètent et exploitent, et il peut, dans certains cas, les concerner directement. Cet article propose une lecture de gouvernance : ce qui s’applique depuis le 11 septembre, qui est réellement concerné, comment ne pas confondre CRA, DORA et NIS2, et ce qu’il reste à préparer avant décembre 2027.

Le périmètre : les « produits comportant des éléments numériques »

Le CRA est un cadre horizontal : il introduit des exigences de cybersécurité obligatoires pour les produits comportant des éléments numériques mis sur le marché de l’Union, tout au long de leur cycle de vie. Cette catégorie couvre aussi bien du matériel que du logiciel : équipements réseau, objets connectés, composants, applications, systèmes d’exploitation, bibliothèques.

Le règlement distingue plusieurs niveaux de criticité, qui déterminent la procédure d’évaluation de la conformité. Les produits par défaut relèvent de l’auto-évaluation. Les produits dits importants, listés à l’annexe III et répartis en deux classes, supposent le recours à des normes harmonisées ou à un organisme notifié. Les produits critiques, listés à l’annexe IV, requièrent une certification obligatoire. La classification suit la fonction principale du produit, la classe la plus stricte s’appliquant lorsque plusieurs correspondent.

Certaines catégories sont exclues, notamment des produits déjà couverts par des législations sectorielles spécifiques — dispositifs médicaux, véhicules, aviation — ainsi que les logiciels libres développés hors d’un cadre commercial.

Ce qui s’applique depuis le 11 septembre 2026

L’article 14 du CRA crée deux obligations de signalement pour les fabricants : les vulnérabilités activement exploitées contenues dans leurs produits, et les incidents graves ayant un impact sur la sécurité de ces produits. Une vulnérabilité est considérée comme activement exploitée lorsqu’il existe des éléments fiables indiquant qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation de son propriétaire.

Le calendrier de notification est serré et se décompose en trois temps. Une alerte précoce doit être transmise dans les 24 heures suivant la prise de connaissance de l’événement. Une notification complète, incluant les mesures correctives ou d’atténuation prises, doit suivre dans les 72 heures. Un rapport final est ensuite attendu : au plus tard 14 jours après la mise à disposition d’une mesure corrective pour une vulnérabilité activement exploitée, et dans le mois suivant la notification de 72 heures pour un incident grave.

Les notifications sont adressées, via la plateforme unique, au CSIRT désigné comme coordinateur ainsi qu’à l’ENISA. Les fabricants doivent par ailleurs informer les utilisateurs concernés — et, le cas échéant, l’ensemble des utilisateurs — de la vulnérabilité ou de l’incident, ainsi que des mesures qu’ils peuvent prendre pour en atténuer les effets.

Un point mérite une attention particulière : en application de l’article 69, paragraphe 3, l’obligation de signalement s’étend aux produits déjà mis sur le marché de l’Union avant l’application pleine du règlement. Un équipement livré en 2022 ou un micrologiciel diffusé avant l’entrée en vigueur entre donc dans le champ de l’obligation. Le signalement est, par défaut, la seule partie du règlement qui atteint ainsi le parc existant.

Enfin, les obligations de signalement applicables aux gestionnaires de logiciels libres (open-source stewards), prévues à l’article 24, paragraphe 3, ne s’appliqueront qu’à compter du 11 décembre 2027.

La plateforme unique de signalement, et ses limites actuelles

Prévue par l’article 16 du règlement, la plateforme unique de signalement a été établie par l’ENISA en coopération étroite avec le réseau des CSIRT. Sa logique est celle du « signaler une fois » : le fabricant dépose une notification unique, qui est ensuite communiquée aux autorités concernées, plutôt que de notifier séparément chaque autorité nationale.

La plateforme a été lancée dans une capacité opérationnelle initiale. Plusieurs limites ont été relevées à son ouverture, notamment l’absence d’interface programmatique (API) et l’indisponibilité du signalement volontaire au lancement — alors que le règlement prévoit que la plateforme pourra également servir à des signalements volontaires. L’ENISA a publié un ensemble de ressources d’accompagnement : questions fréquentes, guides d’utilisation, glossaire et supports de formation. La Commission européenne a, de son côté, apporté des clarifications sur les obligations de signalement dans ses orientations relatives à l’application du CRA.

Concrètement, pour les organisations concernées, l’enjeu n’est pas seulement de connaître la plateforme : c’est de disposer d’un processus interne capable de tenir un délai de 24 heures, avec un enregistrement préalable, des rôles identifiés et une chaîne d’escalade opérationnelle.

Qui est « fabricant » ? La question que les établissements doivent se poser

Le CRA structure ses obligations autour de rôles : fabricant, importateur, distributeur. La charge principale pèse sur le fabricant, c’est-à-dire l’entité qui développe ou fait développer un produit comportant des éléments numériques et le met sur le marché sous son propre nom ou sa propre marque.

Pour la très grande majorité des banques et des assurances, la position est d’abord celle d’utilisateur et d’acheteur de produits. Mais la question du rôle de fabricant mérite d’être posée, au cas par cas, dès lors qu’un établissement met un produit numérique à disposition sur le marché sous sa propre marque — logiciel distribué, équipement fourni à des clients ou à des partenaires, composant commercialisé. Cette qualification ne se présume pas : elle dépend de la nature du produit, de son mode de mise à disposition et des exclusions prévues par le règlement. Elle mérite en revanche une analyse explicite, plutôt qu’une présomption d’exclusion.

Les sanctions justifient cette vigilance : les manquements aux exigences essentielles ou aux obligations des fabricants peuvent être sanctionnés jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu.

Ne pas confondre CRA, DORA et NIS2

C’est probablement le point de clarification le plus utile pour un lectorat financier, car les trois textes créent des obligations de signalement aux délais voisins mais aux logiques distinctes.

Le CRA porte sur les produits. Il fait peser l’obligation de signalement sur le fabricant du produit, pour des vulnérabilités activement exploitées et des incidents affectant la sécurité de ce produit.

DORA porte sur les entités financières et leur résilience opérationnelle. C’est à ce titre qu’un établissement classe et notifie ses incidents liés aux technologies de l’information et de la communication, auprès de son autorité compétente.

NIS2 porte sur les entités essentielles et importantes de secteurs désignés, avec ses propres obligations de notification.

Une conséquence pratique s’impose : une banque victime d’un incident causé par la vulnérabilité d’un produit ne signale pas au titre du CRA — elle notifie au titre de DORA. Le fabricant du produit, lui, signale au titre du CRA. Confondre les deux conduit soit à des signalements inutiles, soit, plus grave, à des notifications manquantes.

L’effet principal pour la finance : la gestion des fournisseurs

C’est par ce canal que le CRA produira l’essentiel de ses effets pour les établissements financiers.

Un flux entrant d’informations à organiser. Les fabricants doivent désormais informer les utilisateurs concernés des vulnérabilités activement exploitées et des incidents affectant leurs produits. Pour un établissement, cela signifie un flux de notifications à recevoir, qualifier et traiter dans des délais courts. Ce flux doit être branché sur le processus de gestion des vulnérabilités et sur la chaîne d’escalade existante, faute de quoi une information critique transmise par un fournisseur risque de se perdre dans une boîte générique.

Une exigence de connaissance des composants. La décision de signaler repose sur une connaissance fine des composants : les orientations de la Commission prévoient qu’un fabricant doit signaler une vulnérabilité activement exploitée provenant d’un composant tiers intégré à son produit, sauf lorsque le code vulnérable n’y est pas exploitable — par exemple parce qu’il n’est pas atteignable — ou n’a pas été exploité dans ce produit. L’obligation formelle de fournir une nomenclature logicielle (SBOM) dans un format lisible par machine relève des exigences applicables en décembre 2027, mais la capacité à répondre aux obligations de signalement en dépend déjà largement en pratique. Pour les établissements, c’est un argument supplémentaire pour exiger et exploiter des SBOM auprès de leurs fournisseurs.

Un levier contractuel et de sélection. À mesure que les exigences du CRA se déploieront, la conformité d’un produit, sa période de support, sa politique de gestion des vulnérabilités et la qualité de son information deviendront des critères d’évaluation objectivables lors des appels d’offres et des renouvellements. Cette dimension s’articule naturellement avec les exigences de gestion du risque lié aux prestataires TIC portées par DORA.

Ce qu’il reste à préparer d’ici décembre 2027

L’essentiel des obligations du CRA — exigences essentielles de cybersécurité, sécurité dès la conception, gestion des vulnérabilités tout au long du cycle de vie, documentation technique, marquage CE, procédures d’évaluation de la conformité, nomenclature logicielle — s’appliquera le 11 décembre 2027.

Pour un établissement qui se découvrirait un rôle de fabricant, le chantier est significatif et suppose d’être engagé dès maintenant. Pour un établissement utilisateur, la préparation est différente mais réelle : cartographier les produits critiques et leurs fournisseurs, identifier ceux qui relèveront des catégories « important » ou « critique », anticiper les fins de support, intégrer les exigences CRA dans les clauses contractuelles et les questionnaires fournisseurs, et organiser la réception des notifications.

Perspective Forum des Compétences

Le Cyber Resilience Act est passé, le 11 septembre 2026, du statut de texte à échéance lointaine à celui d’obligation opérationnelle. Il conserve pourtant une visibilité faible dans le secteur financier, sans doute parce qu’il est perçu comme un règlement destiné aux industriels.

Cette perception mérite d’être corrigée sur trois points. D’abord, la qualification de fabricant n’est pas théorique pour tous les établissements : elle mérite une analyse explicite lorsqu’un produit numérique est mis à disposition sous la marque de l’établissement. Ensuite, et surtout, le CRA modifie la relation fournisseur : il crée un flux entrant de notifications à organiser, et il rend opposables des exigences de transparence, de support et de gestion des vulnérabilités qui relevaient jusqu’ici de la négociation contractuelle. Enfin, il faut éviter la confusion des régimes : un établissement victime d’un incident notifie au titre de DORA, pas du CRA.

À moyen terme, le bénéfice attendu est simple : des produits plus sûrs par défaut, mieux documentés et mieux maintenus. Pour les banques et les assurances, la manière la plus efficace d’en tirer parti est de traiter le CRA non comme une contrainte de plus, mais comme un levier de qualité dans la sélection et le suivi de leurs fournisseurs technologiques — en commençant par une question simple : lorsqu’un fournisseur signalera une vulnérabilité activement exploitée dans les 24 heures, qui, dans l’organisation, recevra cette information, et que se passera-t-il ensuite ?

Sources publiques utilisées

Cet article s’appuie sur le règlement lui-même et sur la documentation officielle de la Commission européenne et de l’ENISA :

• Règlement (UE) 2024/2847 (Cyber Resilience Act), entré en vigueur le 10 décembre 2024, notamment ses articles 14 (obligations de signalement), 16 (plateforme unique de signalement), 24, paragraphe 3 (gestionnaires de logiciels libres), 69, paragraphe 3 (produits déjà mis sur le marché) et 71, paragraphe 2 (calendrier d’application), ainsi que ses annexes I, III et IV.
• Commission européenne, page Cyber Resilience Act – Reporting obligations et orientations relatives à l’application du CRA (clarifications sur les obligations de signalement, notamment pour les vulnérabilités provenant de composants tiers).
• ENISA, annonce du lancement de la plateforme unique de signalement (Single Reporting Platform) et page dédiée à la SRP, incluant les ressources d’accompagnement (questions fréquentes, guides d’utilisation, glossaire, supports de formation).
• Règlement (UE) 2022/2554 (DORA) et directive (UE) 2022/2555 (NIS2), pour la distinction entre les régimes de notification applicables aux entités financières, aux entités essentielles et importantes, et aux fabricants de produits.