CRA Cyber Resilience Act 2027 : Conformité IoT & Logiciels (SBOM, CE)

1. Sécurité by Design (conception sécurisée)

• • Intégrer la sécurité dès la phase de conception du produit
• • Analyse de risques de cybersécurité documentée
• • Architecture de sécurité adaptée au niveau de risque
• • Principe du moindre privilège et de la surface d'attaque minimale
• • Mécanismes de mise à jour sécurisée intégrés dès l'origine

2. Protection des données et confidentialité

• • Chiffrement des données sensibles (au repos et en transit)
• • Protection de la confidentialité, intégrité et disponibilité des données
• • Minimisation de la collecte de données (privacy by design)
• • Mécanismes d'authentification et de contrôle d'accès robustes
• • Protection contre l'accès non autorisé et la manipulation

3. Résilience et disponibilité

• • Capacité à résister aux attaques et à se rétablir rapidement
• • Mécanismes de détection et de réponse aux incidents
• • Sauvegarde et restauration des données critiques
• • Tests de résistance aux attaques (fuzzing, pentesting)
• • Journalisation des événements de sécurité

4. Gestion des vulnérabilités

• • Processus de gestion des vulnérabilités documenté et opérationnel
• • Notification des vulnérabilités critiques sous 24h à l'ENISA
• • Notification aux utilisateurs finaux de manière transparente
• • Coordination avec les chercheurs en sécurité (vulnerability disclosure)
• • Publication d'un SBOM (Software Bill of Materials)

5. Mises à jour de sécurité

• • Fourniture de mises à jour de sécurité pendant toute la durée de support annoncée
• • Durée de support minimale : 5 ans ou durée de vie attendue du produit
• • Mécanisme de mise à jour automatique sécurisé (signature, chiffrement)
• • Information claire aux utilisateurs sur les mises à jour disponibles
• • Possibilité pour l'utilisateur de contrôler le moment des mises à jour (sauf urgence)

6. Documentation et transparence

• • Instructions d'utilisation sécurisée claires et accessibles
• • Déclaration de conformité CE détaillée
• • Documentation technique pour les autorités de surveillance
• • Information sur la durée de support et les mises à jour
• • Contact pour signaler les vulnérabilités (Security.txt recommandé)

7. Chaîne d'approvisionnement sécurisée

• • Sécurité des composants tiers et des dépendances
• • Publication d'un SBOM (Software Bill of Materials) à jour
• • Due diligence sur les fournisseurs et sous-traitants
• • Processus de développement sécurisé (DevSecOps)
• • Intégrité du code source et des binaires

Le CRA s'applique-t-il aux logiciels open source ?

Le CRA distingue deux cas : (1) Les logiciels open source non commercialisés (gratuits, développés de manière collaborative sans contrepartie économique) sont exclus du CRA. (2) Les logiciels open source commercialisés (vendus, distribués avec un support payant, intégrés dans une offre commerciale) sont soumis au CRA comme tout autre produit. Le fabricant ou distributeur commercial est responsable de la conformité. Cette distinction vise à ne pas freiner l'innovation open source tout en garantissant la sécurité des produits commerciaux.

Quelle est la différence entre le CRA et NIS2 ?

Le CRA (Cyber Resilience Act) s'applique aux fabricants de produits connectés et impose des exigences de sécurité produit (conception sécurisée, mises à jour, gestion des vulnérabilités). NIS2 s'applique aux opérateurs de services essentiels et importants (entreprises utilisant ces produits) et impose des mesures de cybersécurité organisationnelles (gouvernance, gestion des risques, réponse aux incidents). Les deux règlements sont complémentaires : NIS2 oblige les entreprises à sécuriser leurs opérations, le CRA oblige les fabricants à fournir des produits sécurisés. Une entreprise peut être soumise aux deux réglementations.

Qu'est-ce qu'un SBOM et pourquoi est-il obligatoire ?

Un SBOM (Software Bill of Materials) est un inventaire exhaustif de tous les composants logiciels (bibliothèques, dépendances, frameworks) utilisés dans un produit. Le CRA impose la publication d'un SBOM pour permettre : (1) l'identification rapide des vulnérabilités affectant des composants tiers, (2) la traçabilité de la chaîne d'approvisionnement logicielle, (3) la transparence sur les dépendances pour les utilisateurs. Le SBOM doit être au format standardisé (SPDX ou CycloneDX), tenu à jour et accessible. C'est un élément clé de la sécurité de la supply chain.

Combien de temps dois-je fournir des mises à jour de sécurité ?

Le CRA impose une durée de support minimale de 5 ans à compter de la mise sur le marché, ou la durée de vie attendue du produit si elle est supérieure. Cette durée doit être clairement communiquée aux utilisateurs au moment de l'achat. Pendant cette période, le fabricant doit fournir gratuitement toutes les mises à jour de sécurité nécessaires. Après cette période, le fabricant doit informer les utilisateurs de la fin du support. Cette exigence vise à lutter contre l'obsolescence prématurée et les produits abandonnés qui deviennent des risques de sécurité.

Que se passe-t-il si je découvre une vulnérabilité critique dans mon produit ?

Le CRA impose des délais stricts : (1) Notification à l'ENISA dans les 24 heures suivant la découverte d'une vulnérabilité activement exploitée ou critique. (2) Information des utilisateurs finaux sans délai injustifié, avec les mesures d'atténuation temporaires et le calendrier de déploiement du correctif. (3) Publication d'un patch de sécurité dans les meilleurs délais (généralement sous 14 à 30 jours pour une vulnérabilité critique). Le non-respect de ces obligations peut entraîner des sanctions importantes. Il est donc essentiel de mettre en place un processus de gestion des vulnérabilités opérationnel avant la mise sur le marché.

Mon produit est déjà certifié ISO 27001, suis-je conforme au CRA ?

Non, la certification ISO 27001 démontre que votre organisation a mis en place un système de management de la sécurité de l'information, mais elle ne garantit pas la conformité de vos produits aux exigences du CRA. Le CRA évalue la sécurité intrinsèque du produit lui-même (architecture, fonctionnalités de sécurité, processus de mise à jour, gestion des vulnérabilités produit), pas l'organisation qui le développe. En revanche, ISO 27001 est un excellent fondement pour construire votre conformité CRA, car beaucoup de processus sont similaires (gestion des risques, secure development, incident response). Considérez l'ISO 27001 comme un prérequis utile, mais pas suffisant.