From Hardware Lock-In to Software Control: How eUICC Is Redefining Global IoT Connectivity

For most of the history of cellular connectivity, the SIM card decided everything. Which network you were on. Which country you could operate in. Whether your device could be managed remotely or required a physical visit. The SIM card was not just a component – it was a constraint.

That model is breaking down. Not because roaming SIMs came along and papered over the cracks, but because eUICC technology is changing the underlying architecture. Connectivity is shifting from something determined by hardware to something controlled by software. Understanding why that matters – and what it means for IoT deployments in particular – is what this article is about.

The problem with traditional SIMs

A standard SIM card carries a single IMSI. That IMSI is tied to one mobile network operator. When you source SIMs for a large IoT deployment – smart meters, EV chargers, industrial routers, CCTV systems, vehicle telematics – you are making a long-term commitment to that operator at the point of manufacture or procurement.

If coverage turns out to be poor at the installation site, you have a problem. If the operator raises prices, you have limited leverage. If you expand into a new market where your operator has no presence, you need a different SIM. And if regulations in that market restrict permanent roaming – as an increasing number of countries now do – you may have an illegal deployment on your hands.

The logistics alone are significant. Managing multiple operator relationships, multiple SIM SKUs, and multiple billing platforms across a device estate of any scale is operationally expensive. Physical SIM swaps in deployed devices are often impractical or completely impossible.

Roaming SIMs offered a partial solution. By giving a device access to multiple networks in a given country through roaming agreements, they reduced the coverage risk. Multi-IMSI SIMs went further, allowing devices to switch between pre-loaded identities to pick up local rates or localise to a specific network. But both approaches have limits that are worth understanding before we get to what eUICC actually changes.

Why roaming was only ever a temporary fix

Roaming SIMs work by allowing a device registered to one operator’s home network to connect via another operator’s radio infrastructure when abroad. That sounds straightforward, but there are several mechanisms that can undermine it in practice.

The first is steering of roaming. Operators can configure their networks to push roaming devices towards preferred partners, which may not be the network with the best local coverage. The device ends up on a network chosen for commercial reasons rather than technical ones.

The second is FPLMN lists – Forbidden PLMN lists stored on the SIM that prevent a device from registering on certain networks. These can cause unexpected connectivity failures that are difficult to diagnose remotely.

The third, and increasingly significant, issue is permanent roaming restrictions. A growing list of countries have introduced regulations that prohibit devices from roaming indefinitely on a foreign operator’s network. Brazil and Turkey enforce these restrictions. China, India, Saudi Arabia, Egypt, and the UAE all restrict large-scale deployments of permanently roaming devices in some form. For any IoT deployment with global reach, this is not a hypothetical risk – it is an active compliance challenge.

Multi-IMSI SIMs address some of this by carrying multiple subscriber identities on a single card. They can localise to a domestic IMSI once deployed in their final destination country. But multi-IMSI is proprietary technology with no standardised management layer. Each provider implements it differently. Switching providers means replacing hardware. And the identities available are fixed at manufacture – you cannot add a new operator profile after deployment.

eUICC changes the model at a more fundamental level.

What eUICC actually is – and why it is not the same as eSIM

The terms eSIM and eUICC are used interchangeably in most marketing material. They are not the same thing, and the distinction matters.

eUICC – the embedded Universal Integrated Circuit Card – is the hardware specification. It defines a secure element capable of storing multiple operator profiles and having those profiles managed remotely over the air. It can be implemented in various physical form factors: the traditional removable SIM shape, a soldered MFF2 chip, or an integrated iSIM within the device’s main processor.

eSIM is a broader term that describes the capability enabled by eUICC – specifically, the ability to provision and switch operator profiles remotely. When people say a device has an eSIM, they usually mean it has an eUICC inside and supports one of the GSMA’s remote SIM provisioning specifications.

The key point is that eUICC enables profiles to be added, switched, and deleted remotely, without any physical access to the device. For IoT deployments – where devices may be installed in a utility cabinet, embedded in a vehicle, mounted on a street pole, or deployed in a remote industrial facility – this is transformative.

SGP.02, SGP.22, and SGP.32: understanding the specifications

Not all eUICC deployments work the same way. The GSMA has published three main specifications that define how remote SIM provisioning works for different device types and use cases.

SGP.02 was the first, published in 2013, and targets industrial M2M deployments. Profiles are managed entirely by the connectivity provider – the operator or MVNO – with no involvement from the end user. Two core components handle the process: the SM-DP (Subscription Manager Data Preparation), which prepares and stores encrypted profiles, and the SM-SR (Subscription Manager Secure Routing), which manages profile delivery to the eUICC. The model is highly resilient and is still widely used by mobile operators and IoT MVNOs. Its main limitation is the requirement for bilateral integration agreements between operators, which adds complexity and can restrict which operators a deployment can work with.

SGP.22 was published in 2016 for consumer devices – smartphones, tablets, smartwatches, connected laptops. The end user activates profile downloads themselves, typically by scanning a QR code or entering a confirmation code. The architecture is simpler in some respects: SM-DP+ replaces the SM-DP/SM-SR combination, and a Local Profile Assistant (LPA) on the device handles user interaction. There is no need for pre-established bilateral links between operators. SGP.22 is not well suited to headless IoT devices with no user interface, though it is increasingly used in some IoT scenarios where direct user activation is feasible.

SGP.32, published by the GSMA in 2023, is the specification built specifically for IoT at scale. It borrows architectural elements from both SGP.02 and SGP.22 and introduces two new components designed to solve the headless device problem: the eIM and the IPA.

The eIM – eUICC IoT Manager – is a standardised, remotely operated management layer that can communicate with any IoT device or SM-DP+, without complex bilateral integrations. It is the component that enables genuinely software-defined connectivity management at scale. The IPA – IoT Profile Assistant – replaces the LPA from the consumer specification and enables the eUICC to be managed remotely using existing SM-DP+ infrastructure. The IPA can sit either on the device itself (IPAd) or within the eUICC (IPAe), giving device manufacturers flexibility in how they implement support.

SGP.32 also adds support for CoAP and MQTT communications protocols, which matter because many constrained IoT devices cannot support the HTTPS connections required by earlier specifications. The first GSMA-certified SGP.32 products appeared in mid-2025, with broader ecosystem adoption expected from 2026 onwards.

SGP.32 is intended to supersede SGP.02 over time. SGP.22 will continue to serve consumer and enterprise use cases. For the foreseeable future, all three specifications will coexist, and device manufacturers and enterprises need to plan for a migration path rather than an immediate switch.

For a detailed technical breakdown of SGP.32, see our SGP.32 guide.

The eIM: the component that most people haven’t heard of yet

Of all the elements introduced by SGP.32, the eIM is the one that receives the least attention in mainstream coverage – and arguably the one with the most strategic significance.

In earlier specifications, managing operator profiles on a large IoT estate required either operator-side infrastructure (SM-SR in SGP.02) or user action (LPA in SGP.22). Neither is appropriate for a fleet of thousands of deployed, headless IoT devices spread across multiple markets.

The eIM solves this. It acts as a centralised management interface that can communicate with any eUICC in a device fleet, regardless of which SM-DP+ holds the profiles. Because it uses standardised interfaces, it does not require the bilateral agreements between operators that made SGP.02 integrations complex. A single eIM platform can manage profile operations across multiple operators and multiple markets.

This is what makes software-defined connectivity genuinely possible at scale. The network selection decision shifts from the SIM card – a fixed hardware component – to a software policy running on the eIM. In principle, that policy can optimise for cost, coverage, regulatory compliance, or latency, and update without any physical intervention on any device.

For enterprises running large IoT estates, the eIM is not just a technical specification. It is the management architecture that makes global deployment operationally viable.

Regulatory compliance and the localisation problem

One of the strongest practical arguments for eUICC – and specifically for SGP.32 – is regulatory compliance in markets that restrict permanent roaming.

The list of affected markets is significant and growing. Brazil requires IoT devices to use domestic operator profiles after a defined period of roaming. Turkey has similar restrictions. India, China, Saudi Arabia, and the UAE all have regulations that make permanent roaming on foreign operator networks problematic for large-scale IoT deployments.

For enterprises using traditional SIMs or even multi-IMSI SIMs, compliance in these markets typically means sourcing separate SIM SKUs from local operators, managing those relationships independently, and maintaining separate logistics for markets with different requirements. It is expensive, complex, and does not scale.

eUICC with SGP.32 addresses this directly. A device can ship with a bootstrap profile and have a local operator profile provisioned remotely once it is deployed in its final market. The profile management happens centrally via the eIM, but the device connects as a local subscriber. Compliance is built into the architecture rather than bolted on as an operational workaround.

This is one of the reasons GSMA developed SGP.32 in the form it did. The permanent roaming problem was already straining the M2M model, and the consumer specification was never appropriate for headless IoT devices. SGP.32 with its eIM architecture provides a path to genuine global compliance without sacrificing central management.

Private networks, satellite, and the expanding connectivity landscape

eUICC is not only relevant in the context of public cellular networks. Two trends are reshaping what IoT connectivity means, and eUICC sits at the centre of both.

The first is private cellular networks. Private LTE and private 5G deployments are growing in industrial, logistics, and critical infrastructure environments. They offer dedicated spectrum, lower latency, and greater security than public networks. An eUICC-equipped device can hold both a public cellular profile and a private network profile, switching between them as required – connecting via the enterprise’s private 5G network on-site and falling back to public 4G or 5G when mobile.

The second is non-terrestrial networks. 3GPP Release 17 introduced NTN support into the 5G specification, enabling cellular devices to connect to satellite networks using the same radio interface as terrestrial connections. This means that in the future, an IoT device with a single eUICC may be able to seamlessly switch between a public MNO, a private LTE network, and a satellite connection – all managed through the same profile management architecture.

The device of the future does not choose its network based on which SIM card was inserted at manufacture. It selects the best available connection – terrestrial, private, or satellite – based on policy. That is software-defined connectivity in practice.

MNOs and MVNOs: different roles in the eUICC ecosystem

Understanding who provides eUICC-based connectivity and how is important for any enterprise evaluating their options.

Mobile network operators own spectrum and radio infrastructure. They can offer competitive rates within their own network footprints, and they hold strong positions for negotiating roaming agreements due to consumer traffic volumes. Most major MNOs have deployed SM-DP+ infrastructure to support consumer eSIM services – by the end of 2024, more than 300 operators had done so – and this infrastructure is technically capable of supporting SGP.32 IoT eSIM services as well.

IoT MVNOs operate differently. They do not own radio infrastructure, but they purchase network access at wholesale rates and aggregate coverage across multiple operators. This gives them inherently broader footprints than any single MNO. Many IoT MVNOs have more advanced localisation capabilities through IMSI and eSIM profile agreements with multiple operators. For deployments that span multiple countries or require multi-network redundancy, MVNOs often provide more flexibility.

The two models are not competing – they are complementary. As SGP.32 adoption grows, the combination of MNO SM-DP+ infrastructure and MVNO eIM platforms will become the architecture underpinning large-scale global IoT connectivity.

What enterprises should do now

The SGP.32 ecosystem is still maturing. Certified products are only just beginning to appear, and broad operator support will take time. That does not mean there is nothing to do today.

Device manufacturers should begin evaluating eUICC chipsets and modules that include SGP.32 support, even if current deployments will use SGP.02 or SGP.22 profiles. Building eUICC capability into hardware now avoids a costly retrofit later.

Enterprises planning large deployments should audit their current SIM estate for regulatory exposure. If any of your target markets restrict permanent roaming, the time to address that architecturally is before deployment, not after.

Connectivity providers and platform vendors should be assessed not just on coverage and pricing, but on their roadmap for eIM support. The management layer is where the long-term value of eUICC is realised, and providers who are building or integrating eIM capabilities now will be significantly better positioned as the ecosystem matures.

And for any deployment with a lifespan of more than five years – which in industrial IoT means most deployments – the question of network sunsets is real. 2G and 3G networks continue to be switched off across Europe, North America, and Australia. An eUICC-equipped device can be migrated to a new network profile without physical access. A device with a traditional SIM cannot.

The direction of travel

The shift from hardware-defined to software-defined connectivity is not a prediction about a distant future. It is already underway. Consumer eSIM adoption has accelerated as smartphone manufacturers have standardised on eUICC. IoT eUICC adoption is growing steadily in M2M and telematics applications. SGP.32 provides the specification that extends this to the full range of IoT device types.

The model that replaces the traditional SIM looks something like this: a device ships with an eUICC and a bootstrap profile. Once deployed, an eIM provisions the appropriate local operator profile based on the device’s location and the enterprise’s connectivity policy. As conditions change – coverage gaps, regulatory updates, network sunsets, cost optimisation opportunities – the policy can be updated centrally, with no physical intervention on any device.

That is not a theoretical architecture. It is what SGP.32, the eIM, and the eUICC specification make possible today.

For further reading, see our guides to what eUICC is, the SGP.32 specification, and eSIM routers.