Cyber Resilience Act : le compte à rebours du 11 septembre 2026 pour les établissements financiers et leurs fournisseurs

Ce qui change le 11 septembre 2026

Demain, le 11 septembre 2026, une nouvelle brique du corpus européen de cybersécurité entre en application : les obligations de déclaration du Cyber Resilience Act (CRA, règlement UE 2024/2847). Ce texte, entré en vigueur le 10 décembre 2024, ne vise pas les établissements financiers en tant que tels — il régule les fabricants de « produits à éléments numériques » (logiciels autonomes, objets connectés, équipements réseau) commercialisés dans l'Union. Mais son impact sur le secteur financier est réel, et il passe par la chaîne de fournisseurs.

Le texte en bref

Le Cyber Resilience Act encadre la cybersécurité des produits comportant des éléments numériques tout au long de leur cycle de vie. Il s'inscrit dans le même mouvement que NIS2 et DORA, mais avec un objet différent : là où NIS2 vise la gouvernance et la gestion des risques des organisations, et DORA les établissements financiers et leurs prestataires TIC critiques, le CRA vise le produit lui-même, chez son fabricant.

Le calendrier d'application est échelonné. Selon la Commission européenne, les obligations de déclaration entrent en application le 11 septembre 2026, tandis que l'essentiel des exigences de conformité (marquage CE, documentation technique, gestion des vulnérabilités sur toute la durée de vie du produit) s'appliquera à compter du 11 décembre 2027.

Ce que le 11 septembre change concrètement

À compter de cette date, tout fabricant d'un produit à éléments numériques placé sur le marché européen doit, en cas de vulnérabilité activement exploitée ou d'incident grave affectant la sécurité du produit :

• signaler une alerte précoce à l'ENISA et/ou au CSIRT national compétent, dans les 24 heures suivant la connaissance du fait ;
• transmettre une notification technique détaillée, avec les mesures correctives ou d'atténuation disponibles, dans les 72 heures ;
• produire un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective pour les vulnérabilités activement exploitées (un mois pour les incidents graves).

Ces déclarations transitent par une plateforme unique, la Single Reporting Platform (SRP), opérée par l'ENISA. Un signalement suffit : l'information est partagée simultanément avec le CSIRT du pays d'établissement du fabricant et avec l'ENISA.

Pourquoi les établissements financiers doivent s'y intéresser maintenant

Le système d'information d'un établissement financier repose largement sur des briques fournies par des tiers : progiciels de cœur bancaire, terminaux de paiement, passerelles API, dispositifs IoT de sécurité physique. Une part significative de ces briques entre dans le périmètre du CRA.

L'impact se joue à trois niveaux :

1. Contractuel — les clauses de gestion des risques liés aux prestataires TIC critiques, déjà renforcées sous DORA, doivent désormais intégrer la question : mon fournisseur a-t-il une obligation de déclaration CRA, et s'engage-t-il contractuellement à me notifier ce qu'il transmet à l'ENISA ?
2. Opérationnel — un établissement qui ignore qu'un fournisseur a signalé une vulnérabilité activement exploitée sur un produit qu'il utilise perd un temps précieux avant de pouvoir activer ses propres mesures de continuité et de remédiation.
3. Réputationnel et prudentiel — en cas d'incident chez un prestataire critique, l'absence de dispositif de suivi de ces signalements réglementaires pourra être questionnée par le superviseur dans le cadre du contrôle du risque d'externalisation.

Checklist opérationnelle avant le 11 septembre

• Cartographier les fournisseurs de logiciels et de matériels connectés du système d'information (cœur bancaire, TPE/TPV, dispositifs de sécurité, objets connectés)
• Identifier, pour chacun, s'il entre dans le périmètre du CRA en tant que fabricant de produit à éléments numériques
• Vérifier, dans les contrats en cours et les clauses TPRM/DORA, si une obligation de notification réciproque est déjà prévue
• Désigner un point de contact interne chargé de recevoir et de traiter ces signalements de vulnérabilité
• Articuler ce nouveau flux d'information avec les procédures de notification d'incident déjà en place au titre de DORA, dont les délais et destinataires diffèrent

Cette checklist ne remplace pas une revue contractuelle complète : elle donne un point de départ pour prioriser, dans les prochains jours, les fournisseurs dont l'absence de vigilance coûterait le plus cher.

Une échéance qui ne concerne pas que les grands éditeurs

Le réflexe naturel est de penser d'abord aux grands éditeurs de progiciels bancaires. Mais le périmètre du CRA est large : il couvre aussi les fabricants de terminaux de paiement, de bornes en agence, de dispositifs biométriques, de routeurs et d'équipements réseau, dès lors qu'ils sont commercialisés comme des « produits à éléments numériques » dans l'Union européenne. Un établissement qui a externalisé une partie de son infrastructure — hébergement, terminaux, objets connectés de sécurité physique — doit donc élargir sa cartographie au-delà du seul cœur bancaire.

Cette échéance du 11 septembre 2026 ne doit pas non plus être confondue avec l'échéance du 11 décembre 2027, qui porte sur l'ensemble des exigences de conformité produit (marquage CE, documentation technique, gestion des vulnérabilités sur toute la durée de vie commerciale). Le 11 septembre n'ouvre que le volet déclaratif — mais c'est celui qui produit un flux d'information opérationnel immédiat, à faire remonter en interne dès maintenant.

Le lien avec DORA : deux textes, deux logiques, un même risque à piloter

DORA impose déjà aux établissements financiers de gérer le risque lié à leurs prestataires TIC critiques et de notifier certains incidents majeurs à leur superviseur, selon des délais et des destinataires qui lui sont propres. Le CRA n'annule ni ne remplace ces obligations : il crée un flux de signalement supplémentaire, en amont, chez le fabricant du produit plutôt que chez l'établissement financier lui-même.

L'articulation pratique consiste à faire en sorte que l'information remontant d'un fournisseur au titre du CRA (vulnérabilité activement exploitée, incident grave) alimente sans délai le dispositif de gestion des risques et de notification d'incident déjà en place au titre de DORA — plutôt que de laisser coexister deux circuits d'information étanches l'un à l'autre.