01Cinq surfaces d'attaque, un écosystème
Un produit connecté est rarement un objet d'audit unique. Il faut considérer le matériel (interfaces de débogage et de mémoire, implantation des composants), le firmware (chaîne de démarrage, système de fichiers, secrets embarqués), les interfaces radio (notamment Wi-Fi, Bluetooth Low Energy, Zigbee, Thread, LoRaWAN, réseaux cellulaires et protocoles propriétaires sub-GHz), le backend cloud avec ses API ainsi que l'application mobile ou web associée. C'est exactement ce découpage que reflètent les cinq catégories d'exigences de l'OWASP ISVS – IoT Ecosystem, User Space Application, Software Platform, Communication et Hardware Platform. Un audit isolé de certaines couches passe généralement à côté des transitions, par exemple l'enrôlement d'un appareil dans un compte utilisateur.
02Analyse matérielle : UART, JTAG, SPI
L'analyse matérielle commence par l'identification des composants et des points de test sur la carte. En pratique, les consoles série (UART) exposent fréquemment des journaux de démarrage, un accès au bootloader ou un shell insuffisamment protégé ; les interfaces de débogage comme JTAG ou SWD permettent, selon l'état de verrouillage du contrôleur, d'arrêter le CPU et d'accéder à la mémoire en lecture et en écriture. Les puces flash externes sur SPI ou I2C peuvent dans bien des cas être lues in situ ou après dessoudage. L'audit vérifie donc non seulement l'existence de tels accès, mais aussi si les ports de débogage sont désactivés ou authentifiés en production, si le secure boot est effectif et si les paramètres sensibles sont stockés chiffrés ou dans un élément sécurisé.
03Extraction et analyse du firmware
Le firmware est obtenu via les téléchargements du fabricant, la capture de processus de mise à jour ou un dump mémoire, puis décompressé. L'analyse statique recherche des identifiants codés en dur, des clés privées et des certificats, des configurations non sécurisées ainsi que des composants obsolètes, confrontés aux vulnérabilités connues via une nomenclature logicielle (SBOM). Elle est complétée par une analyse dynamique sur le système en fonctionnement ou émulé. L'OWASP Firmware Security Testing Methodology (FSTM) décrit cette démarche en neuf phases, de la collecte d'informations à la vérification des constats, en passant par l'extraction et l'émulation. La question centrale reste la capacité de mise à jour : la signature d'une mise à jour est-elle réellement vérifiée, et un retour (downgrade) vers une version antérieure vulnérable peut-il être empêché ?
04Référentiels d'audit : OWASP ISVS et ISTG, ETSI EN 303 645
Des référentiels ouverts couvrent aussi bien les exigences que l'exécution des tests. L'OWASP ISVS regroupe les exigences de sécurité des écosystèmes IoT en cinq catégories et est publié en Release Candidate 1.0RC ; depuis sa version 1.0 du 1er mars 2024, l'OWASP ISTG y ajoute une méthodologie de pentest avec un modèle d'appareil et d'attaquant ainsi qu'un catalogue de cas de test couvrant notamment les interfaces radio, les unités de traitement, la mémoire de l'appareil, les interfaces internes et physiques, ainsi que le firmware et le mécanisme de mise à jour. Au niveau produit, l'ETSI EN 303 645 dans sa version V3.1.3 (2024-09) définit un socle pour l'IoT grand public avec 13 domaines thématiques – de la suppression des mots de passe universels par défaut au stockage sécurisé des paramètres sensibles pour la sécurité, en passant par le traitement des signalements de vulnérabilités entrants – complété par un chapitre sur les dispositions de protection des données. La méthodologie d'évaluation correspondante est fournie par l'ETSI TS 103 701 (V2.1.1, 2025-05) avec des cas de test par provision ; le BSI fonde son label de sécurité informatique (IT-Sicherheitskennzeichen) pour les appareils grand public intelligents sur ces deux documents. Une première auto-évaluation selon l'ISVS est possible via le self-assessment librement accessible sur isvs.vamisec.com.
05Cadre réglementaire : acte délégué RED et CRA
Le règlement délégué (UE) 2022/30 rend applicables les exigences de cybersécurité de l'article 3, paragraphe 3, points d), e) et f) de la directive 2014/53/UE sur les équipements radioélectriques à certaines catégories d'équipements radio – les appareils connectés à Internet, les appareils traitant des données à caractère personnel (notamment les produits de garde d'enfants, les jouets et les appareils portés sur le corps) ainsi que les appareils traitant des valeurs virtuelles ou de la monnaie ; les produits soumis à une réglementation sectorielle, comme les dispositifs médicaux ou les équipements aéronautiques et automobiles, en sont exclus. Les exigences s'appliquent depuis le 1er août 2025, le règlement délégué (UE) 2023/2444 ayant reporté l'échéance initiale de douze mois. Les normes EN 18031-1, -2 et -3 sont inscrites au Journal officiel comme normes harmonisées (décision d'exécution (UE) 2025/138 du 28 janvier 2025) – avec toutefois des restrictions, notamment pour les configurations dans lesquelles l'utilisateur peut renoncer à définir un mot de passe ; sur ces points, la présomption de conformité ne s'applique pas. En parallèle s'applique le Cyber Resilience Act (règlement (UE) 2024/2847) : les obligations de notification des vulnérabilités activement exploitées et des incidents graves s'appliquent à partir du 11 septembre 2026, les autres obligations à partir du 11 décembre 2027 ; à cette date, la Commission a décidé d'abroger le règlement délégué (UE) 2022/30 afin d'éviter une double réglementation.
06Déroulement type d'un test
Un pentest IoT commence par le cadrage : les objets d'audit, le modèle d'appareil et d'attaquant (accès physique et niveau d'autorisation), le nombre d'échantillons de test et les risques de démontage destructif sont définis, complétés par une modélisation des menaces menée conjointement. Suivent la collecte d'informations, l'analyse du matériel et des interfaces, l'extraction du firmware avec analyse statique, l'examen des protocoles radio et réseau ainsi que de l'API cloud, du processus d'enrôlement et de l'application – chaque constat étant vérifié sur l'appareil en fonctionnement. Le résultat est un rapport avec des preuves reproductibles, une évaluation des risques compréhensible et une liste de mesures classées par effort et par impact ; un retest atteste de l'efficacité de la remédiation. Pour les fabricants, cette documentation constitue également un élément de preuve : l'annexe I, partie II du Cyber Resilience Act exige des tests et des contrôles efficaces et réguliers de la sécurité du produit ainsi que l'identification et la documentation des vulnérabilités et des composants, y compris une nomenclature lisible par machine.
