Why IoT Needed Its Own eSIM Standard

The history of eSIM in IoT is largely a history of standards designed for other purposes being pressed into service for a problem they were not built to solve. Understanding why previous standards fell short makes it much easier to understand what SGP.32 actually changes – and why it matters for anyone specifying IoT SIM connectivity today.

What SGP.32 Actually Changes: The Three Core Shifts

SGP.32 is not just an incremental update to existing eSIM standards. It represents three architectural changes that together make remote IoT SIM management practically viable for the first time – including on the most constrained devices and networks in the IoT landscape.

1. Server-initiated provisioning

Every previous eSIM standard required the device – or a user operating the device – to initiate profile changes. The device pulled new profiles from the server. This model breaks down in IoT: a moisture sensor in a crop field cannot initiate a profile download when the operator changes. A submersible pump in a water treatment works cannot respond to a QR code. SGP.32 inverts this. The eIM (eSIM IoT Manager) pushes profile changes from the server side, allowing operators and connectivity managers to update SIM profiles on thousands of devices simultaneously with no device-side interaction required.

2. eIM replaces SM-SR – and removes operator lock-in

Under SGP.02, the SM-SR (Subscription Manager Secure Routing) created tight coupling between the device and a single operator’s infrastructure. Switching operators in the field required complex SM-SR transfer procedures. SGP.32 replaces the SM-SR with the eIM – the eSIM IoT Manager. The eIM is separate from the operator’s profile preparation infrastructure, sitting as an independent management layer. This creates genuine multi-operator flexibility: the eIM can orchestrate profiles from multiple operators, and the eIM itself can be ported from one provider to another without a physical SIM change. For an enterprise running a mixed IoT fleet across multiple geographies and operators, this is a transformative change.

3. CoAP transport for constrained networks

SGP.22 relied on HTTPS for all profile operations. On an NB-IoT device with a daily data budget measured in kilobytes, an HTTPS session for a profile download was impractical – the overhead alone could exceed the device’s daily allowance. SGP.32 uses CoAP (Constrained Application Protocol) over UDP with DTLS encryption – a protocol designed specifically for low-power IoT networks. Profile operations over CoAP complete with a fraction of the data overhead of HTTPS, making SGP.32 viable on the same NB-IoT and LTE-M networks that smart meters, utility sensors, and agricultural monitors actually run on.

SGP.32 vs SGP.02 vs SGP.22: The Comparison That Matters for IoT SIM Buyers

The full technical comparison – including where SGP.22 remains the pragmatic choice for connected gateways and routers today – is covered in depth at euicc.co.uk’s SGP.22 vs SGP.32 guide.

What SGP.32 Means for IoT SIM Buyers Right Now

SGP.32 is the future direction of IoT eSIM. But most organisations deploying IoT connectivity today are not deploying SGP.32 devices – because the hardware ecosystem is still maturing. The practical question for anyone buying IoT SIM cards in 2025-2026 is not “should I use SGP.32” but “how do I plan my connectivity strategy to be SGP.32-ready when the hardware is available?”

Most IoT devices in the field today use physical SIMs or SGP.22

Industrial routers from Teltonika, Milesight, Cradlepoint, and others – the hardware that powers the majority of UK IoT gateway deployments – currently implement SGP.22 where eSIM is supported at all. Physical SIM cards remain the dominant form factor across the IoT estate. This is not a problem to solve urgently. Multi-network physical IoT SIMs – like the unsteered IoT SIM cards available from IoTSIMs – provide excellent connectivity for the vast majority of current deployments, with the flexibility to switch networks automatically based on signal strength, and private APN and fixed IP options for security-critical applications.

SGP.22 with remote management delivers SGP.32-like outcomes on available hardware

Teltonika’s approach to eSIM is instructive here. The RUT241 and RUTX series routers support SGP.22 with up to seven stored eSIM profiles, managed remotely via Teltonika RMS. RMS adds server-initiated profile switching on top of SGP.22 – delivering the core operational benefit of SGP.32 (remote profile management without physical SIM access) on hardware that is commercially available right now. It is not SGP.32 – it does not use the eIM architecture or CoAP transport – but for connected gateway use cases, it delivers comparable operational outcomes. See the Teltonika RUTM55 overview on IoTSIMs for how this plays out on current 5G hardware.

Plan for eIM portability from the start

One of SGP.32’s most significant commercial features is eIM portability – the ability to transfer eSIM management from one eIM provider to another without a physical SIM change. For organisations planning new IoT deployments, this means the connectivity management layer can be changed independently of the physical hardware. When evaluating eSIM platform providers today – even for SGP.22 deployments – it is worth understanding their migration path toward SGP.32 and whether their platform architecture supports eIM portability. The eIM portability guide at SGP32.co.uk covers what to look for.

Where SGP.32 Changes Things: Sector by Sector

SGP.32 delivers different value in different deployment contexts. The underlying mechanism – server-initiated remote profile management without physical SIM access – is the same, but the operational impact varies by sector and by the constraints of the devices involved.

Smart metering and utilities

Smart meters have lifespans of 15 to 20 years. A physical SIM card installed during manufacture may outlive two or three mobile network operators, or at minimum outlive the commercial arrangements that made that operator the right choice at deployment time. SGP.32 allows remote operator switching for the entire device lifetime – and CoAP support makes it viable on the NB-IoT networks that UK smart meter rollouts actually use. SMETS2 meters currently use physical SIMs on the DCC network; the next generation of metering infrastructure is where SGP.32 becomes commercially significant at scale. For multi-network IoT SIMs bridging the gap in current smart metering deployments, see the IoTSIMs solution finder.

Industrial and manufacturing

Industrial devices inside machinery – motors, presses, CNC equipment, process control systems – may be physically inaccessible without production downtime. A SIM card change on a device inside a running production line is not a maintenance task that can be performed casually. SGP.32 eliminates physical SIM management entirely for these deployments, enabling seamless network switching, operator changes, and profile updates without any physical access to the device.

Logistics and asset tracking

Shipping containers, vehicles, and high-value assets cross borders continuously. Permanent roaming – a single global IoT SIM that always roams – carries roaming surcharges and is subject to fair-use restrictions on some networks. SGP.32 allows automatic switching to a local operator profile on arrival in a new country, eliminating permanent roaming costs and restrictions. One hardware SKU, one eIM platform, multiple local operator profiles deployable on demand. For current deployments, multi-network roaming IoT SIM cards provide practical global coverage while SGP.32 hardware matures.

Agriculture and environmental monitoring

Battery-powered sensors in remote locations may run on marginal NB-IoT coverage and wake from deep sleep only periodically – hourly, daily, or even weekly. SGP.32’s asynchronous operation mode is specifically designed for this: devices can receive and queue management commands during their brief active windows, executing profile changes without requiring an always-on connection. No previous eSIM standard supported this mode of operation. It is one of the capabilities that makes SGP.32 genuinely transformative rather than incrementally better for constrained IoT.

eSIM routers and connected gateways

Industrial routers and cellular gateways are the deployment context where eSIM is already commercially available and operationally relevant today – via SGP.22 implementations from Teltonika, Milesight, and others. For router-based deployments, the practical benefits of remote profile management are achievable now, without waiting for SGP.32-certified hardware. The detailed hardware landscape – which routers support which eSIM standards, and what the specification differences mean in practice – is covered comprehensively at euicc.co.uk’s eSIM routers guide.

eSIM Security: What SGP.32 Changes and What It Does Not

eSIM is often presented as a security improvement over physical SIM cards – and in some respects it is. But it introduces its own attack surface that is worth understanding, particularly for deployments in security-critical environments.

What SGP.32 improves

The eIM architecture separates profile management from the operator infrastructure, reducing the attack surface for SIM hijacking attacks that target operator systems. Profile provisioning over CoAP with DTLS provides end-to-end cryptographic authentication – a provisioning command cannot be injected by an attacker without access to the eIM’s credentials. eUICC chips include hardware security elements with tamper resistance equivalent to or exceeding physical SIM cards.

What remains a risk

The eIM platform itself becomes a high-value target. An attacker who compromises an eIM can potentially push malicious profiles to an entire device fleet. eIM platform security – access controls, audit logging, key management, and incident response capability – is critical. When evaluating eIM platform providers, security credentials matter as much as feature set. The eSIM security guide at SGP32.co.uk covers the attack surface and defensive architecture in detail.

The bootstrap problem also deserves attention: an eSIM device needs an initial connectivity profile to reach the eIM for its first provisioning. How that bootstrap profile is managed – which network, what credentials, and what happens if the bootstrap network is unavailable – is a practical deployment challenge that catches organisations out. See the bootstrap issues guide for a detailed walkthrough.

What to Ask Your IoT SIM and eSIM Provider

The eSIM and IoT SIM market is full of vendors who use “eSIM” as a broad marketing term without being precise about which standard they support, what their management architecture looks like, or what happens when you want to switch providers. These are the questions that cut through the noise.

Which eSIM standard does your platform support – SGP.02, SGP.22, or SGP.32?

These are fundamentally different architectures. A provider supporting SGP.22 cannot deliver the asynchronous, CoAP-based profile management of SGP.32. A provider supporting SGP.32 may have a limited hardware ecosystem to point to. Know which standard your specific devices and use cases require before evaluating platforms.

Who operates the SM-DP+ and eIM – you or a third party?

Profile preparation and eIM orchestration may be handled by the provider directly or outsourced to a third-party platform. This matters for data sovereignty, SLA accountability, and what happens if the provider changes its commercial arrangements or ceases trading. Full buyer guidance – including 30 detailed questions for eSIM providers – is available at sgp32.co.uk’s eSIM provider buyer guide.

Is eIM portability supported – can I switch eIM providers without a physical SIM change?

This is a critical lock-in question. If the answer is no, you are accepting dependency on a single eIM provider for the lifetime of the deployed hardware. Not all providers support eIM portability, and not all are transparent about this when selling.

What is your multi-network SIM approach for deployments that are not yet on SGP.32 hardware?

For the majority of IoT deployments today, multi-network physical SIMs with unsteered roaming remain the most practical connectivity choice. Ask how the provider’s physical SIM offering – network breadth, steering policy, private APN options, fixed IP, management portal – compares to their eSIM offering, and what the migration path looks like when SGP.32 hardware becomes available for your device category.