{"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-intercecao-legal-lpwan-m2m","status":"publish","type":"post","link":"https:\/\/ic-services.io\/pt\/resources\/blog\/iot-lawful-interception-lpwan-m2m\/","title":{"rendered":"IoT e interce\u00e7\u00e3o legal: A crescente obriga\u00e7\u00e3o dos operadores de LPWAN e 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

Por que raz\u00e3o a interce\u00e7\u00e3o legal na Internet das Coisas (IoT) \u00e9 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

Por que raz\u00e3o os dados da IoT s\u00e3o importantes para as for\u00e7as policiais<\/h2>\n\n\n\n

Os dispositivos IoT geram dados que podem ser extremamente relevantes para investiga\u00e7\u00f5es criminais. Os ve\u00edculos conectados geram dados de localiza\u00e7\u00e3o, padr\u00f5es de condu\u00e7\u00e3o e registos de comunica\u00e7\u00e3o. Os dispositivos dom\u00e9sticos inteligentes registam dados ambientais, padr\u00f5es de utiliza\u00e7\u00e3o e, em alguns casos, \u00e1udio ou v\u00eddeo. Os dispositivos de sa\u00fade vest\u00edveis captam dados biom\u00e9tricos e padr\u00f5es de movimento. Os sensores industriais da IoT podem revelar atividades operacionais, movimentos na cadeia de abastecimento e condi\u00e7\u00f5es ambientais. Mesmo dispositivos M2M simples, como m\u00e1quinas de venda autom\u00e1tica ou contadores de servi\u00e7os p\u00fablicos, geram dados de localiza\u00e7\u00e3o e utiliza\u00e7\u00e3o que podem ser relevantes em determinadas investiga\u00e7\u00f5es.<\/p>\n\n\n\n

Como organismos respons\u00e1veis pela aplica\u00e7\u00e3o da lei<\/a> \u00c0 medida que se tornam mais conscientes do potencial investigativo dos dados da IoT, \u00e9 cada vez mais prov\u00e1vel que solicitem a interce\u00e7\u00e3o ou a divulga\u00e7\u00e3o de dados aos operadores de IoT. Os operadores que n\u00e3o consigam responder a estes pedidos enfrentam n\u00e3o s\u00f3 consequ\u00eancias regulamentares, mas tamb\u00e9m o risco de serem considerados pouco cooperantes pelas autoridades respons\u00e1veis pela aplica\u00e7\u00e3o da lei, o que pode ter implica\u00e7\u00f5es mais amplas na rela\u00e7\u00e3o do operador com as entidades reguladoras.<\/p>\n\n\n\n

Desafios t\u00e9cnicos da IoT LI<\/h2>\n\n\n\n

A implementa\u00e7\u00e3o da interce\u00e7\u00e3o legal das comunica\u00e7\u00f5es de IoT e M2M apresenta v\u00e1rios desafios t\u00e9cnicos que diferem significativamente da interce\u00e7\u00e3o tradicional de voz e dados. O primeiro \u00e9 a diversidade de protocolos de comunica\u00e7\u00e3o. Os dispositivos IoT comunicam utilizando uma vasta gama de protocolos \u2014 MQTT, CoAP, LwM2M, HTTP e protocolos propriet\u00e1rios \u2014 atrav\u00e9s de v\u00e1rias tecnologias de rede, incluindo LTE-M, NB-IoT, LoRaWAN, Sigfox e sat\u00e9lite. Cada protocolo e tecnologia de rede possui caracter\u00edsticas diferentes que afetam a forma como a interce\u00e7\u00e3o pode ser realizada.<\/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

Considera\u00e7\u00f5es espec\u00edficas sobre 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 e CC para comunica\u00e7\u00f5es na Internet das Coisas (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

Prepara\u00e7\u00e3o para as obriga\u00e7\u00f5es relacionadas com a IoT LI<\/h2>\n\n\n\n

Os operadores que prestam servi\u00e7os de IoT e M2M devem tomar medidas proativas para se prepararem para as obriga\u00e7\u00f5es em mat\u00e9ria de LI, mesmo nos casos em que os requisitos regulamentares ainda n\u00e3o estejam totalmente definidos. Em primeiro lugar, avalie a situa\u00e7\u00e3o regulamentar em cada mercado em que opera, consultando um advogado e a autoridade reguladora nacional competente. Em segundo lugar, avalie as suas capacidades atuais em mat\u00e9ria de LI face aos requisitos espec\u00edficos da interce\u00e7\u00e3o de dados da IoT, identificando lacunas na identifica\u00e7\u00e3o de alvos, na captura de tr\u00e1fego, na gera\u00e7\u00e3o de IRI e na entrega de CC.<\/p>\n\n\n\n

Em terceiro lugar, elabore um plano de a\u00e7\u00e3o t\u00e9cnico para melhorar as suas capacidades de LI, de modo a apoiar a interce\u00e7\u00e3o da IoT. Este plano de a\u00e7\u00e3o deve abordar a integra\u00e7\u00e3o dos elementos da rede da IoT com a LI fun\u00e7\u00e3o de media\u00e7\u00e3o<\/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 Solu\u00e7\u00e3o LI<\/a> fornecedor, para compreender o seu plano de desenvolvimento para o suporte \u00e0 IoT LI e para influenciar as suas prioridades de desenvolvimento com base nos seus requisitos.<\/p>\n\n\n\n

Por fim, documente a sua abordagem \u00e0 IoT Conformidade com a 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

Conclus\u00e3o<\/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

A interse\u00e7\u00e3o entre a IoT e a interce\u00e7\u00e3o legal levanta tamb\u00e9m quest\u00f5es mais amplas sobre o \u00e2mbito da vigil\u00e2ncia num mundo cada vez mais conectado. \u00c0 medida que os objetos do quotidiano se tornam interligados e geram fluxos de dados, a fronteira entre a interce\u00e7\u00e3o de comunica\u00e7\u00f5es e a recolha de dados em geral torna-se menos n\u00edtida. Os operadores devem colaborar de forma proativa com as entidades reguladoras e os organismos do setor para ajudar a definir o quadro emergente para a interce\u00e7\u00e3o legal na IoT, contribuindo com conhecimentos t\u00e9cnicos pr\u00e1ticos para garantir que os requisitos resultantes sejam eficazes para as autoridades respons\u00e1veis pela aplica\u00e7\u00e3o da lei e exequ\u00edveis pelos operadores.<\/p>\n\n\n\n

O \u00e2mbito das obriga\u00e7\u00f5es relativas \u00e0 interce\u00e7\u00e3o legal na IoT varia consoante a jurisdi\u00e7\u00e3o e o tipo de servi\u00e7o. As operadoras devem identificar os seus requisitos em mat\u00e9ria de interce\u00e7\u00e3o legal na IoT numa fase inicial do planeamento da sua implanta\u00e7\u00e3o.<\/p>\n\n\n\n

Artigos relacionados<\/h2>\n\n\n\n

Para mais informa\u00e7\u00f5es sobre temas relacionados, consulte estes artigos:<\/p>\n\n\n\n