Cellular IoT Security in 2026: Make No Assumptions

Security in cellular IoT systems is often misunderstood and occasionally neglected. A cellular connection can feel private, but that does not mean the device is automatically protected. Product teams may assume their devices will not have a public IP address, that the carrier is providing a firewall or VPN, or that SIM controls, NAT, stateful inspection, private APNs, eSIM profiles and other “features” are already in place. Some may be. Some may not be. And some may not be a good idea unless they are planned and tested as part of the full system.

When designing IP-based IoT systems, it is important to anticipate the worst-case situation and make no assumptions. IoT is fundamentally different from other IP-based communication systems. Do not assume that because you have always seen something done a specific way when dealing with data centers or cloud services, that the same methods are correct for a remote, metered, battery-powered or field-deployed device.

A common example is assuming that “somewhere at the carrier” NAT and a firewall are present between cellular devices and the public Internet. In that model, the device can initiate outgoing IP connections, but no one from the public Internet can open a direct connection to the device. That may be true for a specific deployment, but it should not be treated as a security control unless it is documented, verified and monitored. Product creators also need to consider that attackers may gain access inside the network boundary, compromise cloud credentials, abuse an API or exploit a weakness in the device itself.

Never Trust the Channel
Channel security can change over time as carriers update equipment, roaming partners change and new technologies are deployed. LTE, 5G, NB-IoT, LTE-M, satellite, Wi-Fi and other IoT network types all have different security properties and failure modes. Product creators cannot control the channel and should never trust any system outside their control. Over cellular, devices can still be taken offline, misconfigured, tracked through location data or exposed through weak backend controls if the system is not designed carefully.

The best approach for IoT data security is end-to-end authentication and encryption, applied based on the risk and value of the data. For some systems, TLS over TCP is the right choice because it is proven, well known and widely supported. However, TLS negotiation, headers and keep-alive messages add overhead. In cellular IoT, each byte can affect battery life, bandwidth and operating cost.

When deploying 10,000 units that are in service 24/7/365, even a few extra bytes per message can add up.
Some data may not need to be encrypted, but it still needs to be verified as coming from the correct source and protected from tampering or replay. Message signing, device identity, certificate management and application-layer authentication may be sufficient for some applications. Be careful, though: data that appears to have little value today may become valuable over time as analytics, AI systems and cross-device data aggregation improve.

If data needs to be encrypted, message-level encryption can be a strong option, especially for devices that send small, periodic messages. It can also allow lower-overhead transport methods, such as UDP, where appropriate. For systems sending larger amounts of data more often, the overhead of TCP/TLS may matter less. The right choice depends on the device, the network, the data, the risk and the business model.

Check Hardware Security
After you have secured the data path, tested the system and fixed the obvious issues, you still need to protect the hardware. You should assume that someone may gain physical access to your IoT device. Many devices are deployed in remote, isolated or public locations where they can be handled or manipulated for extended periods of time.

To make matters worse, cellular connectivity is not guaranteed. A missed report does not automatically mean a device was compromised, and a compromised device may still appear to be functioning normally.

The first step is to secure the programming and debug interfaces on shipped units. The production test system should disable JTAG or other programming interfaces after it verifies that the bootloader was programmed correctly. From that point on, the device should only accept updates through a controlled bootloader or secure update path.

That bootloader needs to work in a fail-safe way, so a loss of power never causes the device to fail in a way that it cannot recover from by itself. It also needs to enforce signed firmware images, and in many cases encrypted firmware images, so the device only accepts updates from a trusted source.

In 2026, this should be treated as a baseline expectation, not an optional extra. Secure boot, signed over-the-air updates, vulnerability handling and a defined support period are now part of how customers, regulators and partners evaluate connected products.

With these steps, you have protected the hardware from debugger inspection, helped prevent firmware extraction and reduced the risk of unauthorized firmware being installed. Next, consider the sources of data your device is gathering.

Could someone disable or spoof a sensor in the system? If so, how important is that and what can you do about it? How does the hardware handle power interruption? Does the application need to detect relocation, tampering or unexpected behavior? As you think through the application, other factors will come up. Take your time, write them down and consider having a third party review your security plan.

Secure Anything of Value
The data path is secure and the hardware is secure. Is that everything? Not quite. Here is where things get more subtle. Anything in the IoT system that someone is paying for has value. Even if the data or hardware does not seem valuable to a wide audience, it may be valuable to someone.

In a cellular system, the connectivity itself has value. What prevents someone from opening a device, stealing the SIM card and using it in another device? Today, that question also includes embedded SIMs, eSIM profiles, remote SIM provisioning and device credentials. Embedded SIMs are harder to remove than traditional SIM cards, but they do not eliminate fraud risk by themselves.

SIM theft can have serious consequences. In the best case, a SIM is used for unauthorized data consumption and creates a large cellular bill. In a more serious case, the connectivity could be used for suspicious activity that creates legal, compliance or reputational exposure for the company whose account owns the SIM.

To reduce this risk, make sure the SIM is locked to the cellular radio IMEI where supported. Ensure the cellular radio is locked to the SIM either at the radio level, in the application software or through carrier and device management controls. This helps prevent someone from using another network provider, spoofing the system or reverse engineering the product. This cannot typically be applied on certification test units, but the production test process should apply it to every shipped device.

Another way to reduce SIM fraud is by using APN locks and device credentials that only allow the SIM to work in an approved device and network configuration. Even with a soldered MFF2 embedded SIM or eSIM profile, this is still important. The more valuable the connectivity or the data, the more important it is to make sure identity and access controls are enforced across the device, SIM, network and cloud.

Simplify Your System
Of course, all of this is focused on the IoT device and its connection. If the control interface, mobile app, cloud dashboard, API or device management platform is compromised, then all bets are off. A system’s security is limited by its weakest link. Keep your system as simple as possible. Compartmentalize individual pieces so intrusion in one part does not compromise the entire system. Use least-privilege access, secure credential handling, logging and monitoring where practical.

Plan for the full lifecycle of the product, including onboarding, provisioning, firmware updates, vulnerability response, ownership transfer and end-of-life.

The best way to start securing any IoT system is to follow general cybersecurity best practices wherever practical, then add the cellular- and device-specific controls that your use case requires. Current guidance from organizations such as NIST and GSMA, along with programs like the U.S. Cyber Trust Mark and the EU Cyber Resilience Act, all point in the same direction: connected products need security built in from the start and maintained throughout the product lifecycle.

Beyond that, diving into the details will help minimize the risk of a security failure.

At F3, we help companies think through these decisions before they become expensive problems. A cellular IoT product is not just a device and a data plan. It is a complete system that needs the right hardware, firmware, connectivity, cloud architecture, provisioning process and security plan from the beginning.