The prevailing model for IoT security treats the connected device as the security perimeter. Firmware is hardened. Application-layer encryption is applied. Device certificates are issued. Endpoint detection runs on the backend platform. The connectivity layer — the SIM, the network path, the operator infrastructure — is treated as infrastructure that devices use, not as a security domain to be actively managed.
This is the wrong model. The connectivity layer has a security surface that device-level controls cannot address. SIM theft, network-based device impersonation, traffic interception, and command-and-control communication to compromised devices are all attack vectors that operate at the connectivity layer, not the application layer. Addressing them requires security controls enforced at the network core, not patched in at the device.
This article covers the specific security risks that connectivity-layer controls address, what those controls are, and why the architecture of how they are enforced matters as much as whether they are available at all.
The security risks that device-level controls cannot address
SIM theft and device impersonation
A SIM card is a physical object that can be removed from a deployed device. In field deployments across payment terminals, vehicle fleets, industrial equipment, and safety devices, this is not a theoretical risk — SIM theft is a documented fraud vector in several high-value IoT verticals. A SIM removed from one device and inserted into another can use that SIM’s identity and data allocation on the network. Device-level security controls do not travel with the SIM: they remain on the original device, which is now without connectivity, while the fraudulent device operates under a legitimate SIM identity.
IMEI Lock is the connectivity-layer control that addresses this. It binds a SIM to a specific device IMEI, so that the SIM can only authenticate and connect to the network when it is installed in the device it was registered to. A stolen SIM inserted into any other device cannot connect. This control is enforced at the core network — not by the device, not by the application, but by the operator’s authentication infrastructure — which means it cannot be bypassed by the attacker.
Unauthorised network access and lateral movement
An IoT device with access to the public internet has a network path that can be used in both directions. A compromised device that can communicate with arbitrary external endpoints can be used to exfiltrate data, receive commands from a malicious server, or participate in a botnet. Device-level controls that rely on the firmware not being compromised cannot protect against a scenario where the firmware has already been compromised.
Data traffic filtering at the connectivity layer addresses this by whitelisting the specific IP addresses and URLs that each device is permitted to communicate with. A device can only send data to its authorised platform backend, not to arbitrary external destinations. This control is enforced at the network core, which means a compromised device firmware that attempts to communicate with a command-and-control server will find its traffic blocked regardless of what the firmware instructs it to do.
Private APN extends this further by isolating device traffic from the public internet entirely. Traffic routes through a dedicated private network gateway to the organisation’s own infrastructure, with non-routable private IP addressing that removes the public internet attack surface altogether.
Traffic interception and data exposure
Application-layer encryption — TLS, HTTPS, MQTTS — addresses interception within the application data flow. It does not address network-level interception of metadata: which devices are communicating, when, how frequently, and with what payload size. For deployments where communication patterns are operationally sensitive — patient monitoring data, payment transaction flows, infrastructure command sequences — metadata exposure may create risks that application-layer encryption alone does not mitigate.
VPN support at the connectivity layer (IPSec, GRE) provides end-to-end encrypted tunnels from the device to the organisation’s infrastructure, encrypting both payload and metadata for the full network path. This complements application-layer encryption rather than replacing it, providing defence in depth across the full data path.
Device identity fraud and command injection
IoT devices that communicate with cloud backends need to authenticate their identity. Application-level certificates stored in device firmware provide one mechanism, but firmware-based credentials can be extracted if the firmware is compromised. A device that is stolen, cloned, or reflashed with modified firmware may be able to impersonate a legitimate device at the application layer.
IoT SAFE addresses this at the hardware level. It is a GSMA standard that uses the SIM as a Root of Trust for device authentication. Cryptographic keys are stored in the SIM’s tamper-resistant secure element — which cannot be extracted through firmware compromise or physical probing of the device PCB. Authentication to cloud backends and IoT platforms using IoT SAFE keys is hardware-backed, which means the authentication cannot be replicated without the physical SIM.
Why where these controls are enforced matters
The same security feature implemented at different layers provides different security guarantees. IMEI Lock enforced at the operator’s core network cannot be bypassed by an attacker who controls the device firmware. IMEI Lock implemented as a device-side check can potentially be bypassed by reflashing the device with modified firmware. The enforcement point determines the adversarial model the control is effective against.
This is why the distinction between a connectivity provider that enforces security controls natively at their own network core and one that implements them through a host operator’s systems matters for security architecture. A provider implementing security controls through a third-party operator’s API has a dependency and a potential delay in policy enforcement. A provider enforcing controls at their own core network applies them immediately and consistently, without the latency of a third-party system boundary.
The same principle applies to the connectivity management platform. Security configurations that can only be applied through a GUI — rather than via API — cannot be integrated into automated security policy management workflows. A fleet of thousands of devices that needs security policy updates applied consistently and immediately requires API-driven policy management, not manual portal operations.
The controls OV provides as standard
OV builds security controls into the connectivity layer as standard capabilities, not optional additions. The full set:
- IoT SAFE (Root of Trust): GSMA-standard secure element providing hardware-backed device authentication. Cryptographic keys stored in the SIM’s tamper-resistant environment. Enables trusted device-to-cloud communications without device firmware dependency.
- IMEI Lock: Binds SIM to specific device IMEI. Enforced at OV’s own network core. Stolen SIMs cannot connect from any other device. Configured per SIM or per device group via OV ONE API.
- Private APN: Isolated network path for device traffic. Non-routable private IP addressing. No public internet exposure. Custom routing to customer infrastructure via encrypted tunnels.
- Data traffic filtering: Whitelist of approved IP addresses and URLs enforced at network core. Devices cannot communicate with unapproved endpoints regardless of firmware state. No device-side configuration required.
- Geofencing: Virtual geographic boundaries with real-time alerts via webhook, email, or SMS when devices move outside authorised areas. Detects physical asset theft and unauthorised device movement.
- VPN support: IPSec and GRE tunnels for end-to-end encryption from device to infrastructure. Protects payload and metadata across the full network path.
- SMS filtering and voice barring: Controls inbound and outbound SMS endpoints to prevent phishing and smishing. Voice barring prevents premium-rate fraud on devices that do not require voice capability.
- Centralised management via OV ONE: All security controls configurable via REST API and platform interface. Bulk policy application across up to 1,000 devices per operation. 31 days of security event history. Real-time alerts and SIEM integration via webhook.
Thinking about IoT security as a stack
Device-level security and connectivity-layer security are not alternatives — they address different attack surfaces. A mature IoT security architecture applies controls at both layers and treats the connectivity layer as an active security domain rather than passive infrastructure.
The connectivity-layer controls described above are most effective when they are configured from the point of initial device provisioning rather than retrofitted after a security incident. IMEI Lock applied at activation means every device in the fleet has SIM theft protection from day one. Data traffic filtering configured before deployment means compromised devices cannot establish command-and-control connections regardless of when the compromise occurs. IoT SAFE provisioned at manufacture means device authentication is hardware-backed from first connection.
The operational model for connectivity security is the same as for application security: security as a continuous posture, not a one-time configuration. OV ONE’s real-time security event monitoring and 31-day history provide the visibility needed to treat connectivity security operationally rather than architecturally — identifying unusual communication patterns, policy violations, and device behaviour anomalies as they occur rather than during a post-incident forensic review.
Reviewing your IoT security architecture?
The IoT SIM Connectivity Buyer Guide 2026 includes a connectivity security evaluation framework and the questions to ask any provider about how their security controls are enforced.
Download the IoT SIM Connectivity Buyer Guide 2026
Frequently asked questions
Is IoT SAFE the same as a device certificate?
IoT SAFE and device certificates address the same problem — device authentication — but at different hardware layers with different security properties. A device certificate stored in firmware can potentially be extracted if the firmware is compromised or if the device is physically probed. IoT SAFE stores cryptographic keys in the SIM’s tamper-resistant secure element, which cannot be extracted through firmware analysis or standard physical probing. IoT SAFE provides hardware-backed authentication that remains secure even if the device firmware is compromised, which is why it is described as a Root of Trust rather than simply an authentication credential.
Can data traffic filtering break legitimate device functionality?
Data traffic filtering only blocks communication with endpoints that are not on the approved whitelist. If the whitelist is correctly configured to include all endpoints the device legitimately communicates with, no legitimate functionality is affected. The configuration process requires identifying all legitimate communication endpoints before applying filtering — which is also a useful security audit step, since it makes explicit exactly what each device type should be communicating with. The filtering is enforced at the network core and can be updated via the OV ONE API without device firmware changes if new endpoints need to be added.
Does Private APN affect how devices connect to cloud IoT backends?
Private APN provides an isolated network path for device traffic but does not prevent devices from connecting to cloud IoT backends such as AWS IoT or Azure IoT Hub. The routing from the private APN to the customer’s cloud infrastructure is configured through a secure tunnel or dedicated gateway connection, so devices connect to the authorised cloud backend through the isolated path rather than through the public internet. This is the architecture used for PCI DSS-compliant payment connectivity and for regulated industrial and healthcare IoT deployments where data routing through the public internet creates compliance exposure.
How does geofencing work at the connectivity layer?
Geofencing in the connectivity platform operates based on the device’s network registration location — the cell tower or geographic zone where the device is registered on the network. When a device registers outside a configured geographic boundary, the platform generates an alert via webhook, email, or SMS. This is a network-level detection mechanism that operates independently of the device’s GPS module or application software, which means it cannot be disabled by a firmware change on the device. For asset theft detection and regulatory compliance monitoring, network-based geofencing provides a backstop that does not depend on the device reporting its own location.
See OV’s security architecture in practice
OV’s full security stack — IoT SAFE, IMEI Lock, Private APN, data traffic filtering, geofencing, VPN, and SMS filtering — is available as standard across all deployments, managed through OV ONE via REST API. Book a demo or request a free trial SIM.
Book a Demo | Request a Free IoT SIM Trial
