When DTLS makes sense. Know before you deploy

IoT technology is becoming essential across industries, from smart homes to city utilities. Metering infrastructure in particular relies on LPWAN protocols like NB-IoT and LoRa for long-range, low-power wireless communication. But the more sensitive the data, the more important security becomes. Lets explore when DTLS (Datagram Transport Layer Security) makes sense for NB-IoT communication and when it doesn't.

Key takeaways

• Metering data can reveal patterns of personal or business activity, even when it appears relatively harmless. Unencrypted traffic can be intercepted, while inadequate authentication and integrity protection can allow messages to be modified or spoofed.
• DTLS (Datagram Transport Layer Security) provides TLS-based security for datagram communication, typically over UDP. It protects data confidentiality and integrity and supports peer authentication, depending on the authentication method configured.
• The trade-offs include handshake overhead, additional energy consumption, memory requirements on constrained devices and more complex key provisioning and management. The actual impact depends on the implementation and communication pattern.
• A private APN with UDP isolates traffic within the mobile operator’s network but does not encrypt the data itself. MQTT over TLS provides an established approach for secure application-level communication and cloud integration, but uses a different protocol stack and has its own communication and resource overhead.
• DTLS can be a suitable option where public NB-IoT networks carry sensitive data and secure datagram communication is required without adopting MQTT. Its additional complexity may be harder to justify for devices with severe power or memory constraints, depending on the threat model and available alternatives.
• The right security approach depends on data sensitivity, network exposure, authentication requirements, available device resources and key management. ACRIOS NB-IoT converters can support different secure communication approaches, including DTLS, MQTT over TLS and private APN configurations, subject to the capabilities of the specific device and implementation.

‍

Why secure communication matters

"It’s just water or electricity data, who cares?" you might think. But these seemingly trivial measurements can reveal patterns about personal or business activity: when people are home, what kind of operations are running, or even if there’s been a service disruption. And because many IoT devices communicate over public networks, unencrypted traffic can be intercepted or spoofed by bad actors.

Security isn’t just about protecting your own data. Poorly secured devices can become attack vectors or leak third-party information. In some cases, compromised data can be exploited for market manipulation, industrial sabotage, or targeted attacks.

Security is no longer optional. The EU Radio Equipment Directive (RED) will soon require mandatory cybersecurity features for wireless devices. And the Cyber Resilience Act (CRA), expected to take full effect by December 2027, will bring stricter standards for IoT security and vulnerability management. Encryption will be a key part of compliance.

DTLS: What it is and how it works

DTLS is essentially TLS adapted for UDP. It ensures confidentiality, authenticity, and integrity of data over connectionless protocols. Compared to transport layer VPNs or application-level encryption, DTLS offers:

• Encrypted communication over public NB-IoT networks
• Lower data overhead compared to MQTT with TLS
• Support for identity verification and protection against spoofing

But there are trade-offs:

• Longer handshake times and higher energy consumption
• Greater memory requirements on constrained devices
• More complex key provisioning and management

What are the most common alternatives to DTLS?

• Private APN with UDP. The most basic option. By isolating communication within a mobile operator’s private network, exposure to the public internet is reduced. However, it doesn’t encrypt the data itself.
• MQTT over TLS. Good for cloud integration. TLS ensures end-to-end encryption, but requires more bandwidth and battery power than DTLS. MQTT is also easier to implement and widely supported.

When does DTLS make sense?

DTLS is not a one-size-fits-all solution. It shines in use cases where:

• Public NB-IoT networks are used for transmitting metering data
• Data is privacy-sensitive (e.g., water/gas usage from households)
• Compliance with upcoming EU or national cybersecurity regulations is required
• End-to-end encryption is needed without switching to MQTT

It may not be worth the complexity for:

• Devices with severe power or memory constraints
• Private network deployments with limited exposure
• Use cases where application-level encryption or simpler TLS alternatives suffice

Our recommendation

Start by asking:

• Do I need data confidentiality and identity verification?
• Is my network environment public or private?
• Can my device handle the memory and energy requirements?

We at ACRIOS offer DTLS support in our NB-IoT-enabled converters, as well as MQTT/TLS and private APN communication. Our goal is to help you strike the right balance between security, efficiency, and integration.

Glossary of terms used

• CRA (Cyber Resilience Act): the EU regulation establishing cybersecurity requirements for products with digital elements and related obligations throughout their lifecycle, including vulnerability handling and security updates
• DDoS (Distributed Denial of Service): an attack that overwhelms a system or network with traffic from many sources to make it unavailable
• DTLS (Datagram Transport Layer Security): a protocol that secures data sent over datagram-based connections, providing encryption and integrity protection
• Handshake: the initial exchange between two parties in which they negotiate security parameters and establish the keys and authentication needed to protect subsequent communication
• Key provisioning: securely loading and managing the cryptographic keys a device needs for authentication and encryption
• LPWAN (Low-Power Wide-Area Network): a category of wireless networks designed for long-range communication with low power consumption, such as LoRaWAN and NB-IoT
• MQTT: a lightweight messaging protocol commonly used to send data from IoT devices to servers
• NB-IoT (Narrowband IoT): a cellular low-power technology running in mobile operators’ licensed networks, suited to devices that send small amounts of data
• Private APN (Access Point Name): a dedicated mobile network access point that routes a device’s traffic through a private network provided by the operator rather than through the public internet
• RED (Radio Equipment Directive): the EU directive setting requirements for radio equipment placed on the EU market, including safety, electromagnetic compatibility, efficient use of the radio spectrum and, where applicable, additional requirements such as cybersecurity
• RED DA (RED Delegated Act): the delegated regulation that introduced additional cybersecurity requirements under the Radio Equipment Directive for certain categories of radio equipment, applicable from 1 August 2025 and repealed with effect from 11 December 2027
• Spoofing: sending messages or data that falsely appear to come from a trusted source
• TLS (Transport Layer Security): a protocol that secures communication over connection-oriented transports such as TCP, providing encryption, integrity protection and authentication
• UDP (User Datagram Protocol): a connectionless transport protocol that sends data as individual datagrams without guaranteeing delivery or order