Si vous fabriquez un appareil connecté et que vous le vendez dans l’UE, le Cyber Resilience Act (CRA) s’applique à vous. Point final. Peu importe où vous fabriquez, où votre entreprise est enregistrée ou si vous avez un bureau européen.
Le règlement est entré en vigueur le 10 décembre 2024. La plupart des équipes ont marqué 2027 comme échéance et n’ont pas encore bougé. Le problème, c’est que 2027 est la date d’application finale, pas la seule. La première échéance ferme est le 11 septembre 2026, date à laquelle le signalement obligatoire des vulnérabilités entre en vigueur. Vous ne pouvez pas mettre en place les processus que ce signalement exige en un sprint. Il faut qu’ils tournent plusieurs mois avant l’échéance, pour disposer des preuves opérationnelles à présenter aux autorités quand elles les demanderont.
Ce guide couvre ce que vous devez réellement faire, dans l’ordre où vous devez le faire.
Votre produit est-il concerné ?
Le CRA s’applique à tout matériel ou logiciel qui se connecte, directement ou indirectement, à un appareil ou à un réseau, mis sur le marché de l’UE dans un contexte commercial.
Votre capteur intelligent, votre gateway industrielle, votre outil de mise à jour de firmware et l’OS embarqué de votre thermostat sont tous concernés. Le test est simple : s’il est livré dans l’UE et qu’il se connecte à quelque chose, il entre dans le champ d’application.
Ce qui est exclu :
- Les dispositifs médicaux et les véhicules à moteur (couverts par leurs propres réglementations sectorielles)
- Les logiciels open source non monétisés
- Les solutions purement SaaS et PaaS qui ne sont pas indispensables au fonctionnement d’un appareil concerné
- Les sites web qui ne prennent pas en charge le traitement à distance pour un appareil concerné
Si vous êtes importateur ou distributeur plutôt que fabricant d’origine, vous avez tout de même des obligations. Vous devrez peut-être vérifier le marquage CE, conserver la documentation et, dans certains cas, assumer l’intégralité des responsabilités du fabricant si vous modifiez substantiellement le produit avant de le mettre sur le marché.
Un point que beaucoup d’équipes oublient : les exigences de cybersécurité de la directive sur les équipements radioélectriques (RED) s’appliquent déjà depuis le 1er août 2025 aux équipements radio connectés à Internet. Si votre appareil utilise le Wi-Fi ou le Bluetooth et que l’échéance d’août 2025 est passée sans évaluation RED, traitez ce point avant tout le reste. La liste RED est plus courte que celle du CRA, mais elle est déjà en retard.
Étape 1 : classez votre produit
Le CRA répartit les produits en quatre catégories de risque. Votre catégorie détermine comment vous prouvez votre conformité.
Par défaut (environ 90 % de tous les produits) Appareils connectés standards, la plupart de l’IoT grand public, les capteurs industriels à faible risque. L’auto-évaluation est autorisée. Vous évaluez vous-même votre produit au regard des exigences essentielles et signez une déclaration de conformité.
Important : Classe I Produits à risque plus élevé, dont les navigateurs, les gestionnaires de mots de passe, les VPN et les logiciels de gestion réseau. L’auto-certification au regard d’une norme harmonisée est autorisée, ou vous pouvez recourir à un organisme notifié.
Important : Classe II Produits présentant un risque de sécurité important : pare-feu industriels, systèmes de détection d’intrusion, microprocesseurs, routeurs, modems, gateways pour compteurs intelligents. Une évaluation par un organisme notifié tiers est requise dans la plupart des cas.
Critique Produits dont dépendent les infrastructures critiques. Exigent un schéma européen de certification de cybersécurité. Le règlement d’exécution adopté en novembre 2025 a précisé quels produits relèvent de cette catégorie.
Consultez les annexes III et IV du règlement (UE) 2024/2847 pour les listes définitives.
Un problème pratique avec la Classe II et la catégorie Critique : la capacité des organismes notifiés dans l’UE est limitée. Les équipes qui attendent fin 2026 ou 2027 pour commencer feront face à des files d’attente. La Commission européenne vise à disposer d’organismes notifiés en place d’ici le 11 décembre 2026, mais la disponibilité pourrait ne pas répondre à la demande. Commencez tôt.
Étape 2 : constituez dès maintenant votre Software Bill of Materials
L’exigence de SBOM figure à l’annexe I, partie II du CRA. Les fabricants doivent identifier et documenter tous les composants de leurs produits, y compris une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau.
La raison de le faire avant septembre 2026 est opérationnelle, pas bureaucratique. Quand une vulnérabilité activement exploitée est divulguée publiquement, vous avez 24 heures pour la signaler à l’ENISA et à votre CSIRT national. Pour tenir cette échéance, vous devez savoir en quelques minutes si votre produit utilise le composant affecté. Sans SBOM ni suivi automatisé des vulnérabilités, vous passerez ces 24 heures à fouiller manuellement dans les images de firmware.
Ce que votre SBOM doit couvrir :
- Chaque composant logiciel, de l’OS aux modules de firmware
- Les composants propriétaires et open source
- Les numéros de version et les informations de licence
- Les vulnérabilités connues associées à chaque composant
- Les dépendances de premier niveau au minimum ; le suivi complet des dépendances transitives lorsque c’est faisable
Le CRA n’impose pas encore de format précis, mais exige un format « couramment utilisé et lisible par machine ». SPDX et CycloneDX satisfont tous deux à cette exigence. La Commission européenne devrait préciser les formats par des actes d’exécution en 2026. Choisissez-en un dès maintenant et intégrez-le à votre pipeline CI/CD.
Vous n’avez pas besoin de publier votre SBOM. Les autorités de surveillance du marché peuvent le demander, et vous devez pouvoir le fournir rapidement. Conservez-le dans votre dossier de documentation technique.
Pour les appareils qui reçoivent des mises à jour OTA, le processus de SBOM doit rester à jour. Chaque version de firmware qui ajoute ou met à jour un composant exige un SBOM actualisé avant son déploiement.
Étape 3 : intégrez la sécurité dès le départ
C’est là que la plupart des équipes IoT ont le plus de chemin à parcourir. Le CRA exige une sécurité dès la conception, pas une sécurité rajoutée juste avant un audit de marquage CE.
Lors de la conception :
- Pas de mots de passe par défaut. Les appareils doivent être livrés soit en obligeant l’utilisateur à définir un identifiant unique, soit avec des identifiants uniques au matériel, générés par appareil.
- Réduisez la surface d’attaque. Limitez les interfaces, services et ports exposés à ce dont le produit a réellement besoin pour fonctionner.
- Modélisation des menaces avant la mise en route du matériel, pas après.
- Secure boot pour vérifier l’intégrité du firmware dès la mise sous tension.
- Chiffrement des données en transit et au repos lorsque le modèle de menace du produit le justifie.
Pendant le développement :
- Un cycle de développement logiciel sécurisé (SSDL) avec des points de contrôle de sécurité lors de la revue de code, de l’analyse statique et de l’analyse des dépendances, intégrés au CI/CD.
- Aucune vulnérabilité connue de gravité critique ou élevée dans les composants au moment de la sortie. Le CRA exige que les produits soient mis sur le marché « sans vulnérabilités exploitables connues ».
- Tests au regard de votre propre modèle de menace avant le déploiement.
Après la mise sur le marché :
- Les mises à jour de sécurité doivent être disponibles pour les utilisateurs pendant au moins 5 ans à compter de la mise sur le marché du produit, ou pendant la durée d’utilisation prévue si elle est plus longue.
- Une fois une mise à jour de sécurité publiée, elle doit rester disponible pendant au moins 10 ans à compter de cette date de publication, ou pendant la durée de support restante.
- Mécanismes de mise à jour automatique, ou notification claire aux utilisateurs lorsque des mises à jour sont disponibles.
- Une date de fin de support publiée, pour que les utilisateurs sachent quand les correctifs cesseront.
Étape 4 : mettez en place la gestion des vulnérabilités et le signalement des incidents
C’est l’échéance de septembre 2026. À partir du 11 septembre 2026, les fabricants doivent signaler à l’ENISA et au CSIRT national compétent dans les 24 heures suivant la découverte d’une vulnérabilité activement exploitée dans tout produit actuellement présent sur le marché de l’UE.
Le calendrier de signalement :
| Déclencheur | Échéance | Ce qu’il faut transmettre |
|---|---|---|
| Vulnérabilité activement exploitée découverte | 24 heures | Alerte précoce à l’ENISA et au CSIRT national |
| Incident de cybersécurité grave affectant la sécurité du produit | 24 heures | Notification d’alerte précoce |
| Après l’alerte précoce | 72 heures | Notification de vulnérabilité avec évaluation initiale de l’impact |
| Une fois la mesure d’atténuation disponible | 14 jours | Rapport complet : description, versions affectées, étapes d’atténuation |
Cela couvre les produits anciens. Si vous avez livré une gateway IoT en 2019 et qu’elle est toujours sur le marché de l’UE le 11 septembre 2026, vous êtes responsable du signalement de ses vulnérabilités selon ces délais.
Les signalements sont adressés à la base de données européenne des vulnérabilités de l’ENISA et au CSIRT national du ou des États membres où le produit est vendu. Ils sont en général transmis aux CSIRT de chaque État membre où le produit est commercialisé.
Ce que vous devez avoir en place avant septembre 2026 :
- Une politique de divulgation coordonnée des vulnérabilités (CVD), publiée et facile à trouver
- Un contact de sécurité surveillé et un fichier security.txt
- Des workflows de triage internes avec une responsabilité claire et des voies d’escalade définies
- Un SBOM et un suivi des dépendances pour pouvoir répondre à « sommes-nous affectés ? » en heures, pas en jours
- Une relation de travail établie avec votre CSIRT national avant d’en avoir besoin
Étape 5 : préparez votre documentation technique
Chaque fabricant doit tenir à jour un dossier de documentation technique. Les autorités de surveillance du marché peuvent le demander à tout moment. Les exigences de contenu figurent à l’annexe VII du CRA.
Votre dossier technique doit inclure :
- La description du produit : nom, version, type, plage de numéros de série
- L’évaluation des risques : votre modèle de menace en cybersécurité et la manière dont vos choix de conception y répondent
- L’architecture de sécurité : comment le produit satisfait aux exigences essentielles
- Le SBOM
- La description du processus de développement sécurisé : normes de codage, processus de revue, méthodologie de test
- La procédure de gestion des vulnérabilités
- Les résultats des tests et des vérifications
- La référence de la déclaration de conformité
Conservez la documentation pendant 10 ans après le retrait du produit du marché. Mettez-la à jour lorsque vous publiez des mises à jour de sécurité.
Étape 6 : réussissez le marquage CE
Le marquage CE au titre du CRA n’est pas le même que le marquage CE au titre des anciennes directives. Vous ne pouvez pas auto-déclarer la conformité et apposer un marquage CE sur un produit de Classe II.
Pour les produits de la catégorie par défaut : l’auto-évaluation est autorisée. Réalisez l’évaluation de la conformité, produisez une déclaration de conformité, apposez le marquage CE.
Pour les produits importants de Classe I : auto-certifiez-vous au regard d’une norme harmonisée, ou recourez à un organisme notifié.
Pour les produits importants de Classe II et critiques : une évaluation par un organisme notifié est requise dans la plupart des cas.
Votre déclaration de conformité doit inclure :
- L’identification du produit (nom, type, lot, numéro de série)
- Le nom et l’adresse du fabricant
- Une déclaration de conformité au règlement (UE) 2024/2847
- Le nom et le numéro de l’organisme notifié, le cas échéant
- Les coordonnées du signataire autorisé
Le marquage CE doit figurer sur le produit, son emballage ou la documentation d’accompagnement si le produit est trop petit pour le porter.
Ce qui fait trébucher la plupart des équipes
Le traiter comme une case à cocher unique. Le CRA exige des processus continus. La surveillance des vulnérabilités, les mises à jour du SBOM et le signalement des incidents s’exécutent en continu aussi longtemps que votre produit est sur le marché.
Ignorer les produits déjà livrés. S’il est encore en vente dans l’UE le 11 septembre 2026, il entre dans le champ du signalement des vulnérabilités. Cela inclut les produits de 2019.
Sous-estimer la portée du SBOM. Une image de firmware typique contient des dizaines ou des centaines de composants. L’inventaire manuel ne tient pas l’échelle. Automatisez la génération du SBOM dans votre pipeline de build dès le départ.
Oublier les obligations liées à la chaîne d’approvisionnement. Les composants tiers comportent un risque qui se répercute sur vous en tant que fabricant. Vos contrats fournisseurs doivent intégrer des obligations de SBOM et des clauses de divulgation des vulnérabilités. Une vulnérabilité dans une bibliothèque fournie par votre fabricant de puce reste de votre responsabilité de signalement.
Supposer que les normes harmonisées arriveront à temps. La normalisation CEN/CENELEC pour le CRA est en cours. Pour les produits exigeant une évaluation par un tiers, les normes peuvent encore être incomplètes au moment où vous devrez certifier. Engagez tôt un organisme notifié pour convenir des preuves qu’il acceptera dans l’intervalle.
Une remarque sur votre plateforme IoT
Une question revient souvent : la plateforme cloud à laquelle votre appareil se connecte influence-t-elle votre conformité au CRA ?
Si vous utilisez une plateforme IoT polyvalente qui n’est pas développée par vous ou pour votre compte, elle ne relève pas directement du CRA. Les solutions purement SaaS et PaaS sont exclues du règlement. Ce qui compte pour votre dossier technique CRA, c’est de documenter la plateforme comme faisant partie de votre chaîne d’approvisionnement, de comprendre les contrôles de sécurité qu’elle applique et de disposer de preuves à présenter aux autorités de surveillance du marché.
Lorsque vous évaluez des plateformes, recherchez un chiffrement documenté au repos et en transit, des contrôles d’accès, une journalisation d’audit, des processus de divulgation des vulnérabilités publiés et une validation de sécurité par un tiers. La certification ISO/IEC 27001, des scores de sécurité indépendants et un portail de sécurité public avec une documentation disponible sont les éléments à exiger. Les plateformes incapables de produire rapidement ces preuves ralentiront votre processus de documentation CRA.
TagoIO détient la certification ISO/IEC 27001, est conforme au RGPD et propose un Security Portal public sur security.tago.io, avec des rapports d’audit, des auto-évaluations de sécurité et une documentation complète disponible sur demande. Si vous utilisez TagoIO dans le pipeline de données de votre appareil, la documentation de sécurité dont vous avez besoin pour l’évaluation de votre chaîne d’approvisionnement s’y trouve.
Calendrier
| Date | Jalon |
|---|---|
| 10 décembre 2024 | Entrée en vigueur du CRA |
| 1er août 2025 | Les exigences de cybersécurité RED s’appliquent aux équipements radio connectés à Internet |
| 11 juin 2026 | Les notifications des organismes d’évaluation de la conformité doivent être en place |
| 11 septembre 2026 | Début des obligations de signalement des vulnérabilités et des incidents |
| 11 décembre 2027 | Toutes les exigences du CRA pleinement applicables |
Ressources
- Règlement (UE) 2024/2847 : le texte du CRA. Commencez par l’annexe I (exigences de sécurité), les annexes III/IV (catégories de produits), l’annexe VII (documentation technique).
- Orientations CRA de l’ENISA : enisa.europa.eu
- IoT Security Foundation : ressources de conformité et correspondance avec les normes de l’ENISA sur iotsecurityfoundation.org
- ETSI EN 303 645 : la norme de sécurité IoT grand public existante, fortement alignée sur les exigences de l’annexe I du CRA
- Orientations CRA de la Commission européenne : publiées pour consultation en mars 2026, couvrent l’interprétation du champ d’application et le soutien aux PME
Cet article reflète l’état du CRA en avril 2026. Les actes d’exécution et les normes harmonisées sont encore en cours de finalisation. Consultez les pages de la stratégie numérique de la Commission européenne pour les mises à jour. Le règlement (UE) 2024/2847 est la source faisant autorité.
