Exigences CRA pour produits connectés sécurisés

Le Cyber Resilience Act (CRA), règlement (UE) 2024/2847, transforme la sécurité des produits connectés en condition d’accès au marché européen. Ce n’est pas une norme de développement ni un audit annuel à ranger dans un dossier : le fabricant doit démontrer que le produit est sécurisé à la livraison, maintenable pendant sa durée de support et traçable lorsqu’une faille apparaît.

→ Lire l’explication complète de la marmotte

Périmètre du CRA et responsabilité du fabricant

Le CRA vise les produits comportant des éléments numériques, c’est-à-dire du matériel ou du logiciel capable de se connecter directement ou indirectement à un réseau ou à un autre équipement. Une caméra IP, un pare-feu, un routeur, une bibliothèque logicielle distribuée séparément, un système d’exploitation embarqué ou une plateforme de gestion distante entrent potentiellement dans le périmètre.

La question utile n’est donc pas « est-ce un objet connecté ? », formule marketing dont le secteur a fait une soupe tiède. Il faut déterminer si le produit traite, stocke ou transmet des données numériques et s’il peut affecter la cybersécurité d’autres systèmes. Un composant logiciel sans interface réseau peut relever du règlement s’il est destiné à être intégré dans un produit connecté.

Le fabricant porte l’obligation principale : analyse de risque, exigences de sécurité, documentation technique, évaluation de conformité, déclaration UE de conformité et marquage CE. L’importateur et le distributeur ne deviennent pas fabricants par magie, mais peuvent assumer cette qualification s’ils mettent le produit sur le marché sous leur nom ou modifient substantiellement sa conformité.

Les obligations générales s’appliquent à partir du 11 décembre 2027. Le signalement des vulnérabilités activement exploitées et des incidents graves s’applique dès le 11 septembre 2026. Attendre 2027 pour construire le dispositif de réponse revient à découvrir l’extincteur pendant l’incendie.

Le CRA exclut certains domaines déjà régis par des textes sectoriels, notamment des équipements médicaux, aéronautiques ou automobiles dans les cas prévus. Cette exclusion ne signifie pas absence de sécurité. Elle signifie seulement que l’obligation vient d’un autre régime. Une analyse de qualification documentée reste nécessaire, surtout pour les produits hybrides mêlant équipement industriel, logiciel cloud et administration distante.

Le compromis central est net : le CRA impose plus de coût de conception, de preuve et de maintenance, contre une réduction réelle de la dette de sécurité distribuée chez les clients. La recommandation est de traiter le CRA comme une exigence d’architecture produit dès la conception, pas comme une couche de conformité ajoutée avant la commercialisation. Cette position est valable dès qu’un produit possède un cycle de mise à jour, une interface d’administration ou une dépendance logicielle externe. Autrement dit, dans presque tous les cas intéressants.

Exigences de sécurité et preuves de conformité

L’annexe I du CRA impose que les produits soient livrés sans vulnérabilités connues exploitables, configurés de façon sûre par défaut et protégés contre les accès non autorisés. Elle exige aussi l’intégrité des mises à jour, la protection de la confidentialité des données, la limitation de la surface d’attaque et la disponibilité des fonctions essentielles.

« Sans vulnérabilité connue exploitable » ne veut pas dire « aucun identifiant dans une base publique ». Une vulnérabilité non publiée, détectée dans une bibliothèque intégrée ou dans une interface de maintenance, entre dans le calcul. La conformité dépend d’un inventaire de composants exploitable, pas d’un tableur alimenté au courage après chaque incident.

Un inventaire logiciel doit relier chaque composant à sa version, son fournisseur, sa licence, son rôle dans le produit et son exposition. Le format SBOM (Software Bill of Materials), inventaire structuré des composants logiciels, est l’outil pragmatique pour cela. Le règlement ne sanctifie pas un format particulier, mais CycloneDX ou SPDX permettent d’automatiser l’identification des dépendances concernées.

La sécurité par défaut impose notamment :

aucun mot de passe universel ou prévisible ;
une identité distincte par équipement ou par instance ;
des interfaces de débogage désactivées hors procédure de maintenance contrôlée ;
des services réseau minimaux et documentés ;
une authentification forte sur les interfaces d’administration ;
une journalisation exportable des événements de sécurité ;
des mises à jour authentifiées et vérifiées avant installation.

Le chiffrement n’excuse pas une mauvaise exposition réseau. Une interface d’administration sur Internet, protégée par Transport Layer Security (TLS), reste une interface d’administration exposée sur Internet. Fermer la porte à clé tout en affichant le plan de l’immeuble sur la façade demeure une stratégie étonnamment populaire.

Les produits critiques de l’annexe III sont classés en deux niveaux. Les catégories de classe I comprennent, entre autres, certains gestionnaires d’identité, pare-feu, routeurs, commutateurs réseau et composants de sécurité. Les catégories de classe II couvrent des produits plus sensibles, comme certains systèmes d’exploitation, hyperviseurs ou composants de sécurité réseau. Selon la catégorie, une évaluation par un organisme notifié peut être requise, sauf usage pertinent de normes harmonisées couvrant les exigences applicables.

La documentation technique doit donc relier le risque à une mesure vérifiable. « Chiffrement des données » ne prouve rien. Il faut préciser l’algorithme, la gestion des clés, les frontières de confiance, les données couvertes, le mode de rotation, les conditions de révocation et les tests réalisés. La cryptographie appliquée ne compense jamais une autorisation mal conçue.

Cycle de vie, vulnérabilités et signalement CRA

Le fabricant doit fournir des mises à jour de sécurité pendant la période de support, normalement d’au moins cinq ans après la mise sur le marché ou pendant la durée de vie attendue du produit si elle est plus courte. Cette période doit être annoncée clairement avant l’achat. Une fin de support vague transforme le client en dépositaire involontaire d’un équipement vulnérable.

Une politique de gestion des vulnérabilités doit couvrir la réception, le triage, la reproduction, l’évaluation d’impact, la correction, la publication d’avis et le suivi de déploiement. L’adresse de signalement ne suffit pas : il faut un canal capable de recevoir des preuves, des journaux et des rapports chiffrés sans exiger que la personne signalante traverse un portail de vingt-sept champs obligatoires.

Lorsqu’une vulnérabilité activement exploitée est identifiée, ou lorsqu’un incident grave affecte la sécurité du produit, le fabricant doit signaler l’événement à l’Agence de l’Union européenne pour la cybersécurité, European Union Agency for Cybersecurity (ENISA), via le point de contact prévu. Le mécanisme comprend une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final dans le délai réglementaire applicable, généralement un mois.

Le signalement réglementaire ne remplace pas la réponse opérationnelle. Il faut pouvoir répondre aux questions qui comptent réellement : quelles versions sont touchées, quelles configurations rendent l’exploitation possible, quels indicateurs permettent de détecter l’attaque, quelle mesure de contournement limite le risque, et quelle mise à jour corrige définitivement le défaut.

Une vulnérabilité corrigée mais non déployée reste exploitable. Une mise à jour disponible mais impossible à installer hors ligne, derrière un proxy ou dans un environnement isolé n’est pas une capacité de remédiation. Elle est une promesse emballée dans du JavaScript.

L’articulation avec la directive Network and Information Security 2 (NIS2) doit rester nette. Le CRA régit principalement le produit et son fabricant. NIS2 impose des mesures et des notifications à certaines entités opératrices. Un fabricant peut devoir signaler au titre du CRA pendant qu’un opérateur client gère ses propres obligations NIS2. La gouvernance cybersécurité doit prévoir ces flux sans confondre responsabilité produit et responsabilité d’exploitation.

Surface d’attaque des produits connectés

Les vecteurs les plus fréquents ne sont pas mystérieux : interface web exposée, mot de passe initial partagé, bibliothèque obsolète, mise à jour non signée, mécanisme de récupération accessible, journal trop pauvre et accès support surdimensionné. La surface d’attaque doit être modélisée par frontière : démarrage, administration locale, administration distante, mise à jour, stockage de secrets, interfaces réseau, chaîne de compilation et dépendances tierces.

Le démarrage sécurisé doit vérifier l’authenticité et l’intégrité du logiciel avant exécution. Une racine de confiance matérielle est préférable lorsque le produit le permet. La clé de signature ne doit jamais résider dans le dépôt de code, dans une variable d’intégration continue ou dans un poste d’administration. Un Hardware Security Module (HSM), module matériel protégeant les opérations cryptographiques, ou un service de signature isolé réduit fortement le risque d’exfiltration.

La rotation des clés de signature est obligatoire à prévoir avant le premier déploiement. Une clé compromise sans mécanisme de remplacement impose soit une mise à jour acceptée par une clé volée, soit un parc impossible à réparer. Les deux options ont le charme discret d’une assurance incendie imprimée sur du papier inflammable.

Les mises à jour doivent être signées, versionnées, protégées contre le rejeu et contrôlées contre le retour arrière non autorisé. Interdire tout retour arrière est toutefois dangereux : une correction défectueuse doit pouvoir être annulée. La règle saine consiste à autoriser un rollback vers une version explicitement approuvée, avec conservation de l’état de sécurité et traçabilité de l’opération.

Le produit ne garantit pas la sécurité du réseau qui l’héberge, ni l’administration des comptes côté client, ni la protection physique du matériel. Ces protections doivent venir de la segmentation réseau, de la gestion des identités et des accès, Identity and Access Management (IAM), de la supervision et de procédures de reprise. Une architecture produit correcte n’annule pas la nécessité de durcir les identités.

Exemple reproductible : vérifier une mise à jour signée

L’exemple suivant vérifie localement une archive de mise à jour et sa signature OpenSSL. Il illustre un contrôle minimal de chaîne de confiance. En production, la clé publique doit être ancrée dans le produit ou distribuée par un canal authentifié, pas téléchargée depuis le même serveur que le fichier à vérifier.

# Vérifier que l'archive firmware-2.4.1.bin correspond à sa signature.
# La clé publique doit provenir du fabricant via un canal déjà approuvé.
openssl dgst -sha256 \
  -verify fabricant-update-public.pem \
  -signature firmware-2.4.1.bin.sig \
  firmware-2.4.1.bin

# Le code de retour doit être 0 et la sortie doit contenir "Verified OK".
# Tout autre résultat interdit l'installation de la mise à jour.

Cette vérification ne garantit pas que la mise à jour est sans défaut, qu’elle corrige la bonne vulnérabilité ou qu’elle est compatible avec la configuration installée. Elle garantit uniquement que le fichier correspond à une signature produite avec la clé privée associée. La sécurité ne se résume jamais à une commande qui affiche « OK ». Heureusement, sinon les audits seraient beaucoup moins chers et beaucoup plus inquiétants.

🐝 Ce qui arrive si on s’en passe

Sans ce dispositif, l’absence d’inventaire de composants rend impossible de répondre à la seule question utile le jour d’une publication de faille : ce produit est-il concerné, et dans quelles versions. La recherche se fait alors à la main, dépôt par dépôt, pendant que l’exploitation circule. Sans période de support annoncée, un parc continue d’être exploité des années après la dernière correction, sans que l’exploitant sache qu’il n’en recevra plus. Sans canal de signalement fonctionnel, une découverte externe part vers une publication directe plutôt que vers le fabricant. Sans journalisation exportable ni indicateurs fournis, un client touché ne peut ni confirmer une compromission ni dater son début. Faute de rotation prévue des clés de signature, une clé compromise laisse le choix entre accepter des mises à jour signées par un tiers ou renoncer à toute correction.

🦫 Explication de la marmotte 🍫

Le Cyber Resilience Act impose des règles aux entreprises qui vendent en Europe des appareils ou logiciels capables d’échanger des données. Avant de vendre, le fabricant doit chercher les risques : accès non autorisé, erreur de programmation, vol de données, arrêt du produit ou modification frauduleuse de son logiciel.

Le produit doit être livré avec des réglages qui limitent les risques. Il ne doit pas utiliser le même mot de passe pour tous les exemplaires, ni laisser actives des fonctions réservées aux réparations. Les mises à jour doivent être contrôlées avant installation afin d’éviter qu’une personne malveillante remplace le logiciel par un programme dangereux.

Le fabricant doit aussi connaître les éléments logiciels inclus dans son produit. Cette liste permet de savoir rapidement si un défaut découvert dans un composant touche le produit vendu. Lorsqu’un défaut grave est exploité, le fabricant doit avertir l’autorité européenne compétente dans des délais courts, analyser l’impact et fournir une correction ou une mesure temporaire.

Cette obligation dure après la vente. Le fabricant annonce combien de temps les corrections de sécurité seront fournies et doit organiser leur diffusion. Si la clé servant à autoriser les mises à jour est volée, il faut pouvoir la remplacer. Si une mise à jour échoue, il faut pouvoir revenir à une version approuvée. Le règlement ne protège pas le réseau du client ni ses comptes administrateurs : ces protections doivent être gérées séparément.

Pages voisines

La citent

Exigences CRA pour produits connectés sécurisés

Elle cite

: les deux pages se citent l’une l’autre.

Exigences CRA pour produits connectés sécurisés

Exigences CRA pour produits connectés sécurisés

Périmètre du CRA et responsabilité du fabricant

Exigences de sécurité et preuves de conformité

Cycle de vie, vulnérabilités et signalement CRA

Surface d’attaque des produits connectés

Exemple reproductible : vérifier une mise à jour signée

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines