Le 11 septembre 2026, une échéance est passée relativement inaperçue en dehors des équipes produit : les premières obligations du Cyber Resilience Act (CRA) sont devenues applicables. Depuis cette date, tout fabricant qui commercialise dans l’Union européenne un logiciel ou un équipement connecté doit signaler en 24 heures les vulnérabilités activement exploitées dans ses produits. Et ce n’est qu’une étape : le 11 décembre 2027, l’ensemble du règlement s’appliquera, avec exigences de sécurité dès la conception, gestion des vulnérabilités sur toute la durée de support et marquage CE.
Pour un éditeur, un intégrateur ou un fabricant d’équipements, le CRA n’est pas un texte de plus à classer : il conditionne l’accès au marché européen. Pour un DSI ou un RSSI côté client, il change la façon d’acheter et d’évaluer les produits numériques. Voici ce que dit le texte, qui est concerné, le calendrier et un plan d’action concret.
Qu’est-ce que le Cyber Resilience Act ?
Le Cyber Resilience Act est le règlement (UE) 2024/2847, adopté en octobre 2024, publié au Journal officiel le 20 novembre 2024 et entré en vigueur le 10 décembre 2024. Comme il s’agit d’un règlement et non d’une directive, il s’applique directement dans tous les États membres, sans loi de transposition.
Son objet est simple à énoncer : imposer des exigences de cybersécurité horizontales à tous les produits comportant des éléments numériques mis sur le marché européen, c’est-à-dire les logiciels et les matériels dont l’usage prévu implique une connexion, directe ou indirecte, à un appareil ou à un réseau. Le CRA s’inscrit dans la logique du « nouveau cadre législatif » européen, celle qui régit déjà la sécurité des jouets ou des équipements électriques : exigences essentielles, évaluation de la conformité, déclaration UE de conformité et marquage CE.
Là où la directive NIS 2 vise les organisations (entités essentielles et importantes) et leur gestion des risques, le CRA vise les produits et ceux qui les fabriquent, les importent ou les distribuent. Les deux textes sont complémentaires : une entité soumise à NIS 2 doit sécuriser sa chaîne d’approvisionnement, et le CRA lui donne des garanties minimales sur les produits qu’elle achète.
Champ d’application : qui est concerné ?
Le périmètre est très large. Sont notamment concernés :
Les logiciels commercialisés : applications, systèmes d’exploitation, firmwares, logiciels embarqués, y compris les solutions de traitement de données à distance indispensables au fonctionnement du produit.
Les matériels connectés : routeurs, caméras IP, objets connectés grand public et industriels, composants dotés de fonctions de sécurité.
Les opérateurs économiques : fabricants (principaux débiteurs des obligations), mais aussi importateurs et distributeurs, qui doivent vérifier la conformité des produits qu’ils mettent sur le marché.
Certains secteurs déjà couverts par une réglementation spécifique sont exclus : dispositifs médicaux, véhicules à moteur, aviation civile, équipements marins, ainsi que les produits développés exclusivement pour la défense ou la sécurité nationale. Le SaaS pur relève quant à lui principalement de NIS 2.
Le cas de l’open source a fait l’objet de longs débats. Le logiciel libre n’entre dans le champ que lorsqu’il est fourni dans le cadre d’une activité commerciale. Le texte crée en outre la figure du steward de logiciels open source (fondations, organisations qui soutiennent durablement des projets destinés à un usage commercial), soumis à un régime allégé : politique de cybersécurité documentée, coopération avec les autorités, sans amendes administratives.
Les classes de produits
Tous les produits ne sont pas traités de la même manière. Le règlement distingue quatre niveaux :
Catégorie par défaut : la grande majorité des produits, pour lesquels une autoévaluation par le fabricant suffit.
Produits importants de classe I (annexe III) : par exemple les systèmes de gestion des identités et des accès privilégiés, gestionnaires de mots de passe, navigateurs, antivirus, VPN, SIEM, systèmes d’exploitation, routeurs et commutateurs. L’autoévaluation n’est possible que si les normes harmonisées sont appliquées intégralement.
Produits importants de classe II : hyperviseurs et environnements d’exécution de conteneurs, pare-feux, systèmes de détection et de prévention d’intrusion, microprocesseurs inviolables. Une évaluation par un tiers est requise.
Produits critiques (annexe IV) : boîtiers de sécurité matériels, passerelles de compteurs intelligents, cartes à puce et éléments sécurisés, susceptibles d’être soumis à une certification européenne de cybersécurité.
Les obligations des fabricants
L’annexe I du règlement fixe 21 exigences essentielles, réparties en deux blocs : 13 exigences de sécurité du produit et 8 exigences de gestion des vulnérabilités. Concrètement, un fabricant devra notamment :
Évaluer les risques de cybersécurité du produit et en tenir compte dès la conception, le développement et la production (security by design).
Livrer une configuration sécurisée par défaut, sans vulnérabilité exploitable connue au moment de la mise sur le marché, avec la possibilité de revenir à l’état d’origine.
Protéger les données (confidentialité, intégrité), limiter la surface d’attaque et journaliser les activités pertinentes.
Tenir un SBOM (Software Bill of Materials) dans un format courant et lisible par machine, couvrant au minimum les dépendances de premier niveau.
Gérer les vulnérabilités pendant toute la période de support : correctifs sans délai, diffusés gratuitement, séparément des mises à jour fonctionnelles quand c’est techniquement possible, et politique de divulgation coordonnée des vulnérabilités.
Fixer une période de support d’au moins cinq ans, sauf si la durée d’utilisation prévue du produit est plus courte, et l’indiquer clairement à l’acheteur.
Constituer la documentation technique (annexe VII), rédiger la déclaration UE de conformité et apposer le marquage CE.
Le SBOM n’a rien d’exotique pour une équipe DevSecOps : des outils open source comme Trivy génèrent un inventaire des composants au format CycloneDX ou SPDX, et un scanner comme Grype le confronte aux bases de vulnérabilités. L’enjeu est de l’intégrer systématiquement dans la chaîne CI/CD plutôt que de le produire à la main avant un audit.
Déclaration des vulnérabilités : en vigueur depuis le 11 septembre 2026
L’article 14 est la première obligation opérationnelle du CRA. Le fabricant doit notifier deux types d’événements : les vulnérabilités activement exploitées contenues dans ses produits et les incidents graves ayant un impact sur leur sécurité. Les délais courent à partir du moment où il en a connaissance :
Alerte précoce sous 24 heures.
Notification sous 72 heures, avec une première évaluation et les mesures correctives ou d’atténuation disponibles.
Rapport final au plus tard 14 jours après la disponibilité d’un correctif pour une vulnérabilité exploitée, ou un mois après la notification pour un incident grave.
Les notifications passent par la plateforme unique de déclaration (Single Reporting Platform) opérée par l’ENISA et ouverte le 11 septembre 2026. Le fabricant déclare une seule fois au CSIRT coordinateur de l’État membre de son établissement principal, qui relaie l’information aux CSIRT des autres pays où le produit est distribué ; l’ENISA la reçoit simultanément, sauf circonstances exceptionnelles. À son lancement, la plateforme fonctionne uniquement via un formulaire web en anglais, sans API, avec une authentification EU Login à double facteur. Le fabricant doit aussi informer les utilisateurs concernés de l’incident et des mesures à prendre.
Point essentiel : cette obligation de déclaration s’applique à tous les produits concernés déjà sur le marché, y compris ceux mis en vente bien avant décembre 2027. Un éditeur qui maintient un produit vieillissant n’y échappe pas.
Calendrier d’application
10 décembre 2024 : entrée en vigueur du règlement.
11 juin 2026 : application des règles relatives aux organismes notifiés, chargés des évaluations de conformité par un tiers.
11 septembre 2026 : obligations de déclaration des vulnérabilités activement exploitées et des incidents graves (article 14) et ouverture de la plateforme de l’ENISA.
11 décembre 2027 : application complète : exigences essentielles, évaluation de la conformité, marquage CE. Les obligations de déclaration des stewards open source s’appliquent également à cette date.
11 juin 2028 : expiration des certificats de cybersécurité délivrés au titre d’autres législations européennes.
Les produits mis sur le marché avant le 11 décembre 2027 ne sont soumis à l’ensemble des exigences que s’ils font l’objet d’une modification substantielle après cette date. Les obligations de déclaration, elles, s’appliquent sans distinction.
Sanctions
Les montants s’alignent sur ceux du RGPD et de NIS 2 :
jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial pour le non-respect des exigences essentielles et des obligations des articles 13 et 14 ;
jusqu’à 10 millions d’euros ou 2 % pour les autres obligations ;
jusqu’à 5 millions d’euros ou 1 % pour la fourniture d’informations inexactes ou trompeuses aux autorités.
Les micro et petites entreprises ne peuvent pas être sanctionnées pour un retard sur l’alerte précoce de 24 heures, mais restent tenues par la notification à 72 heures et le rapport final. Au-delà des amendes, les autorités de surveillance du marché peuvent exiger le retrait ou le rappel d’un produit non conforme, ce qui coûte souvent bien plus cher.
CRA, NIS 2, RGPD : comment s’articulent-ils ?
NIS 2 encadre la gestion des risques et la notification des incidents des organisations essentielles et importantes. Une entreprise peut être soumise aux deux textes : à NIS 2 en tant qu’opérateur, au CRA en tant qu’éditeur.
Le RGPD protège les données personnelles ; le CRA rend plus concrète l’exigence de sécurité « dès la conception » pour les produits qui en traitent.
Le Cybersecurity Act (règlement 2019/881) organise des schémas de certification volontaires ; le CRA peut s’appuyer sur eux, notamment pour les produits critiques.
Côté client, le CRA devient un levier d’achat : lors d’un appel d’offres, un DSI peut désormais exiger la déclaration UE de conformité, la période de support annoncée, la politique de divulgation des vulnérabilités et un SBOM. Un outil de GRC open source comme CISO Assistant aide à suivre ces exigences fournisseur aux côtés des autres référentiels de conformité.
Plan d’action pour les fabricants et éditeurs
1. Inventorier et qualifier les produits. Listez tous les produits comportant des éléments numériques que vous mettez sur le marché européen, y compris les anciennes versions encore maintenues. Pour chacun, déterminez votre rôle (fabricant, importateur, distributeur) et la classe du produit : par défaut, important de classe I ou II, critique. Cette qualification décide de la procédure d’évaluation de la conformité.
2. Rendre la déclaration à 24 heures opérationnelle. C’est l’obligation déjà applicable. Identifiez votre CSIRT coordinateur, créez les comptes EU Login et désignez les représentants sur la plateforme de l’ENISA, rédigez une procédure de qualification « vulnérabilité activement exploitée » et prévoyez une astreinte capable de produire l’alerte précoce, y compris le week-end. Un exercice à blanc permet de vérifier que la chaîne support, R&D, juridique et direction tient les délais.
3. Formaliser l’analyse de risques produit. Le CRA exige une évaluation documentée des risques de cybersécurité, intégrée à la documentation technique. Une méthode structurée comme EBIOS Risk Manager fournit un cadre reconnu pour identifier scénarios de menace et mesures de sécurité.
4. Industrialiser la gestion des vulnérabilités. Génération automatique du SBOM à chaque build, surveillance continue des dépendances, politique de divulgation coordonnée publiée (avec un point de contact, par exemple via un fichier security.txt), processus de publication de correctifs et d’avis de sécurité.
5. Définir les périodes de support. Fixez pour chaque produit une durée de support cohérente avec sa durée d’utilisation prévue, d’au moins cinq ans par défaut, et anticipez le coût de maintenance correspondant dans votre modèle économique.
6. Préparer l’évaluation de la conformité. Suivez les travaux de normalisation européens sur les normes harmonisées, identifiez dès maintenant un organisme notifié si vos produits relèvent de la classe II ou de la catégorie critique, et commencez à constituer la documentation technique produit par produit.
7. Encadrer la chaîne d’approvisionnement. Les composants tiers, y compris open source, font partie de votre produit : exercez une diligence raisonnable sur leur origine, leur maintenance et leurs vulnérabilités, et prévoyez des clauses contractuelles avec vos fournisseurs.
Bonnes pratiques
Ne pas attendre 2027 : la déclaration des vulnérabilités est déjà exigible, et la mise en conformité complète d’un portefeuille de produits prend plusieurs cycles de développement.
Désigner un pilote : la conformité CRA touche le produit, la R&D, le support, le juridique et les achats ; sans responsable identifié, elle se dilue.
Mutualiser avec NIS 2 et ISO 27001 : gestion des incidents, gestion des vulnérabilités et sécurité de la chaîne d’approvisionnement reposent sur les mêmes processus.
Automatiser les preuves : SBOM, résultats de scans, journaux de correctifs et avis de sécurité produits par la CI/CD constituent une documentation technique à jour sans effort supplémentaire.
Contribuer à l’open source dont vous dépendez : un composant critique non maintenu devient votre problème de conformité ; soutenir les projets en amont est aussi une mesure de réduction des risques.
Côté acheteur, intégrer les exigences du CRA dans les cahiers des charges et les contrats : période de support, SBOM, délais de correction et contact sécurité.
Conclusion
Le Cyber Resilience Act fait passer la cybersécurité des produits numériques du statut de bonne pratique à celui de condition d’accès au marché européen. Depuis le 11 septembre 2026, les fabricants doivent déjà savoir détecter, qualifier et déclarer en 24 heures une vulnérabilité exploitée ; d’ici le 11 décembre 2027, ils devront démontrer la sécurité dès la conception, tenir un SBOM, assurer cinq ans de correctifs au minimum et apposer le marquage CE. Les éditeurs qui structurent dès maintenant leur gestion des vulnérabilités et leur documentation aborderont l’échéance sereinement, et pourront en faire un argument commercial auprès de clients eux-mêmes soumis à NIS 2.
À lire aussi : NIS 2 : ce que la directive change et où en est la loi Résilience en France · Les certifications ISO en sécurité informatique
