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 — particularly those providing Low Power Wide Area Network (LPWAN) connectivity and M2M services — this growth brings not only commercial opportunity but also expanding regulatory obligations, including lawful interception.
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.
IoTにおける合法的な通信傍受が重要な理由
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.
In Germany, § 170 TKG and the TKÜV (Telekommunikations-Überwachungsverordnung) require operators of networks used for publicly available telecommunications services to provide interception capability, and M2M transmission services count as telecommunications services (§ 3 No. 61(c) TKG). The TKÜV exempts some systems from having to install interception facilities, for example systems used only to transmit measurement data (§ 3(2) No. 4 TKÜV) or systems with no more than 10,000 users (§ 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.
Even an operator that is exempt from installing interception facilities must cooperate with an individual order (in Germany, § 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.
法執行機関にとってIoTデータが重要な理由
IoTデバイスは、犯罪捜査にとって極めて重要なデータを生み出します。コネクテッドカーは、位置情報、運転パターン、通信ログを生成します。スマートホームデバイスは、環境データ、利用パターンを記録し、場合によっては音声や映像も記録します。 ウェアラブル健康機器は、生体データや動作パターンを収集します。産業用IoTセンサーは、操業状況、サプライチェーンの動き、環境条件を明らかにすることができます。自動販売機や公共料金メーターといった単純なM2Mデバイスでさえ、特定の捜査において関連性のある位置情報や利用データを生成します。.
As 法執行機関 become more aware of the investigative potential of IoT data, they are increasingly likely to request interception or data disclosure from IoT operators. Operators that are unable to respond to these requests face not only regulatory consequences but also the risk of being seen as uncooperative by law enforcement authorities, which can have broader implications for the operator’s relationship with regulators.
IoT LIの技術的課題
IoTおよびM2M通信における合法的な傍受の実施には、従来の音声・データ傍受とは大きく異なる、いくつかの技術的課題があります。第一に、通信プロトコルの多様性が挙げられます。 IoTデバイスは、MQTT、CoAP、LwM2M、HTTP、および独自プロトコルなど、幅広いプロトコルを用いて、LTE-M、NB-IoT、LoRaWAN、Sigfox、衛星通信といった様々なネットワーク技術を通じて通信を行います。各プロトコルおよびネットワーク技術にはそれぞれ異なる特性があり、それが傍受の実施方法に影響を及ぼします。.
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.
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 — particularly when the device is owned by an organisation rather than an individual — 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.
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, § 8(3) TKÜV); application-layer encryption between device and customer platform that the operator holds no key for is delivered as captured.
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.
LPWAN特有の考慮事項
LPWAN technologies — including NB-IoT, LTE-M, LoRaWAN, and Sigfox — 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.
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.
IoT通信におけるIRIとCC
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.
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.
IoTに関する法的義務への備え
IoTおよびM2Mサービスを提供する事業者は、規制要件がまだ完全に定義されていない場合でも、LI義務に備えて先手を打つべきです。まず、法律顧問や各国の関連規制当局と協議し、事業を展開する各市場における規制状況を評価してください。 次に、IoT通信の傍受に関する具体的な要件に照らして、自社の現在のLI対応能力を評価し、対象の特定、トラフィックのキャプチャ、IRIの生成、およびCCの配信における不足点を特定してください。.
Third, develop a technical roadmap for enhancing your LI capabilities to support IoT interception. This roadmap should address the integration of IoT network elements with the LI 調停機能, 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 LIソリューション vendor to understand their roadmap for IoT LI support and to influence their development priorities based on your requirements.
Finally, document your approach to IoT LIコンプライアンス, 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 (§ 170(1) TKG).
結論
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 — spanning protocol diversity, traffic patterns, target identification, encryption, and scale — 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.
IoTと合法的な通信傍受の交差は、ますます相互接続が進む世界における監視の範囲について、より広範な疑問も提起している。 日用品がネットワークに接続され、データストリームを生成するようになるにつれ、通信傍受とより広範なデータ収集との境界は曖昧になってきています。事業者は、規制当局や業界団体と積極的に連携し、IoTにおける合法的傍受（LI）の新たな枠組みの形成に貢献するとともに、実用的な技術的専門知識を提供することで、その結果として策定される要件が法執行機関にとって効果的であると同時に、事業者にとっても実装可能なものとなるよう努めるべきです。.
IoTにおける合法的な傍受義務の範囲は、管轄区域やサービスの種類によって異なります。事業者は、導入計画の初期段階で、自社のIoTに関する合法的な傍受要件を整理しておく必要があります。.
関連記事
関連トピックについては、以下の記事を参照されたい：
- 5G SAにおけるネットワークスライシング：LIターゲティングをいかに複雑にするか（そしていかに簡素化できるか）
- eSIMと合法的傍受：RSPアーキテクチャがコンプライアンスにもたらすもの
- MVNOとMNO：合法的傍受の法的責任はどちらにあるのか？
外部リソース
以下の外部リソースは、さらなる背景と公式文書を提供している：
