Cyber Resilience Act (CRA) : Guide complet pour la conformité 2026
Tout ce que les fabricants doivent savoir sur le Cyber Resilience Act de l'UE — exigences obligatoires, SBOM, délai de septembre 2026, marquage CE et feuille de route de conformité pour les produits comportant des éléments numériques.
Cyber Resilience Act (CRA) : Guide complet pour la conformité 2026
Le Cyber Resilience Act (Règlement 2024/2847) est le premier règlement horizontal au monde établissant des exigences obligatoires de cybersécurité pour les produits comportant des éléments numériques. Il exige la sécurité dès la conception, des mises à jour de sécurité tout au long du cycle de vie, et une gestion transparente des vulnérabilités pour les produits matériels et logiciels vendus dans l'UE.
L'échéance critique approche : à partir du 11 septembre 2026, les obligations de signalement des vulnérabilités s'appliquent — y compris pour les produits déjà sur le marché.
Si vous fabriquez, importez ou distribuez des produits connectés ou des logiciels en Europe, le CRA vous concerne directement. Ce guide couvre le périmètre complet, les exigences, les actions immédiates pour septembre 2026, et ce que les orientations de la Commission de mars 2026 impliquent pour votre programme de conformité.
Qu'est-ce que le Cyber Resilience Act ?
Le CRA établit des exigences horizontales de cybersécurité pour les produits comportant des éléments numériques tout au long de leur cycle de vie — de la conception et du développement jusqu'à la mise sur le marché et la fin de vie. Il répond à une défaillance fondamentale du marché : la quasi-totalité des produits connectés n'avaient aucune exigence réglementaire de cybersécurité.
Principes fondamentaux :
- Sécurité dès la conception : La cybersécurité doit être intégrée au produit dès le départ — pas ajoutée après coup
- Sécurité par défaut : Les produits doivent être livrés avec des configurations sécurisées par défaut
- Responsabilité sur le cycle de vie : Les fabricants doivent fournir des mises à jour de sécurité pendant la durée de vie prévue (minimum 5 ans)
- Transparence : Les vulnérabilités doivent être signalées et gérées par des processus coordonnés
- Accès au marché : Les produits non conformes ne peuvent pas porter le marquage CE ni être mis sur le marché de l'UE
Le CRA a été publié au Journal officiel le 20 novembre 2024 et est entré en vigueur le 10 décembre 2024.
Qui doit se conformer ?
Le CRA s'applique à trois catégories d'opérateurs économiques :
Fabricants
Toute entité qui conçoit, développe ou produit des produits comportant des éléments numériques — ou les fait concevoir, développer ou produire — et les commercialise sous son propre nom ou sa marque. Si vous distribuez un logiciel sous votre propre marque (même basé sur des composants open source), vous êtes le fabricant au sens du CRA.
Importateurs
Toute entité établie dans l'UE qui met sur le marché un produit d'un fabricant établi hors de l'UE.
Distributeurs
Toute entité dans la chaîne d'approvisionnement (autre que fabricant ou importateur) qui met un produit à disposition sur le marché.
Qu'est-ce qu'un « produit comportant des éléments numériques » ?
Le CRA couvre :
- Produits matériels avec connectivité réseau : dispositifs IoT, routeurs, appareils domestiques intelligents, contrôleurs industriels, composants automobiles
- Logiciels autonomes : Applications, systèmes d'exploitation, micrologiciels, intergiciels, bibliothèques
- Traitement de données à distance : Composants cloud essentiels à la fonction principale d'un produit (pas les services SaaS autonomes)
Les orientations de la Commission de mars 2026 précisent que le logiciel est considéré « mis sur le marché » lorsqu'il est mis à disposition pour la première fois sur le marché de l'UE — y compris par téléchargement ou accès à distance.
Exemptions
- Logiciels open source développés dans un contexte non commercial (voir section Open Source)
- Produits déjà couverts par une législation sectorielle de l'UE (dispositifs médicaux sous le RDM, automobile sous les règlements d'homologation, aviation sous l'AESA)
- Produits développés exclusivement à des fins de sécurité nationale ou de défense
Catégories de produits et évaluation de conformité
Le CRA catégorise les produits selon leur niveau de criticité :
Catégorie par défaut (majorité des produits)
- Évaluation de conformité : Auto-évaluation par le fabricant
- Exemples : La plupart des IoT grand public, logiciels à usage général
- Procédure : Contrôle interne (Module A) selon l'Annexe VIII
Produits importants — Classe I (Annexe III)
- Logiciels de gestion des identités et d'authentification
- VPN, systèmes de gestion de réseau
- Systèmes SIEM
- Gestionnaires de démarrage, micrologiciel BIOS
- Pare-feu, IDS/IPS pour usage non industriel
- Routeurs et modems pour la connectivité internet
- Microprocesseurs et microcontrôleurs avec fonctions de sécurité
- Évaluation : Auto-évaluation avec normes harmonisées OU évaluation par un tiers
Produits importants — Classe II (Annexe III, risque plus élevé)
- Hyperviseurs, systèmes d'exécution de conteneurs
- Pare-feu et IDS/IPS pour usage industriel
- Microprocesseurs/microcontrôleurs résistants aux manipulations
- Évaluation : Évaluation de conformité par un tiers obligatoire
Produits critiques (Annexe IV)
- Dispositifs matériels avec boîtiers de sécurité (HSM, cartes à puce, éléments sécurisés)
- Passerelles de compteurs intelligents dans les systèmes de comptage intelligent
- Évaluation : Certification européenne de cybersécurité requise
État des normes harmonisées : L'ETSI, le CEN et le CENELEC développent des normes harmonisées européennes sur mandat de la Commission — y compris des normes verticales pour les navigateurs, gestionnaires de mots de passe, antivirus, VPN, SIEM et gestionnaires de démarrage. La plupart des normes harmonisées sont attendues d'ici fin 2026. En France, l'ANSSI (Agence nationale de la sécurité des systèmes d'information) publie des orientations sur l'articulation entre le CRA et les référentiels nationaux.
Exigences essentielles de cybersécurité (Annexe I)
Partie I : Exigences applicables aux produits
- Les produits doivent être conçus, développés et produits pour garantir un niveau approprié de cybersécurité
- Les produits doivent être livrés sans vulnérabilités exploitables connues
- Configuration sécurisée par défaut, avec possibilité de réinitialisation aux paramètres d'usine
- Protection contre l'accès non autorisé par des mécanismes de contrôle appropriés
- Protection de la confidentialité des données stockées, transmises ou traitées (chiffrement le cas échéant)
- Protection de l'intégrité des données
- Traitement des seules données nécessaires (minimisation des données)
- Protections de la disponibilité, y compris la résilience face aux attaques par déni de service
- Minimisation de l'impact négatif sur d'autres appareils/réseaux
- Conception minimisant la surface d'attaque
- Atténuation de l'impact par des techniques de mitigation de l'exploitation
- Enregistrement et surveillance des informations pertinentes pour la sécurité (journalisation)
- Mécanismes de mise à jour logicielle sécurisée, avec notification aux utilisateurs
Partie II : Exigences de gestion des vulnérabilités
- Identifier et documenter les vulnérabilités et les composants (y compris le SBOM)
- Traiter les vulnérabilités sans délai par des mises à jour de sécurité
- Appliquer des tests et revues efficaces et réguliers
- Divulgation publique des vulnérabilités corrigées, y compris les identifiants CVE
- Politique de divulgation coordonnée des vulnérabilités (CVD)
- Mécanismes de distribution sécurisée des mises à jour de sécurité
- Mises à jour de sécurité gratuites pendant la durée de vie prévue (minimum 5 ans)
L'échéance de septembre 2026 : Ce que vous devez faire maintenant
L'obligation la plus urgente du CRA est l'Article 14 — qui s'applique à partir du 11 septembre 2026. Ce n'est pas un jalon de préparation ; c'est une date d'application ferme. À partir de cette date, le non-signalement constitue une infraction au CRA.
Point crucial : les produits existants sont inclus
Un point capital que de nombreux fabricants négligent : les obligations de signalement de l'Article 14 s'appliquent à tous les produits avec éléments numériques sur le marché de l'UE, y compris ceux mis en circulation avant la date limite finale de décembre 2027. Si votre dispositif IoT, routeur ou logiciel est actuellement commercialisé et qu'une vulnérabilité est découverte en septembre 2026, vous devez la signaler.
Ce qui doit être signalé
Les fabricants doivent signaler à l'ENISA (via la plateforme unique de signalement) et à leur CSIRT national désigné :
Vulnérabilités activement exploitées :
- Dans les 24 heures suivant la prise de connaissance : Alerte précoce
- Dans les 72 heures : Notification complète avec mesures correctives disponibles
- Dans les 14 jours après disponibilité d'une mesure corrective : Rapport final avec description, gravité, impact et remédiation
Incidents graves affectant la sécurité du produit :
- Même structure d'alerte précoce à 24 h/72 h
- Dans le mois : Rapport final d'incident
La plateforme unique de signalement (SRP)
L'ENISA établit la plateforme unique de signalement (SRP), qui sera opérationnelle le 11 septembre 2026. Les fabricants signalent une seule fois via la SRP — les notifications sont adressées au CSIRT du principal établissement du fabricant, avec une mise à disposition simultanée à l'ENISA et aux CSIRT de l'UE pertinents. Une période de test sera disponible avant l'échéance.
Liste d'actions pour septembre 2026
- Inventaire des produits : Identifier tous les produits avec éléments numériques sur le marché de l'UE
- Créer ou mettre à jour le SBOM : Chaque produit nécessite une nomenclature logicielle complète
- Établir le contact CSIRT : Identifier le CSIRT national compétent (en France : l'ANSSI/CERT-FR)
- S'inscrire sur la SRP : Mettre en place l'accès à la plateforme unique de signalement de l'ENISA
- Publier une politique CVD : Publier une politique de divulgation coordonnée des vulnérabilités
- Documenter le processus 24/72 h : Créer et tester le processus d'escalade interne pour l'alerte précoce
- Mettre en place la surveillance CVE : Surveiller les bases de données CVE pour les dépendances de vos produits
Nomenclature logicielle (SBOM) : le fondement de la conformité CRA
L'une des exigences opérationnellement les plus significatives du CRA est l'obligation de nomenclature logicielle (Software Bill of Materials, SBOM) — un inventaire complet et lisible par machine de tous les composants logiciels d'un produit : bibliothèques, frameworks, paquets open source et leurs versions.
Pourquoi les SBOM sont essentiels pour la conformité CRA :
- Détection des vulnérabilités : Lors de la découverte d'une vulnérabilité critique dans une dépendance (par exemple un événement de type Log4Shell), votre SBOM vous permet d'identifier immédiatement quels produits sont affectés
- Obligation de signalement à 24 heures : Sans SBOM précise, respecter le délai d'alerte précoce de 24 heures est opérationnellement impossible pour tout produit avec des arbres de dépendances complexes
- Preuve de conformité : Les autorités de surveillance du marché (en France, l'ANSSI peut être désignée autorité compétente) peuvent demander votre SBOM dans le cadre de l'évaluation de conformité
Contenu minimum du SBOM selon le CRA :
- Nom et version de chaque composant
- Fournisseur/auteur du composant
- Identifiant unique (par ex. Package URL/PURL)
- Relations de dépendance
- Informations de licence
Formats standards : SPDX (ISO/IEC 5962) et CycloneDX — CycloneDX est de plus en plus privilégié pour les usages sécurité en raison de son intégration du suivi des vulnérabilités.
Cycle de développement sécurisé (SDL) selon les exigences CRA
Le CRA n'impose pas de référentiel SDL spécifique, mais les exigences essentielles de l'Annexe I décrivent ce qu'un processus de développement conforme doit produire. Intégrer la sécurité à chaque phase est la seule approche scalable :
Phase des exigences
- Définir les exigences de sécurité dans les spécifications produit dès le départ
- Conduire une modélisation des menaces (threat modelling) dans le cadre de la planification produit
- Déclarer la durée de vie prévue du produit (minimum 5 ans pour la période de support)
Phase de développement
- Appliquer des standards de codage sécurisé et des revues de code systématiques
- Utiliser des outils de gestion des dépendances pour suivre et mettre à jour les bibliothèques tierces
- Implémenter des tests de sécurité applicatifs statiques automatisés (SAST)
Phase de test
- Conduire des tests d'intrusion avant chaque version majeure
- Appliquer des tests de sécurité applicatifs dynamiques (DAST)
- Effectuer une analyse de vulnérabilités sur tous les composants
Phase de publication
- Générer et publier le SBOM pour chaque version
- Vérifier la configuration sécurisée par défaut avant livraison
- Documenter les paramètres de sécurité pour les utilisateurs
Phase opérationnelle
- Surveiller les bases de données CVE et les bulletins de sécurité pour vos dépendances
- Opérer un processus de gestion des correctifs avec des délais de réponse définis
- Gérer un programme formel de divulgation coordonnée des vulnérabilités (CVD)
Open source et le CRA
Les dispositions du CRA relatives à l'open source sont nuancées. L'exemption open source non commercial couvre les contributions individuelles et les projets développés en dehors d'un contexte commercial. Deux scénarios font cependant entrer des acteurs open source dans le champ d'application :
Stewards open source
Une personne morale (typiquement une fondation) qui fournit un soutien durable au développement de logiciels open source destinés à des activités commerciales est soumise au CRA en tant que steward open source. Ce régime allégé prévoit :
- Maintenir une politique de cybersécurité couvrant le développement sécurisé et la gestion des vulnérabilités
- Coopérer avec les autorités de surveillance du marché
- Signaler les vulnérabilités activement exploitées et les incidents graves à partir de septembre 2026
- Important : les stewards open source ne sont pas soumis aux amendes administratives du CRA
Produits commerciaux intégrant de l'open source
Si vous distribuez un produit commercial intégrant des composants open source, vous êtes le fabricant au sens du CRA — responsable de l'ensemble du produit y compris ses dépendances open source. Les orientations de mars 2026 précisent que les fabricants ne sont pas tenus de garantir qu'un correctif proposé sera accepté en amont (les correctifs locaux sont autorisés), mais doivent suivre et signaler les vulnérabilités dans tous les composants.
Orientations de la Commission de mars 2026 : Clarifications clés
La Commission européenne a publié son projet de document d'orientation (Ares(2026)2319816) le 3 mars 2026 — environ 70 pages de clarifications pratiques ouvertes aux retours des parties prenantes jusqu'au 31 mars 2026.
Clarifications pertinentes pour les fabricants :
- « Mise sur le marché » inclut la mise à disposition d'un logiciel en téléchargement ou accès à distance — pas uniquement la distribution physique
- Les composants de traitement de données à distance essentiels à la fonction principale d'un produit entrent dans le périmètre
- Définition de la période de support et son articulation avec l'obligation minimale de 5 ans de mises à jour
- Signalement en amont : Les fabricants ne sont pas tenus de garantir que leur correctif sera accepté par le projet open source
- Articulation avec d'autres législations UE : Comment les obligations CRA s'articulent avec le RGPD, NIS2 et l'IA Act
Le document d'orientation définitif est attendu après la clôture de la consultation et fournira l'interprétation faisant autorité avant l'échéance de septembre 2026.
Calendrier CRA
| Date | Étape |
|---|---|
| 20 nov. 2024 | Publication au Journal officiel |
| 10 déc. 2024 | Entrée en vigueur |
| 3 mar. 2026 | Publication du projet d'orientations de la Commission (retours jusqu'au 31 mars 2026) |
| 11 juin 2026 | Dispositions relatives aux organismes d'évaluation de conformité ; les États membres doivent avoir désigné leurs autorités notifiantes |
| 11 sept. 2026 | Obligations de signalement des vulnérabilités (Article 14) — y compris pour les produits déjà sur le marché |
| 11 déc. 2027 | Application complète — marquage CE, évaluation de conformité, documentation technique |
Sanctions
| Infraction | Amende maximale |
|---|---|
| Non-respect des exigences essentielles de cybersécurité (Annexe I) | 15 millions d'euros ou 2,5 % du CA annuel mondial |
| Non-respect d'autres obligations du CRA | 10 millions d'euros ou 2 % du CA mondial |
| Fourniture d'informations trompeuses aux autorités | 5 millions d'euros ou 1 % du CA mondial |
Les autorités de surveillance du marché peuvent également :
- Ordonner le retrait de produits du marché
- Exiger des mesures correctives
- Interdire ou restreindre la mise à disposition sur le marché
- Ordonner des rappels de produits
En France, l'ANSSI pourra être désignée autorité de surveillance du marché pour les produits numériques entrant dans son périmètre de compétence, en cohérence avec ses attributions actuelles en matière de cybersécurité et de certification (Critères Communs, CSPN).
Feuille de route complète vers décembre 2027
Au-delà de l'échéance de signalement de septembre 2026, les fabricants ont besoin d'un programme global pour atteindre la pleine conformité CRA d'ici décembre 2027 :
Étape 1 : Évaluation du périmètre
Déterminez lesquels de vos produits relèvent du CRA et leur catégorie (par défaut, Classe I importante, Classe II importante, ou critique). Identifiez la procédure d'évaluation de conformité appropriée.
Étape 2 : Analyse d'écarts par rapport à l'Annexe I
Cartographiez vos pratiques actuelles de sécurité produit par rapport aux 20 exigences essentielles. Lacunes courantes détectées lors des évaluations de préparation CRA :
- Pas de processus formel de gestion des SBOM
- Délais de traitement des vulnérabilités non alignés sur les exigences CRA (24 h/72 h/14 jours)
- Pas de mécanisme de mise à jour sécurisée pour les produits déployés
- Pas de politique de divulgation coordonnée des vulnérabilités publiée
- Tests de sécurité ponctuels plutôt que systématiques
Étape 3 : Intégration de la sécurité dès la conception
Intégrez les exigences de cybersécurité dans votre cycle de développement produit à toutes les phases (voir section SDL). C'est un changement culturel et processuel, pas seulement technique.
Étape 4 : Programme de gestion des vulnérabilités
- Politique de divulgation coordonnée des vulnérabilités publiée sur votre site
- Génération et maintenance du SBOM pour chaque version de produit
- Surveillance CVE pour votre graphe de dépendances
- Documentation et simulation du workflow de signalement 24 h/72 h/14 jours
Étape 5 : Documentation technique
Constituez le dossier technique complet pour la conformité CRA :
- Description du produit et de sa conception
- Exigences de sécurité et leur mise en œuvre
- Analyse des risques
- Résultats des tests
- SBOM
- Déclaration UE de conformité
Étape 6 : Évaluation de conformité et marquage CE
Réalisez la procédure d'évaluation de conformité appropriée à votre catégorie de produit et apposez le marquage CE.
Étape 7 : Conformité continue tout au long du cycle de vie
Le CRA crée des obligations permanentes — pas un exercice ponctuel :
- Mettre à jour le SBOM à chaque version
- Surveiller et corriger les dépendances tout au long de la période de support déclarée
- Maintenir la documentation technique à jour
- Respecter en continu les obligations de signalement de l'Article 14
FAQ : Mise en œuvre du CRA
Le CRA s'applique-t-il aux produits SaaS ?
Les services SaaS autonomes, non intégrés comme composant d'un produit, ne relèvent généralement pas du CRA — d'autres règlements comme NIS2 s'appliquent. Mais les services cloud essentiels à la fonction principale d'un produit physique (par ex. un backend cloud pour un dispositif IoT) sont considérés comme faisant partie du produit et doivent respecter les exigences CRA pour cette partie.
Règle pratique : Si votre logiciel est vendu comme produit autonome ou est une composante essentielle d'un produit connecté, le CRA s'applique. S'il fonctionne uniquement comme service sans intégration produit, probablement pas.
Pendant combien de temps faut-il fournir des mises à jour de sécurité ?
Le CRA exige des mises à jour de sécurité pendant la durée de vie prévue du produit, au minimum 5 ans à compter de la dernière mise sur le marché. Les fabricants doivent :
- Définir une période de support officielle pour chaque produit
- La communiquer clairement aux clients
- Planifier les ressources de gestion des correctifs sur toute la durée de vie
Que se passe-t-il si une vulnérabilité est découverte dans une dépendance open source ?
En tant que fabricant, vous êtes responsable — pas l'auteur open source. Vous devez :
- Identifier les produits concernés grâce à votre SBOM
- Signaler une vulnérabilité activement exploitée à l'ENISA dans les 24 heures
- Fournir une mise à jour ou un contournement dans les 72 heures
- Informer les utilisateurs
CRA et autres réglementations européennes
| Réglementation | Relation avec le CRA |
|---|---|
| NIS2 | Le CRA traite la sécurité des produits ; NIS2 traite la sécurité organisationnelle. Les produits conformes CRA aident les opérateurs soumis à NIS2 à satisfaire leurs obligations de sécurité de la chaîne d'approvisionnement. |
| RGPD | Les exigences de protection des données du CRA (minimisation, chiffrement, contrôle d'accès) complètent le RGPD au niveau du produit. |
| DORA | Les entités financières soumises à DORA doivent utiliser des produits TIC sécurisés — les produits conformes CRA réduisent l'exposition au risque TIC DORA. |
| Règlement IA | Les systèmes d'IA à haut risque qui sont des produits avec éléments numériques doivent se conformer au CRA et au Règlement IA. |
| RDM/RDIV | Les dispositifs médicaux sont exemptés du CRA (couverts par leurs propres règlements). |
| Directive équipements radioélectriques (RED) | Le CRA remplacera à terme les actes délégués de cybersécurité de la RED pour les produits concernés. |
Comment Orbiq soutient la conformité CRA
La conformité CRA génère d'importantes exigences de documentation et de preuves tout au long du cycle de vie du produit. Orbiq aide les fabricants à les gérer en continu :
- Documentation de la chaîne d'approvisionnement : Suivre les composants et dépendances à travers votre portefeuille de produits — la base de la gestion des SBOM
- Preuves de conformité : Centraliser les résultats des tests de sécurité, les évaluations de vulnérabilités et la documentation de conformité
- Trust Center : Partager votre posture de sécurité produit, politique CVD et statut de conformité avec les clients et les autorités de surveillance
- Gestion des fournisseurs : Surveiller le statut de sécurité des composants et dépendances tierces
- Surveillance continue : Assurer les obligations CRA avec un suivi automatisé sur l'ensemble de votre portefeuille produit
Si vous comparez encore des plateformes, notre guide des logiciels d'automatisation de la conformité explique quels fournisseurs sont les plus solides sur la collecte continue de preuves, l'hébergement UE et les workflows opérationnels de conformité.
Lectures complémentaires
- Cyber Resilience Act : Articles 13 et 14 en détail
- Règlement IA de l'UE : Guide complet de conformité 2026 — Exigences IA qui se recoupent avec le CRA pour les produits dotés de capacités d'IA
- Guide de conformité NIS2 — Exigences de sécurité organisationnelle
- Guide de conformité DORA — Exigences du secteur financier
- La Directive NIS2 : Vue d'ensemble complète — Cadre législatif et transposition nationale
Sources et références
- Règlement CRA — Texte officiel (Règlement 2024/2847) — Journal officiel de l'UE, 20 novembre 2024
- Projet d'orientations de la Commission sur le CRA — Ares(2026)2319816 — Commission européenne, 3 mars 2026
- Obligations de signalement CRA — Page officielle — Article 14 et plateforme unique de signalement
- Mise en œuvre du CRA — Fiche factuelle EC — Jalons et calendrier
- EU CRA : Jalons clés 2026 — Hogan Lovells
- Entrée en application progressive du CRA — Bird & Bird, 2026
- Compte à rebours : un an pour la conformité CRA — Keysight Technologies
- Normes harmonisées CRA — Keysight, février 2026
- CRA et open source — Commission européenne
- Guide CRA DLA Piper — DLA Piper, février 2026
Ce guide est maintenu par l'équipe Orbiq. Dernière mise à jour : mars 2026.