Roaming SIM  |  May 2026

The roaming SIM has been the default solution for IoT deployments needing multi-network coverage for the better part of a decade. Put a SIM with roaming agreements across multiple networks into a router or gateway, and the device connects to whichever network has the best signal. No configuration. No switching logic. It just works.

SGP.32 does not replace that model immediately. But it introduces an architecture where the operator profile itself – not just the network selection – can be changed remotely, silently, and at scale. That is a meaningfully different proposition, and understanding where the two approaches diverge is important for anyone specifying IoT connectivity today.

What SGP.32 actually does

SGP.32 is the GSMA specification for remote SIM provisioning on IoT devices. It defines how an eSIM profile – the digital equivalent of a physical SIM card – can be securely downloaded, enabled, disabled or deleted on a device without physical access, without a user interface, and without removing the SIM.

The key components are an eIM (eSIM IoT Remote Manager) on the server side, which orchestrates profile operations across a fleet, and an IPA (IoT Profile Assistant) on the device side, which executes those operations on the eUICC chip. The eUICC is the physical secure element – soldered to the device PCB – that holds the profiles.

For a full technical breakdown of how the architecture works, the SGP.32 architecture guide at sgp32.co.uk covers eIM, IPA, eUICC and SM-DP+ in detail. The SGP.32 FAQ covers the most common questions concisely.

Where roaming SIMs and SGP.32 overlap – and where they diverge

The honest case for roaming SIMs in 2026

Roaming SIMs – and particularly multi-IMSI SIMs carrying multiple network identities on a single card – are not obsolete. For deployed hardware on existing physical SIM infrastructure, they remain the correct answer. The network-switching speed of a multi-IMSI SIM is faster than any profile-based switching SGP.32 can achieve today. For applications where network resilience in seconds matters – emergency services connectivity, vehicle telematics, CCTV uplinks – a multi-IMSI SIM on existing hardware is hard to beat on that dimension alone.

The roaming SIM also requires nothing from the device manufacturer. Any router with a standard SIM slot works. SGP.32 requires a certified eUICC, an IPA implementation, and a relationship with an eIM provider. That is real additional complexity at the hardware design and procurement stage.

The honest case for SGP.32

The multi-IMSI roaming SIM solves the network selection problem. It does not solve the operator problem. Your device is still locked to the connectivity provider who issued the SIM. If their coverage deteriorates, their pricing changes, or a regulatory requirement emerges in a market you are entering, your options are limited to renegotiating with that provider or physically replacing SIMs in the field.

SGP.32 solves the operator layer. With a certified eUICC and an eIM relationship, you can add new operator profiles to deployed devices without site visits. eIM portability – one of the least-discussed features of SGP.32 – means you can also switch your eIM provider without replacing hardware. The device is genuinely operator-agnostic for its entire field life.

For deployments with ten-year field lives – smart metering, industrial sensors, utility infrastructure – that flexibility is commercially significant. The operator landscape in 2036 will not look like it does today. Locking devices to a single operator’s commercial terms at manufacture is a real risk that SGP.32 eliminates.

What this means for UK IoT deployments today

The practical decision framework in 2026 is straightforward:

Existing hardware: multi-IMSI roaming SIM. Nothing else makes sense. SGP.32 requires hardware that is not in your deployed estate.

New hardware, short lifecycle (under 5 years): either approach works. Multi-IMSI SIM is simpler to procure and deploy. SGP.32 is worth considering if commercial flexibility or global deployment is important to the application.

New hardware, long lifecycle (5 years plus): specify SGP.32-certified eUICC from the start. The commercial and operational flexibility over a decade-long deployment lifecycle justifies the additional complexity at design stage. The hardware cost premium for SGP.32-capable eUICC modules has fallen significantly as v1.2 certification has become mainstream in 2025 and 2026.

Global deployments: SGP.32 is the stronger answer. Managing roaming SIM agreements across multiple jurisdictions, dealing with permanent roaming restrictions, and adapting to local regulatory requirements is significantly more manageable with remote profile provisioning than with fixed physical SIMs.

The bootstrap problem

One area where roaming SIMs and SGP.32 interact practically rather than compete is bootstrap connectivity. An SGP.32 device needs network connectivity to receive its first operational profile from the eIM. The bootstrap profile – loaded at manufacture – provides this initial connection. Specialist bootstrap SIM providers use multi-network roaming coverage to ensure that first connection succeeds regardless of where the device is deployed. In this sense, multi-IMSI roaming connectivity is a component of SGP.32 deployments rather than an alternative to them.

For UK deployments, choosing the right bootstrap provider is one of the more practically important decisions in an SGP.32 rollout.

Summary

SGP.32 does not make the roaming SIM obsolete in 2026. It makes the roaming SIM one layer of a more sophisticated connectivity architecture – the network selection layer – while adding an operator and profile management layer above it. For deployed hardware, nothing changes. For new hardware with long field lives, SGP.32 is the right specification to target from the start.

The question is not roaming SIM or SGP.32. For most UK IoT operators in the next three years, the answer will be both – multi-IMSI SIMs for resilient network selection, SGP.32 eUICC for long-term operator flexibility.