Cyber Resilience Act (CRA) : ce qu'il exige, qui est concerné et comment se préparer
Guide pratique du Cyber Resilience Act de l'UE — ce que le CRA exige pour les produits comportant des éléments numeriques, qui est concerné, les exigences essentielles de sécurité, les procédures d'évaluation de la conformité et comment les éditeurs de logiciels peuvent se préparer.
Cyber Resilience Act (CRA) : ce qu'il exige, qui est concerné et comment se préparer
Le Cyber Resilience Act (CRA) est le règlement de l'UE établissant des exigences obligatoires de cybersécurité pour les produits comportant des éléments numeriques. Adopté en 2024, avec une mise en œuvre progressive jusqu'a décembre 2027, le CRA comble une lacune critique dans la législation européenne de cybersécurité en abordant la sécurité des produits avant leur mise sur le marché.
Pour les entreprises de logiciels B2B, le CRA represente un changement fondamental : la cybersécurité n'est plus une fonctionnalité volontaire mais un prerequis legal pour l'accès au marché de l'UE. Les produits doivent être concus avec la sécurité a l'esprit, les vulnérabilités doivent être activement gérées, et les fabricants doivent fournir des mises à jour de sécurité tout au long du cycle de vie du produit.
Ce guide couvre ce que le CRA exige, a qui il s'applique, les obligations essentielles de conformité et comment les éditeurs de logiciels peuvent se préparer.
Champ d'application et applicabilité du CRA
Que sont les produits comportant des éléments numeriques
Le CRA couvre tout produit logiciel ou materiel et ses solutions de traitement de données a distance mis sur le marché de l'UE :
| Catégorie | Exemples |
|---|---|
| Logiciel autonome | Applications de bureau, applications mobiles, plateformes SaaS |
| Systemes d'exploitation | OS de bureau, OS mobile, OS embarque |
| Appareils IoT | Appareils domestiques connectés, objets portables, appareils connectés |
| Equipements réseau | Routeurs, commutateurs, pare-feu, points d'accès |
| Systemes industriels | Automates programmables, systèmes SCADA, IoT industriel |
| Composants | Bibliotheques logicielles, SDK, micrologiciels, microcontroleurs |
Classification des produits
Le CRA categorise les produits par niveau de risque, determinant l'évaluation de conformité requise :
| Catégorie | Évaluation | Exemples |
|---|---|---|
| Par défaut | Auto-évaluation (si les normes harmonisees s'appliquent) | Logiciels generalistes, enceintes connectees, jeux |
| Important Classe I | Auto-évaluation avec normes harmonisees, ou tiers | Gestion d'identite, gestionnaires de mots de passe, VPN, SIEM, gestion de réseau |
| Important Classe II | Tiers obligatoire (organisme notifie) | Systemes d'exploitation, hyperviseurs, pare-feu, microcontroleurs, cartes a puce, automatisation industrielle |
| Critique | Tiers obligatoire (certification UE) | Modules de sécurité materielle, passerelles de compteurs intelligents, cartes a puce pour signatures electroniques qualifiees |
Qui doit se conformer
| Role | Obligations |
|---|---|
| Fabricants | Concevoir des produits sécurisés, realiser l'évaluation de conformité, fournir des mises à jour, signaler les vulnérabilités, maintenir la documentation technique, marquage CE |
| Importateurs | Verifier la conformité du fabricant, s'assurer du marquage CE, conserver les declarations disponibles, signaler les produits non conformes |
| Distributeurs | Verifier le marquage CE, s'assurer de la documentation de conformité, signaler les produits non conformes |
| Open source (non commercial) | Exemptes de la plupart des obligations ; les intendants open source ont des exigences de transparence allegees |
Exigences essentielles de cybersécurité
Exigences de sécurité des produits (Annexe I, Partie I)
Les produits comportant des éléments numeriques doivent satisfaire ces exigences essentielles :
Conception et développement
- Concus, developpes et produits pour assurer un niveau de cybersécurité adapté basé sur l'évaluation des risques
- Livres sans vulnérabilités connues exploitables
- Configuration sécurisée par défaut, incluant la possibilite de réinitialiser a l'etat sécurisé d'origine
- Protection contre l'accès non autorisé avec authentification et gestion des identités appropriees
Protection des données
- Proteger la confidentialité des données stockees, transmises et traitees (chiffrement au repos et en transit)
- Proteger l'intégrité des données, commandes et configurations contre la manipulation
- Traiter uniquement les données adéquates, pertinentes et limitees a l'usage prévu (minimisation des données)
Resilience et disponibilité
- Concus pour assurer la disponibilité, incluant la résilience contre les attaques par déni de service
- Minimiser l'impact négatif sur la disponibilité des services fournis par d'autres appareils ou réseaux
- Reduire les surfaces d'attaque, incluant les interfaces externes
- Concus pour limiter l'impact d'un incident grace a des mécanismes d'attenuation d'exploitation adaptes
Surveillance et journalisation
- Fournir des capacités de journalisation et de surveillance des événements de sécurité
- Capacite de detection et de signalement des événements de sécurité
- Mecanismes de distribution sécurisée des mises à jour
Exigences de gestion des vulnérabilités (Annexe I, Partie II)
Les fabricants doivent etablir et maintenir :
| Exigence | Description |
|---|---|
| Identification des vulnérabilités | Identifier et documenter les vulnérabilités, y compris par des tests réguliers et des rapports de tiers |
| Documentation des composants | Maintenir un Software Bill of Materials (SBOM) identifiant les composants et dépendances |
| Mises à jour de sécurité | Appliquer des mises à jour efficaces et regulieres, fournies gratuitement pendant la période de support |
| Divulgation des vulnérabilités | Mettre en oeuvre une politique de divulgation coordonnée des vulnérabilités |
| Partage d'information | Partager en temps opportun les informations sur les vulnérabilités corrigées |
| Distribution des mises à jour | Fournir des mécanismes sécurisés de distribution des mises à jour |
| Avis de sécurité | Diffuser des avis sur les vulnérabilités et les correctifs disponibles |
Signalement des incidents et des vulnérabilités
Signalement a l'ENISA
Les fabricants doivent signaler a l'ENISA (via une plateforme de signalement unique) :
| Evenement | Notification initiale | Notification complète | Rapport final |
|---|---|---|---|
| Vulnerabilite activement exploitee | 24 heures | 72 heures | 14 jours |
| Incident grave impactant la sécurité | 24 heures | 72 heures | 14 jours |
L'ENISA transmet les notifications aux CSIRT nationaux concernes et aux autorités de surveillance du marché.
Notification aux utilisateurs
Les fabricants doivent également :
- Informer les utilisateurs des incidents et des vulnérabilités activement exploitees
- Fournir des conseils sur les mesures potentielles d'attenuation des risques
- Lorsque possible, fournir des mesures correctives (correctifs, solutions de contournement)
Delai de signalement
L'obligation de signalement s'applique pendant toute la durée de vie attendue du produit ou pendant un minimum de cinq ans a compter de la mise sur le marché du produit, selon la durée la plus courte.
Évaluation de conformité et marquage CE
Procedures d'évaluation
| Procedure | Applicable a | Processus |
|---|---|---|
| Contrôle interne (auto-évaluation) | Produits par défaut ; Classe I avec normes harmonisees | Le fabricant évalue par rapport aux exigences, cree la documentation technique, emet la declaration UE de conformité |
| Examen UE de type | Classe I sans normes harmonisees ; Classe II ; produits critiques | Un organisme notifie examine la conception technique et un echantillon du produit |
| Assurance qualite complète | Alternative pour Classe I/II | Un organisme notifie approuve et surveille le système d'assurance qualite du fabricant |
| Certification UE | Produits critiques lorsque specifie | Certification dans le cadre d'un schema de certification de cybersécurité de l'UE |
Documentation technique
Les fabricants doivent préparer et maintenir une documentation technique comprenant :
- Description generale du produit et usage prévu
- Details de conception et de développement pertinents pour la cybersécurité
- Évaluation des risques et moyens de satisfaire les exigences essentielles
- Liste des normes harmonisees appliquees (ou autres solutions)
- Rapports de tests des évaluations de cybersécurité
- Software Bill of Materials (SBOM)
- Declaration UE de conformité
- Informations sur les mises à jour de sécurité et la période de support
Marquage CE
Les produits satisfaisant toutes les exigences applicables recoivent le marquage CE, qui :
- Indique la conformité aux exigences essentielles de cybersécurité
- Est requis pour la mise sur le marché de l'UE
- Doit être appose de manière visible, lisible et indelebile
- Pour les produits uniquement logiciels, peut être inclus dans la documentation ou l'interface numérique
Calendrier de mise en œuvre du CRA
| Date | Etape |
|---|---|
| 2024 | CRA adopte et entre en vigueur |
| Septembre 2026 | Obligations de signalement pour les fabricants (signalement des vulnérabilités et incidents a l'ENISA) |
| Decembre 2027 | Toutes les exigences du CRA pleinement applicables, incluant l'évaluation de conformité et le marquage CE |
CRA et autres référentiels
CRA et NIS2
| Aspect | CRA | NIS2 |
|---|---|---|
| Objet | Sécurité des produits (pre-marché) | Cybersecurite organisationnelle (opérationnelle) |
| Périmètre | Produits comportant des éléments numeriques | Entites essentielles et importantes |
| Nature | Reglement (directement applicable) | Directive (nécessite une transposition) |
| Évaluation | Évaluation de conformité avant la mise sur le marché | Gestion des risques et signalement des incidents en exploitation |
| Signalement | Vulnérabilités activement exploitees a l'ENISA | Incidents significatifs aux autorités competentes |
| Relation | Complementaires — le CRA sécurisé le produit, NIS2 sécurisé l'organisation qui l'utilise |
CRA et ISO 27001
| Aspect | ISO 27001 | Ajouts du CRA |
|---|---|---|
| Objet | SMSI organisationnel | Sécurité au niveau du produit |
| Gestion des vulnérabilités | A.8.8 Gestion des vulnérabilités techniques | SBOM obligatoire, divulgation coordonnée, correctifs gratuits |
| Signalement des incidents | Procedures internes | Signalement a l'ENISA sous 24/72 heures |
| Developpement sécurisé | A.8.25-A.8.31 Sécurité applicative | Conception sécurisée par défaut obligatoire |
| Chaîne d'approvisionnement | A.5.19-A.5.23 Sécurité des fournisseurs | Documentation des composants et exigences SBOM |
Se préparer a la conformité CRA
Pour les fabricants de logiciels
- Classifiez votre produit — Déterminez si votre produit est par défaut, Important Classe I/II ou critique
- Analyse des ecarts — Cartographiez les pratiques de sécurité actuelles par rapport aux exigences essentielles du CRA (Annexe I)
- Cycle de développement sécurisé — Mettez en oeuvre ou renforcez les pratiques SDL, incluant la modelisation des menaces et les tests de sécurité
- Gestion des vulnérabilités — Etablissez la divulgation coordonnée des vulnérabilités, la gestion des correctifs et les processus d'avis de sécurité
- Creation du SBOM — Generez et maintenez un Software Bill of Materials pour tous les produits
- Documentation technique — Preparez la documentation demontrant la conformité aux exigences essentielles
- Preparation au signalement — Developpez la capacite de signalement des vulnérabilités et incidents a l'ENISA sous 24 heures
- Planification de la période de support — Définissez et communiquez la période de support sécurité pour chaque produit
Pour les entreprises SaaS B2B
- Déterminez l'applicabilité — Évaluez si votre SaaS constitue un produit comportant des éléments numeriques ou un traitement de données a distance
- Revoyez les contrats clients — Preparez-vous aux exigences contractuelles alignées sur le CRA de la part des acheteurs entreprises
- Renforcez la gestion des vulnérabilités — Mettez en oeuvre la génération de SBOM, l'analyse de vulnérabilités et la divulgation coordonnée
- Publiez sur le Trust Center — Rendez la documentation de sécurité, les processus de gestion des vulnérabilités et les preuves de conformité accessibles aux acheteurs
- Planifiez l'évaluation de conformité — Déterminez la voie d'évaluation appropriee et préparez-vous en consequence
- Surveillez les normes harmonisees — Suivez le développement des normes harmonisees qui permettront l'auto-évaluation pour les produits Classe I
Comment Orbiq accompagne la conformité CRA
- Trust Center — Publiez votre posture de conformité CRA — pratiques de développement sécurisé, processus de gestion des vulnérabilités, disponibilité du SBOM et politiques de mises à jour de sécurité en libre-service pour les acheteurs
- Surveillance continue — Suivez les exigences essentielles du CRA a travers vos contrôles de sécurité produit avec un statut de conformité en temps reel
- Gestion des preuves — Centralisez la documentation technique, les rapports de tests de sécurité et les registres de vulnérabilités cartographies aux exigences de l'Annexe I du CRA
- Questionnaires alimentes par l'IA — Repondez automatiquement aux questions des questionnaires de sécurité liés au CRA des clients entreprises
Guide complet : Cyber Resilience Act (CRA) : Guide complet pour la conformité 2026 — Couverture exhaustive de l'échéance de septembre 2026 pour le signalement des vulnérabilités, les exigences SBOM, les obligations des stewards open source, les orientations de la Commission de mars 2026 et la feuille de route complète de conformité.
Pour aller plus loin
- Conformité NIS2 — Comprendre la relation entre la sécurité produit du CRA et la sécurité organisationnelle NIS2
- Conformité DORA — Implications du CRA pour les fournisseurs TIC au service du secteur financier
- Test d'intrusion — Satisfaire les exigences de tests de sécurité du CRA
- Réponse aux incidents — Développer les capacités de signalement pour les notifications de vulnérabilités et d'incidents du CRA
Ce guide est maintenu par l'équipe Orbiq. Derniere mise à jour : mars 2026.