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 a changé le 11 septembre 2026 : depuis cette date, la plateforme européenne de signalement est ouverte, 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 l’a levée.
Vous fabriquez ou éditez un produit numérique ? Voir notre accompagnement à la mise en conformité CRA.
Chez Digitemis, cabinet qualifié PASSI LPM 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 et environnements d’exécution de conteneurs, pare-feu et systèmes de détection ou de prévention d’intrusion, microprocesseurs résistants à la falsification, microcontrôleurs résistants à la falsification.
- Les produits critiques sont trois : dispositifs matériels dotés de boîtiers de sécurité, passerelles de compteurs intelligents, cartes à puce et dispositifs similaires, dont les éléments sécurisés.
Quatre procédures 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 du produit puis la conformité de sa production. Le module H porte sur le système d’assurance qualité complète. Enfin, un schéma européen de certification de cybersécurité peut être utilisé lorsqu’il existe.
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 s’applique avant la conformité des produits eux-mêmes. Depuis 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. Elle est adressée simultanément au CSIRT coordinateur de votre État, le CERT-FR pour la France, et à l’ENISA. Le CERT-FR diffuse ensuite l’information aux autres États concernés.
Les délais sont courts et s’enchaînent :
- 24 heures pour l’alerte précoce, à compter du moment où vous en avez connaissance ;
- 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 déposés sur 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. Le CERT-FR peut lui transmettre les informations qu’il reçoit, en particulier lorsqu’une vulnérabilité activement exploitée n’est pas corrigée. Les sanctions vont jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu, 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.
Vos clients en sont les premiers bénéficiaires. Les correctifs de sécurité doivent leur être fournis pendant toute la période d’assistance, et la date de fin de cette période doit leur être indiquée au moment de l’achat, au moins au mois près.
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 des exigences. Ni effectif, ni chiffre d’affaires. Une start-up de dix personnes qui commercialise un logiciel installé chez ses clients ou un objet connecté est soumise aux mêmes exigences essentielles qu’un éditeur de mille salariés. Seul allègement : une micro ou petite entreprise qui manque le délai de 24 heures de l’alerte précoce n’encourt pas d’amende pour ce seul retard.
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 avant décembre 2027 sur une hypothèse fausse, puis à découvrir 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, exigible depuis 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 laisse l’obligation de signalement sans procédure pendant que le produit est en cours de sécurisation. 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 les règles de notification 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 numériques mis sur le marché européen. 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 sans attendre
Si vous n’avez pas encore ouvert le sujet, trois actions ne peuvent plus 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, est dû pour décembre 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.