Sommaire de l’article
Un objet connecté n’est pas un petit ordinateur posé dans un local protégé. Il est vendu, installé chez des clients, parfois dans l’espace public. N’importe qui peut en acheter un, le démonter et l’étudier à loisir. Une faille trouvée sur un exemplaire vaut souvent pour tout le parc.
C’est pourquoi la sécurité d’un produit IoT se décide à la conception, quand on choisit les composants, l’architecture et les protocoles. Après la mise sur le marché, il reste la mise à jour à distance, si elle a été prévue.
Les quatre surfaces d’attaque d’un objet connecté
| Surface | Ce qu’on y trouve | Attaques typiques |
|---|---|---|
| Matériel | Ports de debug, mémoire flash, bus internes | Lecture de la flash, console série ouverte, injection de fautes |
| Firmware | Système, applications, bibliothèques, secrets | Mots de passe codés en dur, composants vulnérables, clés communes à tous les produits |
| Radio | Wi-Fi, Bluetooth, LoRa, Zigbee, cellulaire | Écoute, rejeu, appairage non authentifié, brouillage |
| Cloud et applications | API, application mobile, interface web | Défaut d’autorisation, accès aux données d’autres clients, prise de contrôle à distance |
Les attaques les plus graves combinent souvent plusieurs surfaces. Une clé extraite de la flash d’un seul appareil permet, par exemple, d’usurper n’importe quel appareil auprès du cloud si tous partagent la même.
Intégrer la sécurité à chaque étape
Spécifications : l’analyse de risque
Avant de choisir un composant, il faut savoir ce qu’on protège, contre qui, et ce que coûterait une compromission : la sécurité des personnes, les données des utilisateurs, la disponibilité d’un service, la propriété intellectuelle. Cette analyse fixe le niveau d’exigence et sert de fil conducteur aux normes. L’EN 18031 comme le CRA demandent de pouvoir la présenter.
Architecture et choix des composants
- un processeur ou microcontrôleur capable de démarrage sécurisé et de verrouillage du debug
- un élément de confiance (élément sécurisé, TPM, zone de confiance du processeur) pour garder les clés
- des protocoles radio utilisés avec leurs modes sécurisés, et un appairage authentifié
- un cloud conçu pour que chaque appareil n’accède qu’à ses propres données.
Développement
- aucun mot de passe par défaut commun à tous les produits : un secret propre à chaque appareil, ou un choix imposé à l’installation
- une identité unique par appareil, un certificat provisionné en production
- des bibliothèques suivies, avec une nomenclature logicielle (SBOM)
- une mise à jour à distance signée, détaillée dans notre article Mise à jour sécurisée d’un système embarqué.
Pour les produits sous Linux, notre article Sécuriser un Linux embarqué détaille le durcissement du système.
Vérification avant la mise sur le marché
Un test d’intrusion sur le produit réel, matériel compris, montre ce qu’un attaquant obtient vraiment. Il se fait idéalement sur les prototypes, quand corriger coûte encore peu.
Après la mise sur le marché
Une politique de divulgation des vulnérabilités (un contact publié, un délai de réponse), une veille sur les composants et un processus de correction. Le CRA y ajoute le signalement des vulnérabilités activement exploitées sous 24 heures.
Ce que demandent les normes
| Texte | Produits concernés | Statut |
|---|---|---|
| ETSI EN 303 645 | Objets connectés grand public | Norme volontaire, référence en Europe : 13 recommandations, dont l’absence de mot de passe par défaut universel |
| EN 18031-1, -2 et -3 | Équipements radio (directive RED) | Obligatoire depuis le 1er août 2025 pour les produits mis sur le marché |
| Cyber Resilience Act | Tous les produits comportant des éléments numériques | Signalements depuis le 11 septembre 2026, ensemble des exigences au 11 décembre 2027 |
| IEC 62443-4-1 et 4-2 | Composants industriels | Référence pour le cycle de développement sécurisé et les exigences des composants OT |
Ces textes se recoupent largement. Un produit conçu proprement selon l’EN 303 645 ou l’EN 18031 aura fait une bonne partie du chemin vers le CRA. Notre article Mise en conformité EN 18031 détaille ce qui est obligatoire aujourd’hui.
Vos questions sur la sécurité des objets connectés
Quand faut-il penser à la sécurité dans un projet IoT ?
Dès les spécifications. Le choix du processeur, de l’élément de confiance et de l’architecture cloud conditionne ce qui sera possible ensuite. Un composant sans démarrage sécurisé ou une architecture où tous les appareils partagent une clé se corrigent mal après coup.
Mon produit est-il concerné par l’EN 18031 ?
Si c’est un équipement radio (Wi-Fi, Bluetooth, cellulaire, LoRa…) capable de communiquer sur internet, de traiter des données personnelles ou de manipuler de l’argent, il entre dans le champ des exigences cybersécurité de la directive RED, que l’EN 18031 permet de démontrer.
Un test d’intrusion suffit-il à sécuriser un produit ?
Non. Il vérifie le résultat à un instant donné et trouve des failles, mais ne remplace pas une conception sécurisée. Le plus efficace est de combiner analyse de risque en amont, revue de conception et test d’intrusion sur prototype.
Qu’est-ce qu’une politique de divulgation des vulnérabilités ?
C’est l’engagement public du fabricant sur la façon de recevoir et traiter les vulnérabilités qu’on lui signale : un contact, un délai de réponse, un suivi. L’EN 303 645 la recommande et le CRA l’impose.
Ce que nous faisons avec vous
Nous accompagnons les fabricants de la conception à la mise sur le marché : conception électronique et firmware sécurisés, RSSE et accompagnement produit, test d’intrusion matériel et IoT, et mise en conformité EN 18031 ou CRA.
Pour vos équipes, la formation Sécuriser un système embarqué couvre les attaques matérielles et radio, la cryptographie et la sécurité dès la conception.
Un objet connecté en conception ou déjà sur le marché ? Parlons de votre produit.
Partager : LinkedIn Facebook E-mail
Un projet à sécuriser ?
Échangeons sur votre périmètre, vos usages et vos priorités de sécurité.
Échanger avec un expert
Expertise cybersécurité IoT, IT, OT et Web.
Découvrir notre équipe
