Cyber Resilience Act 2026 : Guide Anticipation Produits C...

Sécuriser l'écosystème des produits numériques

Le Cyber Resilience Act (CRA), adopté en 2024, représente une révolution dans la réglementation de la cybersécurité des produits. Pour la première fois, l'Union européenne impose des exigences de sécurité obligatoires pour tous les produits comportant des éléments numériques, qu'il s'agisse de logiciels autonomes, d'objets connectés (IoT) ou d'équipements industriels.

Obligations de signalement des vulnérabilités et incidents

Le Cyber Resilience Act introduit un régime de signalement des vulnérabilités et incidents de sécurité qui constitue l'une des innovations majeures du règlement. Contrairement aux obligations sectorielles existantes (NIS 2, DORA), le CRA crée une obligation transversale qui s'applique à l'ensemble des fabricants de produits comportant des éléments numériques, indépendamment du secteur économique concerné.

Les fabricants sont tenus de notifier à l'ENISA (Agence de l'Union européenne pour la cybersécurité) toute vulnérabilité activement exploitée dans leurs produits dans un délai de 24 heures suivant la prise de connaissance. Cette notification précoce doit être suivie d'un rapport intermédiaire sous 72 heures, puis d'un rapport final complet dans les 14 jours décrivant la nature de la vulnérabilité, les mesures correctives prises et les éventuelles divulgations aux tiers concernés.

En parallèle, les incidents ayant un impact significatif sur la sécurité des produits doivent également être déclarés selon le même calendrier. La notion d'impact significatif recouvre notamment les incidents compromettant la confidentialité, l'intégrité ou la disponibilité du produit, ou permettant un accès non autorisé aux données des utilisateurs. Les fabricants doivent aussi informer leurs clients de façon proactive dès lors qu'un incident les concerne directement.

Pour les équipes de sécurité, cette obligation implique la mise en place de processus formels de gestion des vulnérabilités et de surveillance continue : programme de bug bounty ou de divulgation coordonnée des vulnérabilités (CVD), intégration avec le projet Open Source Security Foundation (OpenSSF), alimentation des bases CVE/NVD, et coordination avec les CERT nationaux. L'absence de ces mécanismes constitue une non-conformité sanctionnable.

Cycle de vie des produits : durée de support et fin de vie

L'une des dispositions les plus structurantes du Cyber Resilience Act concerne les obligations de support sur la durée de vie du produit. Le règlement impose aux fabricants de fournir des mises à jour de sécurité pendant une période couvrant l'ensemble de la durée d'utilisation attendue du produit, avec un minimum de cinq ans sauf si la durée de vie effective est inférieure.

Cette exigence bouleverse les modèles économiques de nombreux secteurs. Pour les éditeurs de logiciels, cela signifie maintenir des branches de maintenance actives bien au-delà des cycles commerciaux habituels. Pour les fabricants d'équipements IoT ou industriels, cela implique de planifier dès la conception les mécanismes de mise à jour et d'allouer les ressources nécessaires sur une décennie ou plus.

La notification de fin de vie constitue une obligation distincte : les fabricants doivent informer les utilisateurs au moins un an avant la cessation du support de sécurité. Cette information doit inclure les risques résiduels et les alternatives disponibles. Le CRA prévoit également la possibilité pour les fabricants de transférer les obligations de support à un tiers (distributeur, intégrateur) sous réserve d'un accord contractuel explicite et d'une information claire des utilisateurs finaux.

En pratique, les organisations qui achètent des produits numériques doivent désormais exiger contractuellement la fourniture d'un engagement de support formalisé, incluant la durée garantie, les conditions de mise à jour et la procédure de notification de fin de vie. Ces éléments deviennent des critères de sélection des fournisseurs et doivent figurer dans les politiques achats et dans les questionnaires d'évaluation des prestataires.

Erreurs courantes dans la mise en conformité CRA

L'expérience des premières phases de préparation au Cyber Resilience Act révèle plusieurs erreurs récurrentes que les organisations doivent anticiper pour éviter de compromettre leur démarche de conformité.

Sous-estimation du périmètre produit : De nombreuses entreprises interprètent le CRA comme un règlement dédié aux objets connectés grand public. En réalité, le périmètre est très large et inclut les logiciels de bureau, les applications mobiles, les solutions SaaS, les composants de firmware et les bibliothèques logicielles. Toute organisation commercialisant des logiciels en Europe doit évaluer si elle entre dans le champ du règlement, y compris via des modèles de distribution indirects (OEM, white-label).

Confusion entre les classes de risque : Le CRA distingue les produits par défaut (classe de base), les produits importants de classe I et les produits importants de classe II. Cette classification détermine la procédure d'évaluation de la conformité applicable : auto-évaluation pour la classe de base, audit tierce partie pour les classes I et II. Une mauvaise classification expose à des sanctions lors des contrôles de marché et peut invalider la déclaration de conformité UE.

SBOM insuffisant ou non maintenu : Le Software Bill of Materials est souvent créé en début de projet puis négligé lors des mises à jour. Or le CRA exige que le SBOM soit précis et à jour en permanence, couvrant toutes les dépendances directes et transitives. Les outils d'analyse de composition logicielle (SCA) comme OWASP Dependency-Track, Syft ou SPDX doivent être intégrés dans les pipelines CI/CD pour maintenir automatiquement l'inventaire des composants.

Absence de test de sécurité documenté : La conformité CRA requiert non seulement la réalisation de tests de sécurité (SAST, DAST, pentest) mais aussi leur documentation complète avec les résultats, les remédiations appliquées et les risques résiduels acceptés. Sans cette traçabilité, l'organisation ne pourra pas démontrer sa conformité lors d'un audit ou d'une enquête d'autorité de surveillance.

Objectifs du règlement

Le CRA poursuit quatre objectifs principaux : garantir que les produits numériques sont sécurisés tout au long de leur cycle de vie, permettre aux utilisateurs de faire des choix éclairés grâce à une information transparente, harmoniser les exigences de cybersécurité au sein du marché unique, et réduire le coût global des cyberattaques en Europe.

Le règlement complète NIS 2 (obligations des opérateurs) et l'AI Act (systèmes d'IA). Ces textes forment ensemble un cadre cohérent de résilience numérique européenne.