Présentation du Cyber Resilience Act

Qu’est-ce que le Cyber Resilience Act

Il s’agit d’un règlement européen qui vise à renforcer la cybersécurité des produits numériques au sein de l’Union. Ce règlement s’applique à tous les produits comportant un élément numérique (définition dans la suite de l’article) en imposant un cadre juridique et des obligations aux fabricants, importateurs et distributeurs tout au long du cycle de vie des produits. Si ce règlement n’est pas appliqué, le produit ne pourra pas bénéficier du marquage CE.

Vous trouverez des informations relatives à cette réglementation sur le site du gouvernement.

Calendrier

Le Cyber Resilience Act entrera progressivement en vigueur entre juin 2026 et décembre 2027. Voici les trois dates clefs à retenir:

• Juin 2026 – décembre 2026 : accréditation et début de la notification, par l’ANSSI, des organismes d’évaluation.

• Septembre 2026 : les fabricants notifient les vulnérabilités activement exploitées et les incidents graves via la plateforme ENISA au CSIRTs coordinateurs nationaux, c’est-à-dire le CERT-FR pour la France.

• Décembre 2027 : les produits mis sur le marché sont conformes au CRA et les autorités de surveillance de marché opèrent des contrôles, pour la France c’est l’ANFR.

Pourquoi se conformer à la réglementation?

• C’est la loi, si le règlement n’est pas appliqué, il n’est pas possible pour le fabricant de garantir la conformité de son produit, il ne pourra donc pas être vendu

• Des amendes sont prévues pour non respect de la réglementation, ainsi que des restrictions de mise sur le marché et la publication des manquements

• Sans conformité pas de marquage CE et donc impossibilité de vendre le produit sur le marché européen

Qu’est-ce qu’un produit avec un élément numérique

C’est un produit défini comme « produit logiciel ou matériel et leurs solutions de traitement de données à distance, y compris les composants logiciels ou matériels mis sur le marché séparément ».

Les produits sont classés en quatre catégories en fonction de leur importance:

• La catégorie par défaut contient tous les produits avec un élément numérique de faible importance: balance connectées, smartphone, ordinateur…

• Produit important de Classe 1: 9 types de produits : produits SSI (ex : IGC, SIEM, gestionnaires mots de passe…), numériques (ex : operating systems, routeurs, navigateurs), sectoriels (ex : domotique, jouets.)

• Produit important de Classe 2: 4 types de produits : hyperviseurs, firewalls/IDS/IPS, microprocesseurs et microcontrôleurs (« tamper resistant »)

• Produit Critique: 3 types de produits : dispositifs matériels avec boitiers de sécurité (comme les Hardware Security Module, HSM), cartes à puce ou similaire, passerelles pour compteurs intelligents

Il est important pour le fabricant ou le distributeur d’un produit de sélectionner sa fonction principale afin de savoir à quelle catégorie il appartient.

Le document FAQ définit les produits avec un élément numérique de la façon suivante:

• Les logiciels pouvant être téléchargés et installés sur un appareil
• Les logiciels destinés à être intégrés dans un système d’information électronique
• Les logiciels commercialisés avec un produit matériel
• Divers types de matériel, les circuits intégrés, les cartes mères, les capteurs, les smartphones, les ordinateurs portables, les réfrigérateurs connectés, les appareils IoT industriels, les machines

Procédure d’évaluation

En fonction de la catégorie du produit il est possible d’effectuer différentes procédures d’évaluation:

• Module A : une auto-évaluation et déclaration de conformité sont effectuées par le fabricant (ici, pas de tiers impliqué) .
• Module B + C : un organisme notifié examine la conception et le développement du produit, avec des tests périodiques, et le fabricant déclare la conformité.
• Module H : un organisme notifié examine la performance globale du système de contrôle de la qualité, avec des tests et vérifications périodiques, et le fabricant déclare la conformité.

Qu’est-ce qui est demandé?

1. Périmètre & classification produit

   • Définir si le produit est soumis à la CRA
   • Choisir la fonction principale du produit
   • Définir la catégorie du produit
   • Documenter le cycle de vie du produit

2. Justifier de la sécurité du produit dès sa conception (Security by design)

   • Analyse de risques cybersécurité réalisée
   • Surface d’attaque identifiée et réduite
   • Principe du moindre privilège appliqué
   • Mécanismes d’authentification sécurisés
   • Communications chiffrées (TLS ou équivalent)
   • Sécurisation des interfaces (API, ports, debug désactivé en prod)
   • Secure boot / intégrité du firmware (si applicable)
   • Mécanismes anti-reverse engineering (si pertinent)

3. Gestion des vulnérabilités

   • Processus de réception des vulnérabilités (PSIRT ou équivalent)
   • Canal de divulgation responsable
   • SLA de correction défini selon criticité
   • Process de patching établi (OTA ou manuel)
   • Historique des vulnérabilités suivi
   • Tests de non-régression sécurité après correctif

4. Supply chain logicielle

   • Inventaire des dépendances (SBOM disponible)
   • Versions des dépendances figées et traçables
   • Scan de vulnérabilités des dépendances automatisé
   • Politique de mise à jour des librairies tierces
   • Validation des composants open-source utilisés

5. Documentation technique

   • Architecture système documentée
   • Modèle de menace (threat modeling) disponible
   • Résultats des tests de sécurité documentés
   • Process de développement sécurisé décrit
   • Journal des versions produit maintenu
   • Logs de sécurité et mécanismes d’audit activés

6. Évaluation de conformité

   • Module d’évaluation identifié (A / B+C / H selon cas)
   • Auto-évaluation réalisée OU organisme notifié impliqué
   • Rapport d’évaluation disponible
   • Déclaration UE de conformité rédigée
   • Dossier technique complet prêt pour inspection

7. Marquage CE

   • Conditions d’apposition du marquage CE validées
   • Produit conforme avant mise sur le marché
   • Documentation accessible aux autorités

8. Obligations post-market

   • Process de surveillance sécurité actif
   • Politique de mises à jour maintenue dans le temps
   • Durée de support sécurité définie et communiquée
   • Process de notification des incidents majeurs
   • Capacité de retrait ou mise à jour forcée si nécessaire

9. Organisation & gouvernance

   • Responsabilité sécurité clairement assignée
   • Process interne de gestion CRA défini
   • Formation équipes dev / ops à la sécurité produit
   • Audit interne périodique planifié

10. Point de contrôle final (go/no-go)

    • Tous les risques critiques résiduels acceptés formellement
    • Aucun produit livré sans patch sécurité connu manquant
    • Dossier technique prêt pour inspection UE
    • Conformité continue assurée (pas seulement initiale)

Dans les faits?

Pas de panique si vous n’avez pas encore commencé à vous intéresser au CRA. Dans un premier temps, il n’y aura pas de caractère obligatoire à s’y soumettre ; tout commence réellement en décembre 2027.

Ce n’est pas une raison pour ne rien faire. D’ici là, il faut commencer à cartographier l’ensemble de son infrastructure et de ses partenaires, générer le SBOM, mettre en place le suivi des vulnérabilités et définir la fonction principale de son produit.

Il est aussi primordial de réfléchir à la façon de mettre à jour ses produits déjà commercialisés. L’application d’une mise à jour de sécurité ou l’ajout/la modification d’une fonction va entraîner l’obligation d’être compatible avec la réglementation.

Mais pas de souci, nous sommes là pour aider. Vous pouvez nous contacter si vous avez besoin de support et d’accompagnement.