Cyber Resilience Act : signaler une vulnérabilité exploitée en 24 h

Depuis le 11 septembre 2026, le Cyber Resilience Act impose le signalement des vulnérabilités activement exploitées et des incidents graves sous 24 h, via une plateforme de l’ENISA. Éditeur, agence ou ESN : vous livrez peut-être un « produit comportant des éléments numériques » sans le savoir. Ce guide vous aide à qualifier votre situation, préparer votre SBOM et bâtir un processus de signalement fiable.

Ce qui s’applique depuis le 11 septembre 2026

Le règlement (UE) 2024/2847, dit Cyber Resilience Act (CRA), publié le 20 novembre 2024 [1], fixe des exigences de cybersécurité pour les « produits comportant des éléments numériques » : objets connectés, mais aussi logiciels vendus, distribués ou monétisés.

Le calendrier du CRA en un tableau

Côté français, l’ANSSI est l’autorité notifiante, le CERT-FR centralise les signalements et la surveillance du marché revient à l’Agence nationale des fréquences (ANFR) [7].

Les produits déjà sur le marché sont aussi concernés

Un produit mis sur le marché avant le 11 décembre 2027 n’est en principe soumis au CRA qu’en cas de « modification substantielle ». Mais l’article 69 §3 fait exception : l’article 14 s’applique à tous les produits relevant du règlement, y compris ceux déjà commercialisés [1]. Une application publiée en 2022 et toujours distribuée est donc concernée.

Signalement des vulnérabilités : les délais du Cyber Resilience Act

Vulnérabilité activement exploitée, incident grave : les définitions

Deux notions déclenchent l’obligation, pas chaque CVE de vos dépendances :

• Vulnérabilité activement exploitée : « une vulnérabilité pour laquelle il existe des preuves fiables qu’elle a été exploitée par un acteur malveillant dans un système sans l’autorisation du propriétaire du système » (art. 3) [1]. Une CVE critique non exploitée n’en fait pas partie ; une faille maison exploitée chez un client, si.
• Incident grave (art. 14 §5) : un incident qui entache, ou peut entacher, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou fonctions sensibles, ou qui a conduit (ou peut conduire) à l’exécution de code malveillant chez un utilisateur. La compromission de votre chaîne de build ou de votre serveur de mises à jour en est l’exemple type.

24 h, 72 h, 14 jours, un mois : le tableau des délais

Le compteur démarre à la prise de connaissance, pas à la fin de votre analyse. Le CSIRT peut aussi demander un rapport intermédiaire (art. 14 §6).

Par où passe la notification : plateforme ENISA et CERT-FR

Toutes les notifications passent par la plateforme unique de signalement (Single Reporting Platform) de l’ENISA, opérationnelle depuis le 11 septembre 2026 [2][3]. Vous déposez une seule notification, adressée au CSIRT coordinateur de l’État membre de votre établissement principal (là où se prennent les décisions de cybersécurité produit) et mise simultanément à disposition de l’ENISA (art. 14 §7). Pour la France, l’ENISA liste le CERT-FR [5].

Selon l’ENISA [4], l’accès exige un compte EU Login avec authentification multifacteur, et il est conseillé de ne s’enregistrer comme fabricant qu’au moment où une notification devient nécessaire.

Informer aussi vos utilisateurs

L’article 14 §8 impose d’informer les utilisateurs touchés et de leur indiquer les mesures d’atténuation, « s’il y a lieu dans un format structuré, lisible par machine ». Préparez un modèle d’avis de sécurité et un canal de diffusion.

Êtes-vous « fabricant » au sens du CRA ?

La définition qui compte

Est fabricant la personne qui « développe ou fabrique des produits comportant des éléments numériques ou fait concevoir, développer ou fabriquer des produits comportant des éléments numériques, et les commercialise sous son propre nom ou sa propre marque, à titre onéreux, monétisé ou gratuit » (art. 3) [1]. La gratuité n’exclut donc pas le CRA si le produit est monétisé autrement (considérant 15), et celui qui fait développer puis commercialise sous sa marque est fabricant.

Éditeur SaaS : NIS 2 d’abord, CRA si votre cloud fait fonctionner un produit

Selon le considérant 12, le SaaS, le PaaS et l’IaaS relèvent de la directive NIS 2, pas du CRA. Mais un « traitement de données à distance » conçu par le fabricant et sans lequel le produit ne pourrait pas remplir une de ses fonctions fait partie du produit [1] : l’API qui pilote une application mobile ou un objet connecté que vous distribuez, par exemple. Les lignes directrices de la Commission du 27 juillet 2026 (C(2026) 5252) détaillent ce test [6].

Agence ou ESN qui livre du logiciel : qui porte l’obligation ?

Voici la grille de lecture que nous appliquons, à confirmer au cas par cas avec votre conseil :

En cas de doute, un audit et conseil ciblé permet d’inventorier les produits concernés.

Open source : activité commerciale, intendants et composants

Le CRA ne vise le logiciel libre que s’il est fourni dans le cadre d’une activité commerciale : la fourniture d’un logiciel libre non monétisé n’en est pas une, et contribuer à un projet ou le financer ne suffit pas à le devenir (considérant 18) [1]. Les intendants de logiciels ouverts ont un régime allégé (art. 24) ; la Commission indique que leurs obligations de signalement s’appliquent à partir du 11 décembre 2027 [2], et ils ne sont pas passibles d’amendes (art. 64 §10).

Si vous intégrez de l’open source, deux obligations comptent : la diligence raisonnable sur les composants tiers (art. 13 §5) et le signalement au mainteneur de toute vulnérabilité découverte, avec partage du correctif si vous l’avez écrit (art. 13 §6).

SBOM et gestion des vulnérabilités : ce que l’annexe I exige

Exigibles au 11 décembre 2027, ces exigences conditionnent dès aujourd’hui votre capacité à signaler à temps.

Les huit exigences de la partie II

L’annexe I, partie II, demande aux fabricants [1] :

• une nomenclature des logiciels (SBOM) « dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur » ;
• des corrections sans retard, avec des mises à jour de sécurité séparées des évolutions fonctionnelles si possible ;
• des tests de sécurité réguliers ;
• la publication, avec chaque correctif, de la description et de la gravité des failles corrigées ;
• une politique de divulgation coordonnée des vulnérabilités ;
• une adresse de contact pour signaler une vulnérabilité ;
• une distribution sécurisée des mises à jour ;
• la diffusion des correctifs sans retard et, sauf accord contraire pour un produit sur mesure, gratuitement.

Les points 3 et 7 se traitent dans la chaîne de tests : c’est le rôle d’une démarche d’assurance qualité et tests intégrée au pipeline, plutôt que d’un test d’intrusion annuel isolé.

Produire un SBOM et scanner à chaque build

Le CRA n’impose pas de format ; CycloneDX et SPDX sont les plus répandus. Exemple de commandes à brancher dans une CI GitLab ou GitHub :

# Dépendances PHP (Symfony, Laravel, PrestaShop…) : vulnérabilités connues
composer audit --locked

# Dépendances Node.js : audit + SBOM CycloneDX
npm audit --omit=dev
npm sbom --sbom-format cyclonedx > sbom-npm.cdx.json

# Image Docker complète (OS + runtime + application)
syft registry.example.com/app:1.4.2 -o cyclonedx-json > sbom-image.cdx.json
grype sbom:./sbom-image.cdx.json --fail-on high

Archivez le SBOM avec chaque version livrée : le jour d’une exploitation, la question est « que tourne-t-il chez chaque client ? ».

Une période d’assistance d’au moins cinq ans

L’article 13 §8 impose une période d’assistance d’au moins cinq ans, sauf durée d’utilisation prévue plus courte [1] ; sa date de fin devra être indiquée à l’achat (art. 13 §19).

Le runbook « 24 h » : organiser le signalement avant le premier incident

Seuls les délais de 24 h, 72 h, 14 jours et un mois sont réglementaires ; le jalon à 4 h est une recommandation.

Checklist de préparation :

• [ ] Liste des produits concernés, versions distribuées et pays de mise à disposition
• [ ] SBOM archivé pour chaque version livrée
• [ ] Deux représentants désignés, comptes EU Login avec MFA testés
• [ ] Astreinte couvrant week-ends et jours fériés (24 h calendaires)
• [ ] Adresse de signalement publique (fichier security.txt) et politique de divulgation
• [ ] Modèles pré-remplis : alerte précoce, notification, avis utilisateurs
• [ ] Exercice à blanc au moins une fois par an

Ce que le CRA change pour la TMA et le DevOps

Contrats de TMA : les clauses à revoir

La détection a souvent lieu chez le prestataire. Un contrat de maintenance applicative (TMA) compatible CRA devrait préciser :

• le délai interne de remontée d’un soupçon d’exploitation, en heures ;
• qui tient le SBOM de chaque version ;
• la livraison de correctifs de sécurité distincts des évolutions ;
• la contribution du prestataire aux rapports à 72 h et finaux ;
• la conservation des journaux et la confidentialité des échanges, comme nous la détaillons sur notre page sécurité de vos données.

Pipeline DevOps : de la veille au correctif séparé

Concrètement : SBOM attaché à chaque artefact, veille automatisée (CVE, avis du CERT-FR) croisée avec les SBOM, branches de maintenance pour livrer un correctif sans la prochaine fonctionnalité, artefacts signés, journalisation des accès. Ce chantier d’infrastructure, DevOps et sécurité web se greffe sur une chaîne existante (GitLab CI, GitHub Actions, Jenkins).

Sanctions : ce que prévoit l’article 64

Selon l’article 64 §10 [1][8], les microentreprises et petites entreprises ne sont pas sanctionnées pour le seul dépassement du délai de 24 h, et les intendants de logiciels ouverts échappent aux amendes. L’obligation de signaler demeure.

Questions fréquentes

Préparer votre processus CRA avant le premier incident

Depuis le 11 septembre 2026, le Cyber Resilience Act exige surtout que vous sachiez réagir vite. Trois chantiers sont prioritaires : qualifier votre statut de fabricant produit par produit, tenir un SBOM par version livrée, et formaliser un runbook avec des personnes habilitées sur la plateforme ENISA.

Chez iones, nous accompagnons agences, ESN et éditeurs sur ces trois volets, en marque blanche si besoin : inventaire et qualification avec notre offre d’audit et conseil, SBOM et veille intégrés au pipeline, correctifs livrés dans le cadre de la TMA. Vous voulez faire le point sur votre exposition ? Contactez-nous : réponse sous 48 à 72 h, échange sans engagement, sous NDA.