Règlement européen sur la cyberrésilience : ce que cela change pour le suivi d’actifs

La cybersécurité du matériel connecté, c’était longtemps une slide en fin de présentation : une fonctionnalité qu’on mentionnait si un prospect posait la question, rarement la raison pour laquelle un contrat était signé. Le règlement européen sur la cyberrésilience (CRA) change cela. C’est le premier texte européen horizontal à imposer des exigences de cybersécurité sur tout le cycle de vie des « produits comportant des éléments numériques », et il s’applique à peu près à tout ce qui a une puce, une connexion et un client en Europe : des capteurs industriels aux compteurs intelligents, en passant par les traceurs installés sur des conteneurs réutilisables.

Comme le formulait Talking IoT, le CRA ouvre une nouvelle ère pour les fabricants d’appareils : la sécurité n’est plus optionnelle, elle doit être démontrée. Chez Sensolus, nous concevons des traceurs qui restent des années sur le terrain, connectés au cloud pendant toute cette période — ce basculement, nous le connaissons bien. Notre VP Engineering, Steven Van Hoof, a détaillé notre approche dans son livre blanc « Sleep Like a Baby Thanks to IoT: Security at Every Level ». Ligne par ligne, le règlement demande des choses que nous considérons déjà comme des pratiques standard chez Sensolus.

Une fois le jargon juridique écarté, le CRA repose sur une idée simple : les fabricants doivent maintenir la sécurité d’un produit connecté pendant toute sa durée de service, du jour de son expédition jusqu’à sa mise hors service. Concrètement, cela signifie :

1. Une sécurité intégrée dès le départ : aucune vulnérabilité exploitable connue à la livraison, et pas plus de surface d’attaque que le produit n’en a réellement besoin.

1. Un processus de gestion des vulnérabilités pendant toute la durée de vie prévue du produit, avec une nomenclature logicielle (SBOM) et des mises à jour de sécurité gratuites.

1. Un signalement rapide des vulnérabilités activement exploitées et des incidents graves : alerte précoce sous 24 heures, notification complète sous 72 heures et rapport final sous 14 jours (ou un mois pour les incidents).

1. Les documents pour l’attester : documentation technique, instructions d’utilisation, marquage CE et déclaration UE de conformité.

Le règlement est entré en vigueur le 10 décembre 2024, et le reste s’applique progressivement sur trois ans :

1. 11 juin 2026 : les règles de désignation des organismes notifiés qui réalisent les évaluations de la conformité par tierce partie commencent à s’appliquer.

1. 11 septembre 2026 : les obligations de signalement des vulnérabilités et des incidents deviennent contraignantes.

1. 11 décembre 2027 : le reste des dispositions principales du CRA, y compris les obligations d’évaluation de la conformité qui incombent aux fabricants, deviennent contraignantes.

Le non-respect expose à des amendes allant jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu — juste en dessous du plafond du RGPD, fixé à 20 millions d’euros ou 4 %.

Les produits classés « importants » par le CRA font l’objet d’un contrôle renforcé : la classe I (gestionnaires de mots de passe, VPN, systèmes d’exploitation à usage général) autorise l’auto-évaluation si des normes harmonisées sont appliquées, la classe II (pare-feu, systèmes de détection d’intrusion) exige toujours une évaluation par tierce partie, et les produits « critiques » (passerelles de compteurs intelligents, éléments sécurisés) nécessitent directement une certification. La plupart des appareils connectés, traceurs inclus, restent hors de ces catégories et suivent la voie par défaut de l’auto-évaluation. Mais les obligations de fond — conception sécurisée, gestion des vulnérabilités, signalement des incidents — s’appliquent quelle que soit la catégorie du produit. Aucun niveau n’admet le « on corrigera plus tard » comme réponse.

Les traceurs d’actifs illustrent parfaitement ce qui préoccupe le CRA : conçus pour rester des années sur le terrain sans surveillance, faciles à oublier une fois installés, et connectés en permanence à une plateforme cloud contenant de vraies données opérationnelles. Cette combinaison — déploiement long, faible visibilité, connectivité constante — correspond exactement au profil que le CRA cherche à couvrir.

Le règlement touche deux publics à la fois. Les fabricants d’appareils, dont les traceurs et les firmwares sont précisément les « produits comportant des éléments numériques » décrits par le texte. Et les entreprises qui achètent et déploient ces traceurs (logistique, industrie, aéronautique), à qui leurs propres auditeurs demanderont de plus en plus de prouver que leur matériel connecté est conforme. Les équipes achats qui demandaient hier « est-ce que ça fonctionne ? » commencent à demander « pouvez-vous me montrer votre processus de gestion des vulnérabilités ? ». Un fournisseur incapable de répondre devient un risque dès la mise en service.

C’est ici que le livre blanc de Steven mérite une lecture complète : ses trois principes recoupent étroitement ce que le CRA cherche à standardiser.

1. Secure by design.Pas un module en option, mais l’état par défaut de chaque traceur dès sa sortie de production : données chiffrées en transit et au repos, chaque appareil doté de sa propre identité et de sa propre gestion de clés plutôt que d’un identifiant partagé. Sensolus héberge sa plateforme dans l’UE sur AWS, avec des environnements séparés par client et des tenants dédiés là où c’est nécessaire (dans l’aéronautique, par exemple), et produit également son matériel dans l’UE, chez des partenaires comme Alps Alpine en Irlande. Comme le dit Steven, cette combinaison offre aux clients « des garanties contractuelles claires, une due diligence plus rapide et une adoption facilitée par les équipes conformité » — presque mot pour mot ce que recherche aujourd’hui une équipe achats attentive au CRA.
2. Gouvernance de la plateforme.L’authentification unique (SSO), l’authentification multifacteur (MFA) et le contrôle d’accès basé sur les rôles (RBAC) gardent la connexion simple pour les utilisateurs tout en restant stricts en arrière-plan. Chaque action est journalisée, si bien que des questions comme « qui a déployé la dernière mise à jour du firmware ? » ou « qui a modifié cette Geozone ? » trouvent toujours une réponse. La première surtout, puisqu’une mise à jour est exactement le type de changement susceptible d’introduire une vulnérabilité. Cela compte dès lors qu’on opère sous un règlement qui laisse 24 heures pour signaler un incident à partir du moment où on en a connaissance. Cette même piste d’audit aide aussi pendant la réponse : savoir ce qui a changé, quand et par qui, c’est ce qui permet à une équipe de contenir et d’annuler les dégâts, pas seulement de déposer le rapport dans les délais.
3. Une sécurité qui continue de fonctionner.Le firmware est chiffré et authentifié dès la première installation, les mises à jour sont vérifiées avant d’être considérées comme fiables, et les identifiants uniques permettent à Sensolus de détecter un appareil qui n’a rien à faire là avant qu’il n’entre. Une bonne illustration : un concessionnaire automobile américain a un jour signalé un problème de confidentialité concernant un traceur laissé par erreur dans un véhicule vendu. Le correctif de Sensolus est devenu une fonctionnalité standard : les Geozones peuvent désormais forcer un traceur à arrêter ou à limiter son enregistrement en dehors d’une zone convenue. C’est toute la différence entre la sécurité comme case à cocher et la sécurité comme routine : des tests d’intrusion indépendants chaque année, réalisés par un partenaire différent à chaque fois, dont les conclusions sont partagées avec les clients et réintégrées dans le produit.

Le CRA oblige les fabricants à maintenir la sécurité d’un produit aussi longtemps qu’il est raisonnablement susceptible de rester en service. Les nouvelles fonctionnalités ajoutées des années plus tard doivent donc répondre au même standard que ce qui a été livré le premier jour. C’est le test que les fonctionnalités d’IA commencent à poser dans tout l’IoT. Sensolus utilise déjà l’IA pour signaler des anomalies — un actif immobile bien plus longtemps que la normale, ou un autre sorti de sa zone — et pour affiner la précision de localisation, toujours dans les limites des droits d’accès existants de l’utilisateur : chaque action est journalisée et soumise aux mêmes contrôles SSO, MFA et RBAC que ceux qui encadrent un utilisateur humain. Comme le résume Steven : « d’abord la qualité des données et la confidentialité, ensuite l’IA. Sinon, on ne fait que se tromper plus vite. » Une bonne synthèse de ce que le CRA cherche à inscrire par défaut dans chaque produit connecté.

Il est tentant de voir le CRA comme une taxe de conformité : un audit de plus, un document de plus avant de signer. La lecture plus utile, celle que retient Steven en conclusion de son livre blanc, c’est qu’une sécurité bien faite est invisible au quotidien et évidente dans le résultat : tranquillité d’esprit, prévisibilité, et une due diligence plus rapide parce que les réponses étaient déjà vraies avant que quiconque ne pose la question.

C’est là que réside la véritable opportunité pour les entreprises qui gèrent des actifs connectés partout en Europe. Les fournisseurs qui ont déjà mis en place un chiffrement de bout en bout, un hébergement dans l’UE, une gouvernance stricte des accès et une véritable routine de gestion des vulnérabilités n’auront pas à improviser quand les obligations de signalement démarreront : ils transmettront simplement une documentation que les auditeurs de leurs clients réclament déjà. Pour tous les autres acteurs de la chaîne d’approvisionnement, c’est précisément la question à poser à ses fournisseurs dès maintenant, bien avant que le compte à rebours ne commence.

Si Steven a intitulé son livre blanc « Sleep Like a Baby Thanks to IoT », ce n’est pas un hasard : quand la conception sécurisée, l’hébergement dans l’UE et une vraie routine de réponse aux incidents sont déjà en place, le CRA n’a plus rien d’inquiétant.