Sécurité offensive
Gouvernance & conformité
Protection des données
Le Cyber Resilience Act est entré en vigueur le 10 décembre 2024, mais rien ne vous était encore demandé. Cela change le 11 septembre 2026 : à cette date, la plateforme européenne de signalement ouvre, et les fabricants doivent y déclarer leurs vulnérabilités activement exploitées. Restait une inconnue que le règlement laissait à chaque État membre : qui contrôle, et qui sanctionne. La foire aux questions publiée par l’ANSSI vient de la lever.
Chez Digitemis, cabinet qualifié PASSI par l’ANSSI, nous accompagnons des éditeurs et des industriels sur cette trajectoire. Cet article détaille ce que le règlement exige, à quelle date, et devant quelle autorité.
Le périmètre du règlement
Le CRA s’applique aux « produits comportant des éléments numériques », c’est-à-dire aux logiciels et matériels connectés, ainsi qu’aux solutions de traitement de données à distance qui leur sont associées. Un composant logiciel ou matériel mis sur le marché séparément entre également dans le champ.
Concrètement, cela couvre les systèmes d’exploitation, les navigateurs, les routeurs, les équipements industriels, les objets connectés grand public et les solutions de sécurité elles-mêmes. Le règlement répartit ces produits en quatre catégories, et cette classification détermine la rigueur de l’évaluation que vous devrez conduire.
- La catégorie par défaut regroupe la grande majorité des produits, du smartphone à la brosse à dents connectée. L’auto-évaluation suffit.
- Les produits importants de classe I rassemblent dix-neuf types de produits, parmi lesquels les gestionnaires de mots de passe, les SIEM, les infrastructures de gestion de clés, les systèmes d’exploitation et les routeurs.
- Les produits importants de classe II comptent quatre types : hyperviseurs, pare-feu et systèmes de détection ou de prévention d’intrusion, et microprocesseurs résistants à la falsification.
- Les produits critiques sont trois : modules matériels de sécurité, cartes à puce et passerelles de compteurs intelligents.
Trois modules d’évaluation existent selon la catégorie. Le module A repose sur une auto-évaluation du fabricant, sans tiers. Les modules B et C font intervenir un organisme notifié qui examine la conception et le développement, avec des essais périodiques. Le module H porte sur le système de management de la qualité.
Quelques secteurs restent hors champ parce qu’ils relèvent déjà de leurs propres cadres : dispositifs médicaux, automobile, aviation, équipements marins, et produits développés exclusivement pour la sécurité nationale ou le traitement d’informations classifiées.
L’échéance du 11 septembre 2026
C’est la première obligation qui vous concerne directement, et elle arrive avant la conformité des produits eux-mêmes. À partir de cette date, vous devez signaler toute vulnérabilité activement exploitée contenue dans l’un de vos produits, ainsi que les incidents graves affectant leur sécurité.
La déclaration passe par une plateforme européenne unique, la Single Reporting Platform, opérée par l’ENISA et mise en ligne à cette même date. L’agence européenne relaie ensuite l’information aux CSIRT nationaux concernés. Pour la France, c’est le CERT-FR.
Les délais sont courts et s’enchaînent :
- 24 heures pour l’alerte précoce, à compter de la découverte ;
- 72 heures pour la notification principale, qui documente la vulnérabilité et les mesures engagées ;
- 14 jours pour le rapport final, à compter du moment où un correctif ou une mesure d’atténuation est disponible ;
- un mois à compter de la notification à 72 heures dans le cas d’un incident grave.
Ces délais ne se tiennent pas en improvisant. Il faut savoir qui décide qu’une vulnérabilité est activement exploitée, qui rédige, qui signe et qui dispose des accès à la plateforme, un dimanche soir comme un mardi matin. C’est une astreinte, pas une procédure de plus dans un classeur.
La chaîne d’autorités françaises
Le règlement laissait à chaque État le soin d’organiser sa chaîne de contrôle. L’ANSSI a publié une foire aux questions qui tranche la répartition française.
L’ANSSI est l’autorité notifiante. Elle évalue, notifie et contrôle les organismes d’évaluation de la conformité qui certifieront les produits, sur la base d’une accréditation délivrée par le COFRAC. L’accréditation ouvre au second semestre 2026, et les premières notifications d’organismes sont attendues pour la fin de l’année. Si votre produit relève d’une catégorie qui exige un tiers, votre planning dépend donc de ce calendrier autant que du vôtre.
Le CERT-FR, qui fait partie de l’ANSSI, reçoit les signalements transmis par la plateforme européenne. C’est votre interlocuteur en cas de vulnérabilité exploitée.
L’ANFR est l’autorité de surveillance du marché. Elle conduit des analyses de marché pour identifier les produits à vérifier, mène les études techniques et documentaires, et prend les mesures correctives ou restrictives nécessaires. Elle intervient notamment sur alerte de l’ANSSI, en particulier lorsqu’une vulnérabilité activement exploitée n’est pas corrigée par le fabricant dans les délais prévus. Les sanctions vont jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, et jusqu’au retrait du produit du marché. La mécanique tient en une phrase : vous déclarez au CERT-FR, et c’est l’ANFR qui vient vérifier que vous avez corrigé.
La fin du « vendre puis oublier »
L’apport le plus structurant du CRA tient moins aux exigences de sécurité elles-mêmes, que la plupart des éditeurs sérieux connaissent déjà, qu’à l’extension de votre responsabilité après la vente.
Vous devez déterminer une période d’assistance pendant laquelle vous garantissez le traitement effectif des vulnérabilités de votre produit. Cette période doit refléter la durée d’utilisation attendue, et ne peut descendre en dessous de cinq ans, sauf lorsque la durée de vie du produit est elle-même plus courte. Pendant tout ce temps, vous surveillez les vulnérabilités qui apparaissent, vous produisez des correctifs et vous informez vos clients.
Ces derniers acquièrent d’ailleurs des droits correspondants. Un acheteur peut exiger la mise à disposition des correctifs pendant la période d’assistance, et des informations claires sur l’identité du produit et de son fabricant.
Le déplacement est réel. Une équipe produit qui livrait une version et passait à la suivante doit désormais tenir un inventaire de ce qu’elle embarque, savoir qui pilote le traitement des vulnérabilités et produire la preuve de ce qu’elle a fait. Le CRA n’est pas un dossier juridique, c’est un chantier d’organisation produit qui commence dans le cycle de développement.
Le cas des composants open source
Le règlement a beaucoup évolué sur ce point avant son adoption. Dans sa version finale, seuls les logiciels libres distribués ou utilisés dans le cadre d’une activité commerciale relèvent du CRA. Les projets communautaires développés sans objectif commercial restent en dehors.
Le texte crée par ailleurs une catégorie d’intendants de logiciels ouverts, les open-source software stewards : des personnes morales qui apportent un soutien durable et systématique au développement de produits open source destinés à des usages commerciaux. Leur régime est allégé. Ils doivent disposer d’une politique de cybersécurité, coopérer avec les autorités de surveillance du marché et signaler les vulnérabilités activement exploitées, mais ils ne s’exposent pas aux sanctions prévues par le règlement.
Un point ne souffre en revanche aucune ambiguïté. Lorsque vous intégrez un composant open source dans un produit commercial, vous restez pleinement responsable de sa conformité. La provenance du code ne transfère pas la responsabilité. C’est ce qui rend l’inventaire de vos composants logiciels aussi central, et ce qu’un audit de code met en évidence : vous ne pouvez pas répondre du CRA sur un produit dont vous ne savez pas ce qu’il contient.
L’absence de seuil pour les petites structures
Le CRA ne prévoit aucun seuil d’exonération. Ni effectif, ni chiffre d’affaires. Une start-up de dix personnes qui commercialise une solution SaaS est soumise aux mêmes exigences essentielles qu’un éditeur de mille salariés.
La Commission a prévu des mécanismes d’accompagnement pour les microentreprises et les PME, sous forme de guides, de dispositifs de soutien nationaux et de financements. Ils atténuent l’effort, ils ne le suppriment pas. Pour une petite équipe, l’enjeu se joue moins sur la technique que sur la formalisation : documenter ce qui est déjà fait, écrire les processus qui existaient dans les têtes, et tenir la traçabilité dans la durée.
Le piège de l’attente des normes
La FAQ de l’ANSSI vise explicitement ce réflexe, ce qui laisse penser qu’il est répandu : attendre la publication des normes harmonisées pour lancer les travaux, en supposant que ces normes diront quoi faire.
La réalité est différente. Les normes harmonisées ouvriront une présomption de conformité et faciliteront la démonstration, mais leur usage reste volontaire. L’ANSSI est formelle : aucune norme n’est obligatoire, et les fabricants n’ont pas à attendre leur adoption. Les exigences essentielles du règlement, elles, s’imposent indépendamment.
Attendre revient donc à consommer les mois qui restent sur une hypothèse fausse, puis à découvrir en 2027 que l’inventaire des composants, la politique de gestion des vulnérabilités et le dossier de preuves n’existent toujours pas. Ces trois chantiers ne dépendent d’aucune norme.
Les deux chantiers à ne pas confondre
La confusion la plus coûteuse consiste à traiter le CRA comme une échéance unique en décembre 2027. Ce sont deux chantiers distincts, avec des exigences et des rythmes différents.
Le premier est un chantier de processus, dû pour le 11 septembre 2026. Il consiste à savoir détecter qu’une de vos vulnérabilités est activement exploitée, à disposer d’une chaîne de décision et de rédaction capable de tenir 24 heures, et à avoir les accès à la plateforme européenne. Il ne demande pas de retoucher vos produits.
Le second est un chantier de produit, dû pour le 11 décembre 2027. Il porte sur la sécurité dès la conception, l’évaluation de conformité, la documentation technique, le marquage CE et la gestion des vulnérabilités sur tout le cycle de vie. Il se compte en trimestres, et il conditionne l’accès au marché européen. C’est le périmètre de notre accompagnement à la mise en conformité CRA, qui sépare précisément ce qui est dû à chaque échéance.
Un plan d’action qui ne distingue pas les deux vous fera arriver en septembre avec un produit en cours de sécurisation et aucune procédure de signalement. C’est l’inverse de l’ordre utile.
Ce qu’il faut retenir
- Le CRA, règlement (UE) 2024/2847, couvre tous les produits comportant des éléments numériques, du logiciel au matériel connecté.
- Trois échéances : le 11 juin 2026 pour la désignation des organismes d’évaluation, le 11 septembre 2026 pour le signalement des vulnérabilités, le 11 décembre 2027 pour la conformité complète.
- En France, l’ANSSI désigne les organismes certificateurs, le CERT-FR reçoit les signalements, l’ANFR surveille le marché et sanctionne.
- Les amendes atteignent 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial, avec retrait du produit possible.
- Il n’y a aucun seuil d’exonération : une start-up de dix personnes est soumise aux mêmes exigences essentielles qu’un grand éditeur.
- Les fabricants n’ont pas à attendre l’adoption des normes harmonisées pour se mettre en conformité.
Questions fréquentes
Mon logiciel est en SaaS, suis-je concerné ?
Le règlement vise les produits comportant des éléments numériques et les solutions de traitement de données à distance qui leur sont associées. Un service purement en ligne, sans produit associé, peut sortir du champ, mais la question mérite une analyse au cas par cas plutôt qu’une réponse de principe.
Le marquage CE atteste-t-il de la sécurité de mon produit ?
Non, et la nuance est importante. Le marquage CE atteste de la conformité aux exigences du règlement, par auto-évaluation ou par un tiers selon la catégorie. Il ne mesure pas la robustesse réelle du produit, ce que fait une certification de sécurité ou un test d’intrusion.
Que se passe-t-il si je ne signale pas une vulnérabilité exploitée ?
L’ANFR peut intervenir sur alerte de l’ANSSI, exiger des mesures correctives, restreindre la commercialisation, et prononcer une amende pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial.
Le CRA remplace-t-il NIS2 ?
Non, les deux textes se complètent. NIS2 porte sur la sécurité des organisations qui exploitent des systèmes d’information. Le CRA porte sur la sécurité des produits qu’elles achètent. Un éditeur peut relever des deux à la fois, comme entité régulée et comme fabricant.
Faut-il un organisme notifié pour mon produit ?
Cela dépend de sa catégorie. La majorité des produits relèvent de l’auto-évaluation. Les produits importants et critiques exigent, selon les cas, l’intervention d’un organisme notifié, dont les premières désignations en France sont attendues fin 2026.
Les trois actions à engager avant septembre
Si vous n’avez pas encore ouvert le sujet, trois actions valent d’être engagées sans attendre. Établissez l’inventaire des composants logiciels de vos produits, y compris l’open source, parce que rien ne se fait sans lui. Désignez le responsable du traitement des vulnérabilités et écrivez la chaîne de décision qui tiendra le délai de 24 heures. Qualifiez enfin la catégorie de chacun de vos produits, puisqu’elle détermine si vous dépendez ou non d’un organisme notifié, et donc si votre planning dépend du calendrier de l’ANSSI. Le reste, la sécurité dès la conception, le dossier de preuves et le marquage CE, relève de 2027 et se construit sur ces trois fondations.
Sources
- Règlement (UE) 2024/2847 du Parlement européen et du Conseil, dit Cyber Resilience Act.
- Questions fréquentes sur le CRA et cadre réglementaire du CRA, ANSSI.
- Le Cyber Resilience Act, Agence nationale des fréquences.
- The Cyber Resilience Act, summary of the legislative text, Commission européenne.