EU Cyber Resilience Act (CRA) : ce que vous devez savoir

Vous développez une application mobile ? Vous vendez des objets connectés ? Vous éditez un logiciel utilisé par des entreprises européennes ? Alors le Cyber Resilience Act (CRA) va changer votre quotidien.

Ce règlement européen, adopté en 2024, impose pour la première fois des exigences de cybersécurité à tous les produits numériques vendus dans l’Union européenne. Fini le temps où l’on pouvait vendre un logiciel truffé de failles sans conséquences légales.

Qu’est-ce que le CRA ?

Un règlement pour sécuriser tous les produits numériques

Le CRA (Regulation (EU) 2024/2847) est un texte européen qui oblige les fabricants de produits numériques à :

• Concevoir des produits sécurisés dès le départ (pas de sécurité “ajoutée après coup”)
• Corriger les failles pendant toute la vie du produit (minimum 5 ans de mises à jour)
• Informer rapidement en cas de problème (24h pour signaler une faille exploitée)
• Documenter ce qu’il y a dans le produit (le fameux SBOM, on y reviendra)

Pourquoi ce règlement ?

Aujourd’hui, on achète des produits connectés sans savoir s’ils sont sécurisés. Une caméra IP à 30€ peut contenir des failles béantes, jamais corrigées par le fabricant. Un logiciel peut embarquer des centaines de bibliothèques vulnérables sans que personne ne s’en soucie.

Le CRA veut mettre fin à cette situation en créant des règles communes pour toute l’Europe.

Règlement vs Directive : une différence importante

Vous avez peut-être entendu parler de la “directive NIS2”. Le CRA, lui, est un règlement. Ce n’est pas la même chose :

Type	Fonctionnement	Conséquence
Directive	Chaque pays crée sa propre loi nationale	Les règles peuvent varier d’un pays à l’autre
Règlement	S’applique directement, de manière identique partout	Mêmes règles dans les 27 pays de l’UE

Le CRA est un règlement. Cela signifie que les mêmes exigences s’appliquent en France, en Allemagne, en Espagne, partout. Pas besoin d’attendre une transposition nationale. C’est plus simple et plus prévisible pour les entreprises qui opèrent dans plusieurs pays.

Ce que le CRA change concrètement

Avant le CRA, la cybersécurité des produits était essentiellement volontaire. Certains fabricants faisaient des efforts, d’autres non. Le consommateur n’avait aucun moyen de savoir.

Après le CRA :

Aspect	Avant	Après CRA
Conception	Sécurité optionnelle	Sécurité obligatoire dès la conception
Mises à jour	À la discrétion du fabricant	Minimum 5 ans obligatoires
Failles connues	Correction quand on veut	Notification sous 24h si exploitée
Transparence	Boîte noire	SBOM obligatoire
Responsabilité	Floue	Chaîne claire (fabricant → importateur → distributeur)
Sanctions	Quasi inexistantes	Jusqu’à 15M€ ou 2,5% du CA

Êtes-vous concerné ?

Les produits couverts par le CRA

Le CRA utilise l’expression “produits comportant des éléments numériques” (Products with Digital Elements). En pratique, cela couvre énormément de choses :

Logiciels :

• Applications mobiles (iOS, Android)
• Logiciels desktop (Windows, macOS, Linux)
• Bibliothèques et frameworks utilisés par d’autres développeurs
• Systèmes d’exploitation

Matériel avec logiciel embarqué :

• Objets connectés (IoT) : caméras, thermostats, montres, capteurs
• Équipements réseau : routeurs, switches, points d’accès WiFi
• Appareils électroniques : NAS, imprimantes, téléviseurs connectés
• Équipements industriels : automates, capteurs, systèmes SCADA

Services hybrides :

• Logiciels installés localement qui communiquent avec le cloud
• Applications avec composant local (agent, SDK)

Les acteurs concernés

Le CRA ne s’adresse pas qu’aux fabricants. Toute la chaîne de distribution est concernée :

Rôle	Qui c’est	Ce qu’il doit faire
Fabricant	Celui qui conçoit et produit	Assurer la conformité complète, fournir le SBOM, maintenir les mises à jour
Importateur	Celui qui fait entrer un produit non-UE sur le marché européen	Vérifier que le fabricant a fait son travail, ne pas importer de produits non conformes
Distributeur	Celui qui revend (boutique, marketplace)	Vérifier le marquage CE, signaler les problèmes découverts
Mandataire	Représentant d’un fabricant étranger dans l’UE	Servir d’interlocuteur pour les autorités européennes

Exemple concret :

Vous achetez une caméra IP sur Amazon :

• Le fabricant (une entreprise chinoise) doit avoir conçu un produit conforme
• L’importateur (la filiale européenne ou un grossiste) doit avoir vérifié la conformité
• Le distributeur (Amazon) doit s’assurer que le marquage CE est présent
• Si le fabricant n’est pas dans l’UE, un mandataire doit être désigné pour répondre aux autorités

Ce qui est exclu du CRA

Tout n’est pas couvert. Le CRA prévoit des exclusions importantes :

Logiciels open source non commerciaux :

Un projet open source est exclu si :

1. Il n’y a pas de modèle commercial (pas de vente, pas de support payant, pas de version “entreprise”)
2. Il n’y a pas de personne morale derrière avec une intention de profit

Autrement dit : un développeur qui publie un projet personnel sur GitHub n’est pas concerné.

Attention : si vous êtes une entreprise et que vous intégrez ce projet open source dans votre produit commercial, vous êtes responsable de la conformité du tout.

Services SaaS purs :

Un service 100% cloud, où rien n’est installé chez le client, n’est pas couvert par le CRA. Il peut en revanche être couvert par NIS2 si l’entreprise qui l’opère est dans un secteur concerné.

Nuance : si votre SaaS nécessite l’installation d’un agent, d’un SDK ou d’une application chez le client, ce composant est couvert par le CRA.

Produits déjà réglementés :

Certains secteurs ont déjà leurs propres règles de cybersécurité :

• Dispositifs médicaux (règlement MDR)
• Véhicules (règlement véhicules)
• Aviation (règlement aviation)
• Équipements militaires

Ces produits restent sous leur réglementation sectorielle.

Comment savoir si mon open source est concerné ?

Posez-vous ces questions :

1. Y a-t-il une entreprise ou une fondation derrière le projet ?
2. Cette entité gagne-t-elle de l’argent grâce au logiciel (support, consulting, version payante) ?
3. Le logiciel est-il développé dans le cadre d’une activité professionnelle ?

Si vous répondez “oui” à l’une de ces questions, le CRA s’applique probablement.

Ce que le CRA exige concrètement

Les exigences de sécurité (Annexe I)

Le CRA définit dans son Annexe I les exigences essentielles de cybersécurité. En voici les grandes lignes, expliquées simplement :

1. Conception sécurisée (Security by Design)

Votre produit doit être pensé pour la sécurité dès le départ :

• Protéger contre les accès non autorisés (authentification, contrôle d’accès)
• Garantir la confidentialité des données (chiffrement)
• Garantir l’intégrité des données (pas de modification non autorisée)
• Minimiser la surface d’attaque (désactiver ce qui n’est pas nécessaire)
• Limiter les dégâts en cas d’incident (principe du moindre privilège)

2. Pas de failles connues à la livraison

Un produit ne doit pas être mis sur le marché s’il contient des vulnérabilités connues et exploitables. Vous devez scanner vos dépendances et corriger les failles avant de livrer.

3. Configuration sécurisée par défaut

Le produit doit être sécurisé “out of the box” :

• Pas de mot de passe par défaut faible ou identique sur tous les appareils
• Fonctionnalités sensibles désactivées par défaut
• Mises à jour automatiques activées par défaut (ou incitation forte)

4. Protection des données

• Les données personnelles doivent être protégées
• L’utilisateur doit pouvoir supprimer ses données
• Les données collectées doivent être limitées au strict nécessaire

La gestion des vulnérabilités

Le CRA impose un processus formel de gestion des vulnérabilités :

Ce que vous devez mettre en place :

1. Un canal de signalement : une adresse email, un formulaire, une page dédiée où les chercheurs en sécurité peuvent vous signaler des failles

2. Un processus de triage : évaluer la criticité des failles signalées (CVSS, impact, exploitabilité)

3. Un processus de correction : développer, tester et déployer les correctifs

4. Une communication : informer les utilisateurs des failles et des correctifs disponibles

Les délais de notification :

Situation	Délai	À qui
Vulnérabilité activement exploitée	24 heures	ENISA + autorité nationale
Incident de sécurité grave	72 heures	ENISA + autorité nationale
Mise à jour de sécurité disponible	Sans délai	Utilisateurs

La durée du support :

Vous devez fournir des mises à jour de sécurité pendant au minimum 5 ans ou pendant la durée de vie raisonnable du produit (si plus longue).

Pour un logiciel bureautique, 5 ans peut suffire. Pour un équipement industriel prévu pour durer 15 ans, vous devez assurer le support pendant 15 ans.

Le SBOM obligatoire

Le SBOM (Software Bill of Materials) est une liste de tous les composants logiciels présents dans votre produit. Pensez-y comme la liste d’ingrédients sur un emballage alimentaire.

Pourquoi c’est important ?

Quand une faille est découverte dans une bibliothèque (comme Log4j en 2021), les entreprises doivent savoir si elles utilisent cette bibliothèque. Sans SBOM, c’est la panique : personne ne sait ce qu’il y a dans ses produits.

Avec un SBOM, vous pouvez :

• Identifier immédiatement si vous êtes concerné par une faille
• Informer vos clients rapidement
• Prioriser les corrections

Ce que doit contenir un SBOM :

Information	Exemple
Nom du composant	express
Version	4.18.2
Fournisseur/auteur	OpenJS Foundation
Licence	MIT
Identifiant unique	pkg:npm/express@4.18.2
Dépendances	Liste des composants dont il dépend

Formats reconnus :

Le CRA ne prescrit pas de format spécifique, mais deux standards dominent :

SPDX

SPDX est un standard ISO (ISO 5962) porté par la Linux Foundation :

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "mon-application",
  "packages": [
    {
      "name": "express",
      "versionInfo": "4.18.2",
      "supplier": "Organization: OpenJS Foundation",
      "downloadLocation": "https://registry.npmjs.org/express/-/express-4.18.2.tgz"
    }
  ]
}

CycloneDX

CycloneDX est un standard OWASP, très utilisé dans la communauté sécurité :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "supplier": {
        "name": "OpenJS Foundation"
      }
    }
  ]
}

Le SBOM doit-il être public ?

Non. Le CRA demande de le tenir à disposition des autorités de surveillance sur demande. Vous n’êtes pas obligé de le publier. Certaines entreprises choisissent de le faire pour la transparence, d’autres préfèrent le garder confidentiel.

La classification des produits

Tous les produits ne sont pas logés à la même enseigne. Le CRA définit trois classes avec des obligations croissantes :

Classe par défaut :

• La majorité des produits
• Auto-évaluation de conformité par le fabricant
• Exemples : jeux vidéo, applications de productivité, utilitaires

Classe I (produits importants) :

• Produits avec un rôle de sécurité
• Auto-évaluation possible si vous suivez des normes harmonisées, sinon audit externe
• Exemples :
  • Gestionnaires de mots de passe
  • VPN
  • Antivirus et anti-malware
  • Pare-feux personnels
  • Navigateurs web
  • Logiciels de gestion d’identité

Classe II (produits critiques) :

• Produits au cœur de la sécurité des systèmes
• Certification obligatoire par un organisme tiers
• Exemples :
  • Systèmes d’exploitation
  • Hyperviseurs
  • Modules de sécurité matériels (HSM)
  • Infrastructure PKI
  • Routeurs et équipements réseau industriels

Attention à la classification

Si votre produit est classe II, vous devrez passer par un organisme notifié pour obtenir une certification. Ces processus prennent du temps (plusieurs mois) et coûtent cher. Anticipez !

Le calendrier : quand tout ça s’applique ?

Le CRA ne s’applique pas d’un coup. Les obligations arrivent progressivement :

1. Décembre 2024 — Publication officielle

   Le texte est publié au Journal Officiel de l’UE. Le compte à rebours commence.

2. Septembre 2026 — Obligations de signalement

   Les fabricants doivent notifier l’ENISA sous 24h pour les vulnérabilités activement exploitées. Les processus de gestion des vulnérabilités doivent être en place.

3. Décembre 2027 — Entrée en vigueur complète

   Toutes les exigences s’appliquent. Les produits non conformes ne peuvent plus être vendus dans l’UE. Le marquage CE devient obligatoire.

Ce que ça signifie pour vous :

Si vous développez un produit aujourd’hui, il sera probablement encore en vente en 2027. Vous devez donc intégrer les exigences CRA dès maintenant dans votre processus de développement.

N’attendez pas décembre 2027 pour découvrir que votre produit n’est pas conforme.

Comment vous préparer concrètement

Étape 1 : Déterminez si vous êtes concerné

Posez-vous ces questions :

• Mon produit contient-il du logiciel ? (application, firmware, système embarqué)
• Est-il vendu ou distribué dans l’Union européenne ?
• Est-il exclu ? (open source non commercial, SaaS pur, secteur déjà réglementé)

Si vous êtes concerné, passez à l’étape suivante.

Étape 2 : Identifiez votre classification

Consultez les Annexes III et IV du CRA pour savoir si votre produit est :

• Classe par défaut → auto-évaluation
• Classe I → auto-évaluation avec normes OU audit
• Classe II → certification obligatoire

Étape 3 : Mettez en place la gestion des vulnérabilités

C’est souvent le plus urgent car les obligations de signalement arrivent en 2026.

Actions concrètes :

1. Créez une adresse security@votreentreprise.com pour recevoir les signalements
2. Documentez votre processus de triage et correction
3. Identifiez qui est responsable en interne (PSIRT, équipe sécurité)
4. Préparez des templates de communication (advisory, bulletin de sécurité)
5. Testez le processus avec un exercice

Étape 4 : Intégrez la génération de SBOM

Ajoutez la génération de SBOM à votre pipeline CI/CD :

# Avec Syft (Anchore) — recommandé pour sa simplicité
syft . -o spdx-json > sbom.spdx.json

# Avec cdxgen (CycloneDX) — bon pour les projets multi-langages
cdxgen -o sbom.cdx.json

# Avec Trivy (Aqua Security) — si vous l'utilisez déjà pour le scan
trivy fs . --format spdx-json --output sbom.spdx.json

Bonnes pratiques :

• Générez le SBOM à chaque release
• Stockez-le avec vos artefacts de build
• Incluez les dépendances transitives (les dépendances de vos dépendances)
• Versionnez-le avec le produit

Étape 5 : Constituez votre dossier technique

Le CRA exige une documentation technique. Préparez :

• Description du produit et de son usage prévu
• Analyse des risques cybersécurité
• Comment chaque exigence est satisfaite
• SBOM complet
• Résultats des tests de sécurité (SAST, DAST, pentest)
• Instructions d’installation et de configuration sécurisées
• Politique de support et de mises à jour

Étape 6 : Planifiez la certification (si classe II)

Si votre produit est classe II :

1. Identifiez les organismes notifiés pour le CRA (liste à venir)
2. Contactez-les pour connaître les délais et les coûts
3. Préparez votre dossier en avance
4. Prévoyez plusieurs mois de processus

Le lien avec NIS2

Le CRA et NIS2 sont deux textes complémentaires qui s’articulent ainsi :

Question	CRA	NIS2
À qui ça s’adresse ?	Fabricants de produits	Opérateurs de services essentiels
Obligation	Fabriquer des produits sécurisés	Sécuriser ses systèmes d’information
Focus	Ce qui est vendu	Ce qui est utilisé

En pratique :

• Si vous fabriquez un logiciel → CRA
• Si vous opérez des services critiques (énergie, santé, transport…) → NIS2
• Si vous faites les deux → les deux s’appliquent

Une organisation soumise à NIS2 devra vérifier que les produits qu’elle achète sont conformes au CRA. Elle pourra demander les SBOM à ses fournisseurs.

Les sanctions : ce que vous risquez

Le CRA prévoit des sanctions significatives :

Type d’infraction	Amende maximale
Non-conformité aux exigences essentielles	15 millions € ou 2,5% du CA mondial
Non-respect des obligations de notification	10 millions € ou 2% du CA mondial
Informations incorrectes aux autorités	5 millions € ou 1% du CA mondial

Autres mesures possibles :

• Interdiction de mise sur le marché
• Retrait des produits déjà vendus
• Rappel de produits
• Injonctions de mise en conformité

Pour mettre en perspective :

• Entreprise à 10M€ de CA : amende jusqu’à 250 000€
• Entreprise à 100M€ de CA : amende jusqu’à 2,5M€
• Multinationale à 1 milliard de CA : amende jusqu’à 25M€

Questions fréquentes

« Mon produit est open source, suis-je concerné ? »

Ça dépend de votre modèle économique.

Si vous êtes une personne physique qui développe un projet personnel sans intention de profit → Non.

Si vous êtes une entreprise ou une fondation avec une activité commerciale liée au logiciel (support, consulting, version entreprise, intégration) → Oui.

Si vous intégrez de l’open source dans un produit commercial → Vous êtes responsable de la conformité du tout.

« Je vends du SaaS, suis-je concerné ? »

Pas directement pour le service cloud lui-même.

Mais attention : si votre SaaS nécessite l’installation d’un composant côté client (agent de monitoring, SDK, application desktop, extension navigateur), ce composant est couvert par le CRA.

« Comment gérer les dépendances open source ? »

Vous êtes responsable de la conformité de votre produit final, y compris tous les composants tiers.

Actions recommandées :

1. Maintenez un SBOM à jour
2. Surveillez les CVE avec un outil comme Dependency-Track ou Trivy
3. Mettez à jour rapidement les composants vulnérables
4. Documentez vos choix (pourquoi tel composant, quelle version)

« 5 ans de mises à jour, c’est beaucoup ! »

C’est le minimum. Pour certains produits (IoT industriel, équipements médicaux), la durée de vie attendue est bien plus longue.

Conseils :

• Définissez clairement la durée de support dès le lancement
• Communiquez-la aux clients
• Prévoyez les ressources nécessaires
• Envisagez un modèle économique qui finance le support (abonnement, maintenance)

« Quand dois-je commencer à me préparer ? »

Maintenant.

Les obligations de signalement arrivent en septembre 2026. Mettre en place un processus de gestion des vulnérabilités prend du temps. Et vos produits actuels seront encore en circulation en 2027.

À retenir

1. Le CRA est un règlement européen — il s’applique directement et de manière identique dans tous les pays de l’UE

2. Il couvre tous les produits numériques — logiciels, IoT, matériel avec firmware, tout ce qui contient du code

3. Le SBOM devient obligatoire — commencez dès maintenant à générer et maintenir l’inventaire de vos composants

4. La gestion des vulnérabilités doit être formalisée — processus, contacts, délais de notification sous 24h

5. Septembre 2026 : obligations de signalement — les processus doivent être en place

6. Décembre 2027 : entrée en vigueur complète — vos produits doivent être conformes

7. Les sanctions sont significatives — jusqu’à 15M€ ou 2,5% du CA mondial

8. L’open source commercial est concerné — seuls les projets sans intention de profit sont exclus

Liens utiles

• Sécuriser la supply chain logicielle — contexte et menaces actuelles
• Directive NIS2 — obligations pour les opérateurs de services essentiels
• SBOM : comprendre et générer — formats SPDX et CycloneDX en détail
• SLSA : sécuriser la chaîne de build — attestations de provenance
• SCA : analyse des dépendances — scanner les vulnérabilités de vos bibliothèques
• OpenSSF Scorecard — évaluer la sécurité des projets open source

Ressources officielles

• Texte officiel du CRA (EUR-Lex) ↗ — le règlement complet
• FAQ de la Commission européenne ↗ — questions-réponses officielles
• ENISA — Guidance on CRA ↗ — ressources de l’agence européenne de cybersécurité