{"id":2166,"date":"2026-07-29T08:00:00","date_gmt":"2026-07-29T07:00:00","guid":{"rendered":"https:\/\/ic-services.io\/?p=2166"},"modified":"2026-10-21T14:12:27","modified_gmt":"2026-10-21T13:12:27","slug":"iot-interception-legale-lpwan-m2m","status":"publish","type":"post","link":"https:\/\/ic-services.io\/fr\/resources\/blog\/iot-lawful-interception-lpwan-m2m\/","title":{"rendered":"IoT et interception l\u00e9gale : L'obligation croissante pour les op\u00e9rateurs LPWAN et M2M"},"content":{"rendered":"

Law enforcement interest in IoT data is growing as connected devices proliferate across networks. The Internet of Things (IoT) is transforming industries from logistics and agriculture to healthcare and smart cities. Billions of connected devices now communicate over cellular and non-cellular networks, generating vast quantities of machine-to-machine (M2M) data. For telecommunications operators \u2014 particularly those providing Low Power Wide Area Network (LPWAN) connectivity and M2M services \u2014 this growth brings not only commercial opportunity but also expanding regulatory obligations, including lawful interception.<\/p>\n\n\n\n

The application of lawful interception obligations to IoT and M2M communications is a developing area of regulation, but the direction of travel is clear: as IoT traffic grows and becomes more relevant to criminal investigations, law enforcement interest in IoT data is growing, and operators should expect more requests for data, mainly for subscriber, location and traffic data rather than live content. This article examines the current state of LI obligations for IoT operators, the technical challenges involved, and the steps operators should take to prepare.<\/p>\n\n\n\n

Pourquoi l'interception l\u00e9gale dans le cadre de l'IoT est-elle importante ?<\/h2>\n\n\n\n

The question of whether IoT and M2M communications fall within the scope of lawful interception obligations is primarily a legal one, and the answer varies by jurisdiction. In the European Union, the obligation to support lawful interception generally applies to providers of electronic communications services that are available to the public. Under the EU Electronic Communications Code, transmission services used for machine-to-machine communication are electronic communications services (Art. 2(4)(c) EECC). Whether they carry LI obligations depends on whether they are offered to the public and on national law, which sets the LI conditions and any exemptions.<\/p>\n\n\n\n

In Germany, \u00a7 170 TKG and the TK\u00dcV (Telekommunikations-\u00dcberwachungsverordnung) require operators of networks used for publicly available telecommunications services to provide interception capability, and M2M transmission services count as telecommunications services (\u00a7 3 No. 61(c) TKG). The TK\u00dcV exempts some systems from having to install interception facilities, for example systems used only to transmit measurement data (\u00a7 3(2) No. 4 TK\u00dcV) or systems with no more than 10,000 users (\u00a7 3(2) No. 5). Whether an IoT offering is exempt therefore depends on what it carries, not on the label ‘IoT’. In other EU member states the details differ.<\/p>\n\n\n\n

Even an operator that is exempt from installing interception facilities must cooperate with an individual order (in Germany, \u00a7 100a(4) StPO). It should therefore know how it would carry out an order on its IoT platform, even where no permanent LI system is required.<\/p>\n\n\n\n

Pourquoi les donn\u00e9es de l'Internet des objets (IoT) sont-elles importantes pour les forces de l'ordre ?<\/h2>\n\n\n\n

Les appareils connect\u00e9s \u00e0 l'Internet des objets (IoT) g\u00e9n\u00e8rent des donn\u00e9es pouvant s'av\u00e9rer tr\u00e8s pertinentes pour les enqu\u00eates criminelles. Les v\u00e9hicules connect\u00e9s fournissent des donn\u00e9es de localisation, des habitudes de conduite et des journaux de communication. Les appareils domotiques enregistrent des donn\u00e9es environnementales, des habitudes d'utilisation et, dans certains cas, des enregistrements audio ou vid\u00e9o. Les appareils de sant\u00e9 portables capturent des donn\u00e9es biom\u00e9triques et des habitudes de mouvement. Les capteurs IoT industriels peuvent r\u00e9v\u00e9ler des activit\u00e9s op\u00e9rationnelles, les mouvements au sein de la cha\u00eene d\u2019approvisionnement et les conditions environnementales. M\u00eame de simples appareils M2M, tels que les distributeurs automatiques ou les compteurs de services publics, g\u00e9n\u00e8rent des donn\u00e9es de localisation et d\u2019utilisation qui peuvent s\u2019av\u00e9rer pertinentes dans certaines enqu\u00eates.<\/p>\n\n\n\n

Comme services charg\u00e9s de l'application de la loi<\/a> \u00c0 mesure qu'ils prennent conscience du potentiel des donn\u00e9es de l'IoT en mati\u00e8re d'enqu\u00eates, ils sont de plus en plus enclins \u00e0 demander aux op\u00e9rateurs IoT de proc\u00e9der \u00e0 des interceptions ou \u00e0 la communication de donn\u00e9es. Les op\u00e9rateurs qui ne sont pas en mesure de r\u00e9pondre \u00e0 ces demandes s'exposent non seulement \u00e0 des sanctions r\u00e9glementaires, mais aussi au risque d'\u00eatre consid\u00e9r\u00e9s comme peu coop\u00e9ratifs par les autorit\u00e9s charg\u00e9es de l'application de la loi, ce qui peut avoir des r\u00e9percussions plus larges sur leurs relations avec les autorit\u00e9s de r\u00e9gulation.<\/p>\n\n\n\n

D\u00e9fis techniques li\u00e9s \u00e0 l'IoT LI<\/h2>\n\n\n\n

La mise en \u0153uvre de l'interception l\u00e9gale des communications IoT et M2M pose plusieurs d\u00e9fis techniques qui diff\u00e8rent consid\u00e9rablement de ceux li\u00e9s \u00e0 l'interception traditionnelle des communications vocales et de donn\u00e9es. Le premier r\u00e9side dans la diversit\u00e9 des protocoles de communication. Les appareils IoT communiquent \u00e0 l\u2019aide d\u2019un large \u00e9ventail de protocoles \u2014 MQTT, CoAP, LwM2M, HTTP et des protocoles propri\u00e9taires \u2014 sur diverses technologies r\u00e9seau, notamment LTE-M, NB-IoT, LoRaWAN, Sigfox et les r\u00e9seaux satellitaires. Chaque protocole et chaque technologie r\u00e9seau pr\u00e9sente des caract\u00e9ristiques diff\u00e9rentes qui influent sur la mani\u00e8re dont l\u2019interception peut \u00eatre effectu\u00e9e.<\/p>\n\n\n\n

The second challenge is the volume and pattern of communications. Unlike voice calls or web browsing sessions, IoT communications are typically short, infrequent, and low-bandwidth. A sensor may transmit a few bytes of data every hour. This pattern matters less for capture, because interception points copy every packet or non-IP message of the target, however small, but it means many sessions stay idle for long periods and each transmission is reported separately.<\/p>\n\n\n\n

The third challenge is target identification. IoT devices may be identified by IMSI, IMEI, IP address, or device-specific identifiers that do not correspond to traditional subscriber identities. Mapping these identifiers to a specific target \u2014 particularly when the device is owned by an organisation rather than an individual \u2014 can be complex. The administration function and the interception points must support the identifier types used for IoT devices (for example IMSI\/SUPI, IMEI\/PEI, external identifiers and IP addresses), and the operator must be able to map a device serial number to one of them before the task is provisioned.<\/p>\n\n\n\n

The fourth challenge relates to encryption and security. Many IoT protocols implement application-layer encryption, which means that the operator may be able to capture the encrypted traffic but not access the content. The DTLS and TLS implementations used by CoAP and MQTT, for example, may encrypt the application payload in a way that the operator cannot decrypt. This limitation must be communicated transparently to law enforcement when responding to interception requests. Operators must remove encryption they apply in the network or whose keys they help generate or exchange (in Germany, \u00a7 8(3) TK\u00dcV); application-layer encryption between device and customer platform that the operator holds no key for is delivered as captured.<\/p>\n\n\n\n

A fifth challenge is the sheer scale of IoT deployments. An operator may have millions of IoT devices on its network, and large device populations matter mainly for identifying the right device (for example mapping a device serial number to IMSI\/IMEI) and for making sure all IoT core functions are covered. The number of simultaneous intercepts remains driven by the number of orders.<\/p>\n\n\n\n

Consid\u00e9rations sp\u00e9cifiques aux r\u00e9seaux LPWAN<\/h2>\n\n\n\n

LPWAN technologies \u2014 including NB-IoT, LTE-M, LoRaWAN, and Sigfox \u2014 have specific characteristics that affect LI implementation. NB-IoT and LTE-M operate within the 3GPP ecosystem and are served by the cellular core network. 3GPP TS 33.127\/33.128 already cover their IoT-specific paths: data sent over the signalling plane (Data over NAS) and Non-IP Data Delivery via the SCEF (4G) or NEF (5G). Operators must make sure these functions, not just the user-plane gateways, have interception points.<\/p>\n\n\n\n

LoRaWAN and Sigfox operate outside the 3GPP ecosystem and use proprietary or open-standard network architectures. The application of LI to these technologies is less well-defined in terms of standards, and operators may need to develop custom interception solutions. The network architecture of LoRaWAN, for example, includes gateways, network servers, and application servers, and the network server sees device identifiers, timing and gateway (location) metadata, but the application payload is encrypted end-to-end with a key held by the application server. Interception at the network server gives readable content only where the operator also runs the application or join server.<\/p>\n\n\n\n

IRI et CC pour les communications IoT<\/h2>\n\n\n\n

Standard IRI covers what the network knows: identities (IMSI\/SUPI, IMEI\/PEI, external identifiers), sessions, location. Sensor readings travel as content (CC). Any additional metadata must come from the national handover specification, not from operator-specific extensions.<\/p>\n\n\n\n

CC for IoT communications is typically much smaller in volume than for voice or data sessions, but may be more diverse in format. The content of an IoT transmission might be a JSON payload, a binary sensor reading, a protocol buffer message, or a proprietary data format. CC is delivered as an unaltered copy of what was transmitted (for example IP packets or non-IP data), together with the IRI. Interpreting proprietary payload formats is the job of law enforcement’s analysis tools.<\/p>\n\n\n\n

Se pr\u00e9parer aux obligations li\u00e9es \u00e0 l'IoT LI<\/h2>\n\n\n\n

Les op\u00e9rateurs proposant des services IoT et M2M doivent prendre des mesures proactives pour se pr\u00e9parer aux obligations en mati\u00e8re de LI, m\u00eame lorsque les exigences r\u00e9glementaires ne sont pas encore pleinement d\u00e9finies. Tout d\u2019abord, \u00e9valuez le cadre r\u00e9glementaire sur chaque march\u00e9 o\u00f9 vous op\u00e9rez, en consultant un conseiller juridique et l\u2019autorit\u00e9 de r\u00e9gulation nationale comp\u00e9tente. Ensuite, \u00e9valuez vos capacit\u00e9s actuelles en mati\u00e8re de LI au regard des exigences sp\u00e9cifiques relatives \u00e0 l\u2019interception des donn\u00e9es IoT, en identifiant les lacunes en mati\u00e8re d\u2019identification des cibles, de capture du trafic, de g\u00e9n\u00e9ration d\u2019IRI et de transmission des CC.<\/p>\n\n\n\n

Troisi\u00e8mement, \u00e9laborez une feuille de route technique visant \u00e0 renforcer vos capacit\u00e9s en mati\u00e8re de LI afin de prendre en charge l'interception des donn\u00e9es de l'IoT. Cette feuille de route doit porter sur l'int\u00e9gration des \u00e9l\u00e9ments du r\u00e9seau IoT avec le LI fonction de m\u00e9diation<\/a>, the extension of target identification to support IoT device identifiers, and coverage of the IoT-specific data paths (Data over NAS, NIDD via SCEF\/NEF). Fourth, engage with your Solution LI<\/a> fournisseur afin de comprendre sa feuille de route concernant la prise en charge de l'IoT LI et d'influencer ses priorit\u00e9s de d\u00e9veloppement en fonction de vos besoins.<\/p>\n\n\n\n

Enfin, documentez votre approche de l'IoT Conformit\u00e9 LI<\/a>, including any limitations in your current capabilities and the steps you are taking to address them. This documentation shows the regulator why your service is exempt or how your interception capability is implemented. Where an obligation applies, it does not replace the capability: in Germany the facilities must be in place when the service starts (\u00a7 170(1) TKG).<\/p>\n\n\n\n

Conclusion<\/h2>\n\n\n\n

The growth of IoT and M2M communications is bringing more law enforcement requests to operators, because IoT data is increasingly relevant to investigations. While the technical challenges of IoT LI are significant \u2014 spanning protocol diversity, traffic patterns, target identification, encryption, and scale \u2014 they are not insurmountable. Operators that assess their regulatory exposure, evaluate their technical capabilities, and invest in IoT-capable LI solutions will be well positioned to meet their obligations and to maintain compliance as the IoT ecosystem continues to grow.<\/p>\n\n\n

L'intersection entre l'Internet des objets (IoT) et l'interception l\u00e9gale soul\u00e8ve \u00e9galement des questions plus larges concernant la port\u00e9e de la surveillance dans un monde de plus en plus connect\u00e9. \u00c0 mesure que les objets du quotidien sont connect\u00e9s et g\u00e9n\u00e8rent des flux de donn\u00e9es, la fronti\u00e8re entre l\u2019interception des communications et la collecte de donn\u00e9es au sens large devient de moins en moins nette. Les op\u00e9rateurs devraient collaborer de mani\u00e8re proactive avec les r\u00e9gulateurs et les organismes sectoriels afin de contribuer \u00e0 l\u2019\u00e9laboration du cadre \u00e9mergent r\u00e9gissant l\u2019interception l\u00e9gale dans le cadre de l\u2019IoT, en apportant leur expertise technique pratique pour garantir que les exigences qui en r\u00e9sulteront soient \u00e0 la fois efficaces pour les forces de l\u2019ordre et applicables par les op\u00e9rateurs.<\/p>\n\n\n\n

La port\u00e9e des obligations en mati\u00e8re d'interception l\u00e9gale dans le cadre de l'IoT varie selon les juridictions et les types de services. Les op\u00e9rateurs doivent recenser leurs obligations en mati\u00e8re d'interception l\u00e9gale dans le cadre de l'IoT d\u00e8s les premi\u00e8res \u00e9tapes de la planification de leur d\u00e9ploiement.<\/p>\n\n\n\n

Articles connexes<\/h2>\n\n\n\n

Pour en savoir plus sur des sujets connexes, consultez les articles suivants :<\/p>\n\n\n\n