La fabrication d’un objet connecté est traditionnellement traitée comme un projet matériel : électronique, boîtier, alimentation, CEM, firmware, tests de production, documentation, puis commercialisation.

Or un produit connecté ne reste pas figé après sa livraison. De nouvelles vulnérabilités apparaissent dans le code propre du fabricant, dans les bibliothèques utilisées, dans le système d’exploitation ou dans les composants de communication. Le paysage des menaces peut évoluer pendant que le produit fonctionne des années durant sur le même site.

Le règlement sur la cyberrésilience (Cyber Resilience Act, CRA) de l’Union européenne fait de ce risque lié au cycle de vie une obligation du fabricant.

Où en sommes-nous en septembre 2026 ?

Le CRA, c’est-à-dire le règlement (UE) 2024/2847, est entré en vigueur le 10 décembre 2024.

Les principales exigences relatives aux produits s’appliquent à partir du 11 décembre 2027. Les obligations de signalement, en revanche, s’appliquent déjà depuis le 11 septembre 2026. La préparation n’est donc pas un projet lointain qui ne commencerait qu’à la fin de 2027.

Le règlement couvre les produits matériels et logiciels comportant des éléments numériques ; chaque fabricant doit déterminer, pour son propre produit, le champ d’application exact, la catégorie de produit et la procédure d’évaluation de la conformité.

Une passerelle IoT industrielle, un compteur capable de communiquer en réseau, un contrôleur intelligent ou le logiciel associé relève fort probablement d’une gamme de produits qu’il convient de réexaminer de manière réfléchie en raison du CRA.

La sécurité dès la conception n’est plus un slogan

Le règlement impose des exigences de cybersécurité obligatoires lors de la conception, du développement, de la production et de la maintenance. La sécurité ne peut donc pas être « plaquée » sur le produit fini au moyen d’un test d’intrusion en fin de projet.

Dès l’architecture, il faut notamment décider :

  • quels services sont accessibles par défaut ;
  • comment l’appareil est identifié de manière unique ;
  • s’il existe des identifiants d’usine, partagés ou faciles à deviner ;
  • comment les données sont protégées en transit et au repos ;
  • comment l’accès peut être restreint ;
  • comment les événements de sécurité peuvent être journalisés ;
  • ce qui se passe en cas d’entrée erronée ou manipulée ;
  • comment un état sûr peut être rétabli.

Le principe de surface d’attaque minimale signifie que ce qui n’est pas nécessaire au fonctionnement du produit ne doit pas être accessible par défaut.

La capacité de mise à jour est une fonction du produit

Il ne suffit pas de concevoir un appareil connecté pour qu’il paraisse sûr le jour de la vente. Il doit aussi pouvoir être mis à jour en toute sécurité.

Cela peut nécessiter :

  • un firmware signé numériquement et dont l’intégrité est vérifiée ;
  • un canal de mise à jour sécurisé ;
  • la gestion des versions et de la compatibilité ;
  • la restauration après une mise à jour défaillante ;
  • une gestion de parc à grande échelle mais maîtrisée ;
  • un journal des mises à jour et le statut d’installation ;
  • une communication claire de la période de support.

La mise à jour OTA n’apporte pas à elle seule la sécurité. Sans vérification de signature, gestion des droits, retour arrière (rollback) ni preuve d’installation, le mécanisme de mise à jour peut lui-même devenir une surface d’attaque.

La gestion des vulnérabilités sur toute la période de support

L’un des changements majeurs du CRA est qu’il aborde la sécurité des produits comme un processus. Le fabricant doit être en mesure de recevoir, d’évaluer, de corriger et de communiquer les vulnérabilités.

Cela suppose aussi une organisation interne opérationnelle :

  • qui reçoit les signalements de sécurité ;
  • comment la gravité et l’impact sont évalués ;
  • quelles versions du produit sont concernées ;
  • quel composant est à l’origine du problème ;
  • comment le correctif est élaboré et testé ;
  • comment il parvient aux clients ;
  • comment la clôture peut être documentée.

Une simple adresse e-mail ne constitue pas un processus de gestion des vulnérabilités.

Il faut savoir ce que contient le firmware

Les firmwares et logiciels modernes sont rarement constitués uniquement de code maison. Bibliothèques open source, composants du système d’exploitation, piles réseau et SDK de fournisseurs s’empilent les uns sur les autres.

Si l’un d’eux devient vulnérable, le fabricant doit savoir quels produits et quelles versions sont concernés. Cela exige un inventaire ordonné des dépendances et des composants. La nomenclature logicielle (SBOM) peut être un outil important à cet égard.

La SBOM n’est toutefois qu’un inventaire. Elle n’apporte de la valeur que si elle est reliée à la gestion des versions, aux informations sur les vulnérabilités, au parc d’appareils concerné et au processus de mise à jour.

L’obligation de signalement exige une capacité de détection

Depuis le 11 septembre 2026, les fabricants sont soumis à une obligation de signalement pour certaines vulnérabilités activement exploitées et certains incidents de sécurité graves. Le fabricant doit suivre la procédure détaillée et les orientations en vigueur des autorités en fonction de son rôle et de son produit.

D’un point de vue pratique, une chose est toutefois certaine : on ne peut pas signaler dans les délais ce que l’organisation n’est pas capable de détecter, de faire remonter en interne et de rattacher aux versions du produit.

Les prérequis du processus de signalement sont donc :

  • un registre des produits et des versions ;
  • un point de contact sécurité ;
  • une classification des incidents ;
  • des règles de décision et d’approbation ;
  • la communication avec les clients ;
  • un journal d’événements probant.

Derrière le marquage CE, il y aura des preuves de développement

Selon le CRA, le marquage CE des produits conformes indiquera également qu’ils satisfont aux exigences de cybersécurité. Selon la classification de risque du produit, une procédure d’évaluation de la conformité différente peut être nécessaire, avec l’intervention d’un organisme notifié (notified body) pour certaines catégories.

Cela exige un processus de développement documenté. Il faut conserver l’évaluation des risques, les décisions d’architecture, les résultats des tests, les informations sur les composants, la gestion des vulnérabilités et les preuves de publication des versions.

Il est très difficile de reconstituer après coup, de manière crédible, pourquoi une décision de sécurité a été prise des années plus tôt. La documentation doit donc être construite au fil du développement.

Qu’est-ce que cela signifie pour un développement de type OrigSmart ?

Compte tenu des compétences d’OrigSmart en matière de matériel, de passerelles et de plateforme, la sécurité ne peut pas s’arrêter au boîtier de l’appareil. L’ensemble du cycle de vie du système doit être géré comme un tout :

  • matériel et firmware sur mesure ;
  • communication de terrain ;
  • identité et configuration des appareils ;
  • mise à jour sécurisée ;
  • droits d’accès côté plateforme ;
  • journal d’événements et supervision ;
  • gestion des incidents et des vulnérabilités ;
  • processus d’exploitation côté client.

Maîtriser toute la chaîne de valeur est à la fois une responsabilité et un avantage concurrentiel. Le fabricant et intégrateur qui relie matériel, logiciel, exploitation et processus de sécurité vérifiables dès la conception du produit ne sera pas contraint de produire à la hâte des documents de conformité fin 2027.

L’essentiel du CRA n’est pas d’ajouter davantage de papiers à côté de l’objet connecté, mais de faire en sorte que le produit numérique demeure un risque de cybersécurité maîtrisable tout au long de son cycle de vie pris en charge.

Parlons de votre projet

Sources

Remarque : cet article constitue une information professionnelle générale et non un conseil juridique ou en matière de conformité.