With the introduction of the EN 18031 standard and the updated Radio Equipment Directive (RED), the regulatory landscape for connected devices in Europe is entering a new phase. From August 2025, cybersecurity compliance will no longer be optional—it will be a prerequisite for market access. While this marks a crucial first step toward a more secure and trustworthy IoT ecosystem, it also represents a regulatory shake-up that puts pressure on developers, system integrators, and device manufacturers to scrutinize their designs—and in some cases, even rethink their wireless technology choices.
Low-power wide-area (LPWA) technologies—such as NB-IoT, LTE-M, and LoRaWAN—have each carved out their niche in the IoT space. From a wireless perspective, we’ve learned that they are similar in many respects. And in this market, allegiance to a technology often resembles a form of faith. The wireless saviour. But as cybersecurity requirements tighten, energy efficiency and cost-effectiveness are no longer enough. The question now is: Which of these technologies is truly ready to deliver secure, standards-compliant connectivity—at scale?
My answer may surprise you—or perhaps not. It may irritate some of you. If so, I encourage you to study the EN 18031 standard and reassess your stance without the wireless religion filter.
Understanding the regulatory shift
EN 18031 introduces a significant tightening of cybersecurity requirements for wireless-connected products in the EU, and therefore IoT products are affected.
The regulation mandates that devices must resist cyber threats and unauthorized access and that they must be securely configurable, updatable, and monitorable throughout their operational life. Combined with the RED’s expanded scope—which now covers software updates, data protection, and user privacy—the impact on wireless IoT design is profound.
It’s explicitly stated that devices must be secure throughout their expected lifespan. But how can manufacturers guarantee that a device will remain secure 7–10 years from now? That question lies at the heart of the new compliance challenge. One thing is for sure: if we see the dawn of quantum computing, the landscape may change very quickly, and what was once considered safe may become vulnerable very fast.
For developers of battery-operated, long-range devices, these new obligations pose a difficult trade-off. Power budgets are tight, yet secure communication now demands capabilities like encrypted firmware updates, authenticated network access, and anomaly detection. In this context, the wireless protocol is no longer just a transport layer—it becomes a strategic enabler or a compliance bottleneck.
And here’s where a crucial technical detail comes in: wireless protocols that rely solely on shared secrets (for example, a username/password or a single symmetric key) offer limited security compared to those that use X.509 certificates, mutual authentication, and public key infrastructure (PKI). These differences are no longer just theoretical—they now determine whether a product can meet the EN 18031 bar. And let us be honest: it is one thing to meet the certifications, but security should always be at the forefront, legislation or not.
LoRaWAN: Open standards, limited control
LoRaWAN has gained traction for its open architecture, long battery life, and affordability. But its decentralized design introduces serious challenges under EN 18031. While security features like AES-128 encryption, join-server separation, and session key derivation exist in the specification, their effectiveness is heavily dependent on deployment architecture.
In public networks especially, device makers often lack control over key management, data routing, or backend exposure—elements that are now front and center under RED and EN 18031. The protocol allows optionality, and therein lies the risk: optional security is not acceptable under mandatory regulation.
Even more problematic is firmware lifecycle protection. While some vendors have bolted on proprietary firmware update mechanisms, secure, standardized over-the-air firmware updates are not part of the LoRaWAN specification. This creates inconsistency, and with it, certification uncertainty. Yes, the EN 18031 standard does not explicitly mandate OTA firmware updates—but it does require manufacturers to ensure secure patching mechanisms are in place.
And if OTA is not technically feasible? Then the burden falls on the manufacturer to deliver firmware updates another way. Imagine needing to recall and physically reflash 10,000 water meters. That’s not just costly—it’s operationally unmanageable.
NB-IoT: Deep coverage, but fragmented security
NB-IoT, as a 3GPP-standardized cellular technology, offers a stronger baseline security posture than LoRaWAN. SIM-based authentication, mutual device–network verification, integrity protection, and encryption (typically 128-bit AES) are built into the cellular stack. Further isolation can be achieved using a private APN, ensuring that device traffic never traverses the public internet—an attractive option for critical applications.
However, NB-IoT was originally architected for static, low-throughput sensor applications—and the legacy of that design remains evident. The technology has limited support for mobility, TCP/IP connectivity, or low-latency transmission. These constraints make secure provisioning, credential updates, or rapid reconfiguration difficult, particularly in large-scale or dynamic deployments.
A more pressing concern lies in the fragmentation of operator implementations. While the 3GPP specification includes robust security features such as EPS encryption (LTE control and user plane encryption), not all operators enable them by default. Moreover, NB-IoT roaming support is inconsistent across networks and countries, and when it is available, it often omits full security parity with the home network. This variability creates a compliance risk: the security of an NB-IoT device is not solely defined by its hardware or firmware, but also by the infrastructure and policies of the mobile network operator—a variable that device manufacturers can neither control nor easily certify against.
Then there’s the issue of secure firmware updates. FOTA is technically possible on NB-IoT, and it is supported by some modules and operators. However, the limited bandwidth, narrow uplink/downlink profiles, and lack of TCP/IP transport in many NB-IoT stacks make certificate-based mutual authentication and large-scale updates cumbersome, if not impractical.
It is still better positioned than LoRaWAN in this respect—but it’s far from ideal when judged against the demands of EN 18031 and RED, which emphasize lifecycle security and updateability.
LTE-M: Built-in readiness for compliance
Among low-power wide-area technologies, LTE-M stands apart. It inherits the full security stack of LTE—including mutual authentication via SIM, 3GPP-standardized encryption, integrity protection, and network-based anomaly detection. But crucially, LTE-M also supports mobility, voice fallback, and TCP/IP transport—capabilities that are vital for secure provisioning, configuration, and firmware updates across the entire device lifecycle.
From a lifecycle security standpoint, LTE-M is the only LPWAN technology that can reliably support secure, certificate-based firmware-over-the-air (FOTA) updates within a standards-aligned, operator-managed environment. This is a direct response to core expectations in EN 18031 and the revised Radio Equipment Directive, where updateability, authenticated communication, and resilience to future threats are not optional—they’re foundational.
Another key differentiator is consistency. LTE-M is integrated into existing LTE infrastructure, meaning that security features are enabled by default across most commercial networks. Roaming scenarios retain encryption and session integrity, which simplifies compliance documentation and removes the guesswork tied to operator-specific limitations seen in NB-IoT.
For IoT solution providers navigating this new regulatory era, LTE-M offers something rare: a balanced trade-off between energy efficiency and built-in regulatory alignment. It avoids the need for bespoke security workarounds, making it the most forward-compatible choice for long-term, secure, and scalable IoT connectivity in Europe’s post-2025 compliance environment.
Turning regulation into implementation
Complying with EN 18031 and the updated Radio Equipment Directive is not simply about ticking checkboxes—it demands tangible, field-proven capabilities. Devices must resist cyberattacks, prevent unauthorized changes, and be securely updated over time. Achieving this in battery-powered IoT deployments—at scale—is no trivial task. And this is precisely where LTE-M demonstrates its maturity: not just as a communication protocol, but as a strategic enabler of secure lifecycle management.
Secure provisioning and onboarding
With native SIM-based authentication, LTE-M devices benefit from a secure, operator-managed identity from day one. This removes the need for pre-shared keys or insecure provisioning workflows and establishes a hardware-based root of trust—a foundation.
Encrypted firmware updates over the air
Unlike LoRaWAN, where firmware updates are typically proprietary add-ons, LTE-M supports standardized, IP-based update mechanisms using protocols like LwM2M or HTTPS. This enables manufacturers to push authenticated, encrypted firmware updates using widely accepted frameworks—while maintaining detailed logs for audit trails. This meets both RED and EN 18031 requirements for secure and traceable updates over time.
Continuous monitoring and incident response
EN 18031 calls for the ability to detect anomalies and respond to threats. LTE-M, with its support for IP-based telemetry, allows real-time reporting of device logs, system health, or intrusion attempts to centralized platforms. Its support for QoS, TCP/IP, and lower latency enables active diagnostics, fallback behaviors, and even remote containment—features that are impractical over LoRaWAN and inconsistently supported in NB-IoT deployments.
Roaming and lifecycle traceability
Compliance doesn’t end at the border. LTE-M’s integration into global LTE networks and its compatibility with roaming frameworks ensure a predictable and consistent security posture, regardless of deployment geography.
In short, LTE-M isn’t just more secure. It’s more manageable, more auditable, and more future-proof. Its architecture aligns naturally with the European Commission’s regulatory trajectory and empowers manufacturers to focus on functionality—without compromising on compliance.
Yet for many companies, the final decision may come down to a deceptively simple question: Are we building for the past—or for the world that’s coming next?
Choosing what lasts: The wireless decision that future-proofs your compliance
As the European IoT landscape matures, the pressure on manufacturers, solution providers, and property owners grows. The choice of wireless technology is no longer just about energy efficiency, signal range, or price per module—it’s about enabling trust, accountability, and upgradability in a connected world that now demands regulatory proof.
LoRaWAN may still be attractive for simple, local deployments. NB-IoT might appear cost-efficient, particularly where it’s bundled by mobile operators in narrow public utility use cases. But neither offers the same level of cybersecurity readiness, lifecycle robustness, or international operability as LTE-M.
Importantly, EN 18031 is not the end—it’s the beginning of a broader push for digital product regulation across Europe, including the Cyber Resilience Act and the Digital Product Passport. LTE-M is already aligned with these directions, offering native support for encrypted traffic, secure boot, remote management, and roaming-aware security policies. Choosing LTE-M now means aligning not just with today’s standards, but with the regulatory trajectory of the next decade.
And while the industry races to retrofit security into legacy protocols, LTE-M stands apart as a protocol born into the age of compliance.
So the question is no longer whether LTE-M is technically superior—but whether your connected product strategy can afford anything less.