Pentest IoT et objets connectés

Le pentest IoT est une attaque contrôlée menée sur un objet connecté et sur tout ce qui gravite autour : le firmware qui tourne dessus, les interfaces de débogage restées accessibles sur la carte, les liaisons radio, l’application compagnon et l’API dorsale. Un objet connecté n’existe jamais seul, et le chemin d’attaque se trouve presque toujours à la jonction entre ces éléments.

Nous travaillons sur l’objet lui-même, en laboratoire : extraction et analyse du firmware, accès par UART ou JTAG, écoute et rejeu du trafic BLE, Zigbee ou LoRa, examen du mécanisme de mise à jour OTA. Vous recevez un rapport en français, chaque vulnérabilité accompagnée d’une preuve reproductible, et le contre-audit est inclus sans surcoût.

Test d’intrusion d’objets connectés, de firmware et de systèmes embarqués

Ils nous font confiance

  • Logo de Raiffeisen Processing Centre
  • Logo de Penta Hospitals
  • Logo de Pixel Federation
  • Logo du ministère slovaque des Finances
  • Logo de DanubePay
  • Logo d’Alison
  • Logo de Ditec
  • Logo de Sanaclis
  • Logo de Piano
  • Logo d’Ultima Payments
  • Logo d’Amerge
  • Logo de Digital Systems

Qu’est-ce qu’un pentest IoT ?

Un test d’intrusion (pentest) sur un objet connecté consiste à reproduire, dans un cadre contractuel et avec votre autorisation écrite, ce que ferait un attaquant qui a l’appareil entre les mains. La différence avec un pentest applicatif tient à la surface d’attaque : ici, l’attaquant peut ouvrir le boîtier, lire une mémoire flash et repartir avec le firmware. Les protections logicielles pèsent peu si la clé de chiffrement est stockée en clair dans une partition que l’on extrait en vingt minutes.

Cette prestation s’adresse aux fabricants d’équipements connectés, aux intégrateurs qui déploient des flottes d’appareils chez leurs clients et aux exploitants qui achètent ces objets sans pouvoir vérifier ce qu’ils contiennent. Dans les trois cas, la question est la même : que peut obtenir un attaquant qui dispose d’un exemplaire, d’une antenne et de quelques jours ?

Le sujet devient aussi réglementaire. Le règlement (UE) 2024/2847 sur la cyberrésilience, dit Cyber Resilience Act, fixe des exigences essentielles de cybersécurité aux produits comportant des éléments numériques mis sur le marché de l’Union, ainsi qu’une obligation de traitement des vulnérabilités pendant la durée de support. L’essentiel de ses obligations s’applique à compter du 11 décembre 2027. C’est un règlement européen d’application directe, et non une loi française : nous le citons comme une échéance de conception. Dernière vérification : 11 septembre 2026.

Les environnements industriels — OT, ICS, SCADA, automates et supervision — obéissent à d’autres contraintes de continuité et à un référentiel distinct, au premier rang duquel la CEI 62443. Nous les cadrons séparément : ils ne relèvent pas de cette page. Si votre projet mêle les deux, signalez-le au cadrage et nous découperons la mission en deux volets.

Objectifs d’un pentest IoT

Un pentest IoT ne cherche pas à produire une liste de vulnérabilités théoriques. Il répond à quatre questions précises, posées avant le début de la mission et reprises une à une dans le rapport.

Savoir ce qu’un attaquant obtient réellement

Extraction du firmware, récupération des secrets embarqués, accès à une interface d’administration non documentée : nous établissons ce qui est atteignable à partir d’un exemplaire du produit, et non ce qui serait théoriquement possible.

Mesurer l’impact à l’échelle de la flotte

Une clé identique sur tous les appareils transforme la compromission d’une unité en compromission du parc. Nous vérifions si un secret extrait d’un objet ouvre l’accès aux autres et au service dorsal.

Vérifier la chaîne de mise à jour

Le mécanisme OTA est la seule voie de correction dont vous disposerez après la mise sur le marché. Nous testons la signature des images, le refus des versions antérieures et le comportement en cas de coupure.

Obtenir des preuves opposables

Chaque constat est documenté avec les commandes, le matériel employé et le résultat obtenu, dans une forme que vos équipes peuvent rejouer et que votre auditeur peut lire sans interprète.

Types d’objets connectés que nous testons

Le périmètre change beaucoup d’un produit à l’autre. Voici les familles sur lesquelles nous intervenons le plus souvent ; si la vôtre n’y figure pas, la démarche de cadrage reste identique.

Produits connectés grand public

Caméras, serrures et sonnettes connectées, électroménager, objets de santé, traceurs. Ce sont les produits qu’un attaquant peut acheter dans le commerce, démonter chez lui et analyser sans limite de temps.

Passerelles et concentrateurs

Passerelles LoRaWAN, box domotiques, concentrateurs Zigbee ou Thread. La passerelle voit passer le trafic de tous les objets qu’elle dessert : sa compromission vaut souvent celle du site entier.

Équipements techniques de bâtiment

Contrôle d’accès, gestion technique du bâtiment, bornes de recharge, compteurs et capteurs communicants. Ces équipements restent en place dix ans et reçoivent rarement les mises à jour prévues au catalogue.

Approches : boîte noire, boîte grise, boîte blanche

Trois niveaux d’information, trois budgets, trois profondeurs de couverture. Sur un objet connecté, le choix est moins tranché que sur une application web : même en boîte noire, un attaquant patient finit par obtenir le firmware. La boîte grise reflète donc souvent mieux la réalité de la menace, à budget égal.

Boîte noire (black box)

Nous partons de l’objet et de rien d’autre : ni schéma, ni image de firmware, ni compte. C’est la simulation la plus fidèle d’un attaquant externe qui achète votre produit dans le commerce. Le revers est budgétaire : le temps consacré à obtenir un premier accès n’est plus disponible pour tester la suite.

Boîte grise (grey box)

Nous recevons la documentation d’architecture, un compte utilisateur, parfois une image du firmware et le brochage de la carte. C’est l’approche que nous recommandons par défaut sur l’IoT : elle supprime la phase de découverte et concentre les jours-homme sur l’exploitation réelle.

Boîte blanche (white box)

Accès au code source, aux schémas électroniques, à la documentation des clés de signature et à un exemplaire de développement déverrouillé. C’est le niveau le plus complet, adapté à une revue avant mise sur le marché ou à un produit dont la compromission aurait des conséquences physiques.

Notre méthodologie

Notre méthodologie et le déroulement de la mission

Nous nous appuyons sur des référentiels publics plutôt que sur une méthode maison invérifiable : l’OWASP IoT Top 10 et la Firmware Security Testing Methodology (FSTM) de l’OWASP pour l’objet et son firmware, le WSTG pour les interfaces web d’administration, le MASTG pour l’application compagnon et le PTES pour la conduite générale de la mission. Le détail est publié sur nos méthodologies de test.

L’outillage automatisé sert à la cartographie et au tri initial : sur nos missions IoT, il représente moins d’un cinquième du temps passé. L’essentiel du travail est manuel, sur la carte et sur le firmware, parce qu’aucun scanner ne lit une mémoire flash dessoudée.

1

Cadrage, autorisation écrite et devis ferme

Nous définissons le périmètre exact : références des appareils, versions de firmware, fréquences radio concernées, comptes fournis, éléments hors périmètre. L’autorisation écrite et la fenêtre d’intervention sont signées avant toute manipulation. Les jours-homme et le prix sont fixés à ce moment-là et n’évoluent plus ensuite.

2

Reconnaissance et ouverture de l’objet

Identification des composants, repérage des pastilles de test, des ports UART, JTAG ou SWD, lecture des mémoires externes. Nous cherchons d’abord les accès prévus par le constructeur et restés ouverts en production : console de débogage sans mot de passe, mode bootloader accessible, journal série trop bavard.

3

Extraction et analyse du firmware

Récupération de l’image par la mémoire flash ou par le canal de mise à jour, décompression du système de fichiers, recherche de secrets codés en dur, de clés privées et de composants vulnérables. Rétro-ingénierie ciblée des fonctions sensibles : authentification, vérification de signature, chiffrement du stockage.

4

Radio, application compagnon et API dorsale

Écoute, rejeu et manipulation du trafic BLE, Zigbee ou LoRa ; appairage et chiffrement de la liaison ; tests de l’application mobile selon le MASTG ; tests de l’API dorsale, notamment l’authentification des appareils et le contrôle d’accès horizontal d’un numéro de série à un autre.

5

Rapport, restitution et contre-audit

Rapport rédigé en français et remis sous dix jours ouvrés, restitution en visioconférence avec vos équipes techniques, puis contre-audit après correction : nous rejouons les scénarios concernés et attestons de ce qui est corrigé. Il est inclus dans le prix, sans surcoût.

Périmètre

Ce que nous testons sur un objet connecté

Le périmètre va du silicium à l’API. Chacun de ces axes peut être retenu ou écarté au cadrage, selon le budget et selon le risque que vous cherchez à couvrir.

Système embarqué et démarrage

Chaîne de démarrage, bootloader, démarrage sécurisé lorsqu’il existe, durcissement du système, services exposés sur l’appareil et séparation des privilèges.

Firmware et mise à jour OTA

Signature et vérification des images, chiffrement du transport, protection contre le retour à une version vulnérable, secrets et certificats présents dans le système de fichiers.

Interfaces de débogage et accès physique

UART, JTAG, SWD, SPI et I2C, lecture directe des mémoires, protection en lecture du microcontrôleur, résistance à l’ouverture du boîtier.

Interfaces radio

BLE, Zigbee, LoRa, Wi-Fi, NFC et liaisons propriétaires sur bandes ISM : appairage, chiffrement, rejeu, brouillage et interception du trafic (MITM).

Application compagnon

Stockage local des jetons, épinglage de certificat, communication locale avec l’objet, partage d’accès entre utilisateurs et révocation effective des droits.

API dorsale et plateforme

Enregistrement et authentification des appareils, cloisonnement entre clients, contrôle d’accès horizontal d’un numéro de série à un autre, files MQTT, droits d’administration des flottes.

Comparatif

Pentest IoT ou pentest applicatif : quelle différence ?

Un pentest applicatif classique s’arrête au logiciel. Un pentest IoT touche des couches qu’il ne peut pas atteindre : le matériel, le firmware et la radio.

CritèrePentest IoTPentest applicatif classique
PérimètreObjet, firmware, interfaces matérielles, liaisons radio, application compagnon et API dorsale.Application web ou mobile, API et services associés.
Hypothèse d’attaqueL’attaquant possède physiquement un exemplaire et dispose de temps.L’attaquant agit à distance, depuis le réseau.
Vulnérabilités typiquesSecrets codés en dur, port de débogage ouvert, mise à jour non signée, clé partagée par toute la flotte, trafic radio rejouable.Injection SQL, XSS, contournement d’authentification, contrôle d’accès défaillant.
RéférentielsOWASP IoT Top 10 et FSTM, MASTG pour l’application compagnon, PTES pour la conduite de mission.OWASP WSTG et ASVS.
LivrableRapport couvrant l’objet, la flotte et le service dorsal.Rapport couvrant l’application et son API.

Vous ne savez pas quel test correspond à votre besoin ? Demandez un devis, nous cadrons ensemble.

Livrables : rapport, restitution et contre-audit

Ce que vous achetez n’est pas une intervention, c’est ce qu’il en reste une fois les testeurs partis. Voici précisément ce qui vous est remis.

Rapport rédigé en français

Une synthèse pour la direction, puis le détail technique : chaque vulnérabilité avec sa criticité, ses conditions d’exploitation, son impact à l’échelle de la flotte et la correction attendue, classées par priorité. La version anglaise est fournie sur demande, sans supplément.

Preuves d’exploitation reproductibles

Commandes, matériel employé, captures radio et fichiers extraits : vos équipes rejouent le scénario et vérifient elles-mêmes la correction. Aucun constat n’est livré sans démonstration, et aucune sortie brute d’outil n’est recopiée dans le rapport.

Restitution avec vos équipes

Une visioconférence avec vos développeurs, vos électroniciens et vos responsables produit, pour arbitrer ce qui se corrige dans le firmware, ce qui se corrige côté plateforme et ce qui relève de la prochaine révision matérielle.

Contre-audit inclus, sans surcoût

Après correction, nous rejouons les scénarios concernés et publions un rapport de contre-audit indiquant ce qui est corrigé et ce qui ne l’est pas. Il est compris dans le prix, dans les 90 jours suivant la remise du rapport initial.

Pourquoi confier votre pentest IoT à Haxoris ?

Nous ne détenons aucune qualification délivrée par une autorité nationale et nous ne le laissons pas entendre. Ce que nous mettons en face, ce sont quatre engagements que vous pouvez vérifier avant de signer.

Contre-audit inclus, sans surcoût :

La vérification après correction fait partie de la prestation, dans les 90 jours suivant la remise du rapport. Nous ne facturons pas une journée de plus pour constater que vous avez corrigé.

Nos tarifs sont publics :

Le devis est établi en jours-homme, chiffré au cadrage et ferme. Nos repères de prix sont publiés dans l’article prix d’un test d’intrusion, avant tout échange commercial.

Vous savez qui teste :

Le nom, le parcours et les certifications du consultant qui réalise votre mission (OSCP, OSWE, OSEP) vous sont communiqués au cadrage. Vous lui parlez directement pendant la mission et lors de la restitution.

Prestataire européen, données dans l’Union :

Haxoris OÜ est une société établie dans l’Union européenne. Les images de firmware, les captures radio et les rapports sont traités et conservés dans l’UE, sous RGPD, puis détruits à l’issue de la durée convenue.

Témoignages clients

Ce que nos clients disent de nous

Foire aux questions

01 Combien coûte un pentest IoT ?

Le prix dépend du nombre de références à couvrir, de la profondeur retenue et de l’étendue du périmètre radio. Une mission portant sur un objet unique et son application compagnon se situe généralement entre 5 et 10 jours-homme ; un écosystème complet, avec plusieurs produits, une passerelle et la plateforme dorsale, demande plutôt 3 à 6 semaines. Le chiffrage est établi au cadrage et ne bouge plus ensuite. Nos repères de prix sont détaillés dans l’article prix d’un test d’intrusion.

02 Combien de jours-homme faut-il prévoir ?

Comme ordre de grandeur : 5 à 10 jours-homme pour un objet et son firmware, 2 à 4 jours de plus pour l’application compagnon, 3 à 5 jours pour une analyse radio approfondie et 3 à 5 jours pour l’API dorsale. Ces volumes se cumulent selon le périmètre retenu, et nous annonçons la fourchette au cadrage plutôt que de découvrir en cours de mission que le budget ne couvre pas la moitié du sujet.

03 Boîte noire ou boîte grise ?

Sur un objet connecté, nous recommandons la boîte grise dans la grande majorité des cas. En boîte noire, une part importante du budget est consommée à obtenir ce qu’un attaquant patient finira de toute façon par obtenir : l’image du firmware. En fournissant la documentation d’architecture, un compte et le brochage de la carte, vous transférez ces jours-homme vers l’exploitation réelle. La boîte blanche reste indiquée pour une revue avant mise sur le marché.

04 Devons-nous fournir un exemplaire physique de l’appareil ?

Oui, et nous demandons idéalement deux à trois exemplaires, dont un que nous pouvons ouvrir, dessouder et rendre inutilisable. Sans accès physique, le matériel, les interfaces de débogage et la protection en lecture du microcontrôleur ne peuvent pas être évalués. Si l’appareil ne peut pas quitter votre site, nous travaillons à partir d’une image de firmware, d’un banc de développement ou d’une intervention sur place, et le rapport indique alors ce qui n’a pas pu être vérifié.

05 Le contre-audit est-il inclus ?

Oui, et sans surcoût. Après vos correctifs, nous rejouons les scénarios concernés et remettons un rapport de contre-audit qui indique, constat par constat, ce qui est effectivement corrigé. Il est compris dans le prix initial, dans les 90 jours suivant la remise du rapport, et vous pouvez le transmettre à un client, à un donneur d’ordre ou à un auditeur. Vous pouvez aussi consulter un exemple de rapport anonymisé avant de vous engager.

06 Faut-il un prestataire qualifié pour réaliser un test d’intrusion ?

Non, pas pour un test commandé par une entreprise privée. Les qualifications délivrées par l’ANSSI relèvent d’une démarche volontaire instituée par le décret n° 2015-350 du 27 mars 2015 ; elles ne conditionnent pas la réalisation d’un test d’intrusion pour un donneur d’ordre privé. Haxoris ne détient aucune qualification de ce type et ne s’en prévaut pas. En revanche, les contrôles des systèmes d’information d’importance vitale ordonnés au titre de l’article L. 1332-6-3 du code de la défense sont réalisés par l’ANSSI, par des services de l’État désignés par le Premier ministre, ou par des prestataires de service qualifiés : nous ne soumissionnons pas sur ces prestations. Nous détaillons ce point dans un article dédié. Dernière vérification : 11 septembre 2026.

07 Le Cyber Resilience Act nous impose-t-il un test d’intrusion ?

Non, pas en ces termes. Le règlement (UE) 2024/2847 impose aux fabricants de produits comportant des éléments numériques des exigences essentielles de cybersécurité, une évaluation de la conformité avant mise sur le marché et un traitement des vulnérabilités pendant la durée de support ; il ne prescrit pas nommément de test d’intrusion. Un pentest est en revanche le moyen habituel de démontrer que ces exigences sont satisfaites. Le règlement est d’application directe dans toute l’Union et l’essentiel de ses obligations s’applique à compter du 11 décembre 2027 : ce n’est pas une loi française et nous ne le présentons pas comme telle. Dernière vérification : 11 septembre 2026.

08 Testez-vous aussi les environnements industriels (OT, ICS, SCADA) ?

Oui, mais dans une mission distincte. Un réseau industriel impose des contraintes de continuité, des protocoles spécifiques et un référentiel propre — la CEI 62443 — qui n’ont rien à voir avec l’analyse d’un objet grand public en laboratoire. Nous y commençons par des méthodes passives et planifions toute action active pendant une fenêtre de maintenance convenue. Si votre projet comporte les deux volets, nous les cadrons et les chiffrons séparément : demandez un devis en le précisant.

Vous voulez faire tester votre objet connecté ?

Décrivez-nous le produit, le nombre de références concernées et les liaisons radio utilisées. Nous revenons vers vous sous 24 h avec un périmètre, un nombre de jours-homme et un prix ferme.