eUICC SIMs, eSIM Routers and the Specs That Matter: M2M and IoT Guide 2026
The word “eSIM” is being applied to at least three different things in the M2M and IoT market in 2026. There is the plastic eUICC SIM card that arrives in the post. There is the soldered eSIM chip on a router’s circuit board. And there are three different GSMA specifications – SGP.02, SGP.22, and SGP.32 – that govern how these chips behave. These things are not the same.
Confusing them leads to hardware decisions that look fine on day one and create problems at contract renewal. This guide explains exactly what each of these things is, how the underlying specifications work, who controls what, and what questions you need answered before committing to any combination of hardware and connectivity.
Who this is for: buyers, sellers and deployers of M2M and IoT connectivity – fleet managers, system integrators, procurement teams, network engineers, and anyone evaluating cellular hardware or SIM contracts in 2026.
What is an eUICC? The foundations explained
eUICC stands for Embedded Universal Integrated Circuit Card. The key word here is “embedded” – not embedded as in soldered to a circuit board (though that is one application), but embedded as in the profile management capability is built into the chip architecture itself, rather than being fixed at manufacture as it is on a standard SIM card.
A standard SIM is provisioned once at manufacture: one ICCID, one network, one operator profile. If you want to change operator, you change the physical card. The card itself cannot be reprogrammed. This is true of every standard SIM in every phone, router, tracker, or industrial device currently deployed.
An eUICC contains a secure element – a tamper-resistant processor – that can store multiple operator profiles and switch between them over the air (OTA), without any physical intervention. The profiles stored on the eUICC can be provisioned, enabled, disabled, and deleted remotely. Which profiles can be loaded, when switching happens, and who has authority to instruct those operations – those things depend entirely on which GSMA specification the eUICC implements, and how it was provisioned when it left the factory.
The EID – the permanent identity that does not change
Every eUICC is permanently identified by its EID (eUICC Identifier) – a unique 32-character identifier burned into the chip at manufacture. The EID cannot be changed, cannot be re-programmed, and does not belong to any operator or provider. It is the chip’s permanent identity, equivalent to a device’s serial number at the hardware level.
The profiles loaded onto an eUICC each have their own ICCID (the SIM identifier most people are familiar with). When you change the active profile on an eUICC device, the ICCID changes but the EID stays the same. This distinction matters for contracts, for portability, and for understanding what you actually own in a deployment.
Key principle: Always reference EIDs, not ICCIDs, when negotiating portability and exit terms in a connectivity contract. An ICCID belongs to a profile provisioned by your current operator. An EID belongs to the chip – permanently.
The plastic eUICC SIM card: what you are actually receiving
A plastic eUICC SIM card looks identical to any other SIM card. It ships in the same form factor, fits in the same SIM card slot in your router or IoT device, and is physically indistinguishable from a standard SIM. The difference is entirely in the chip inside.
That chip is an eUICC – a secure element capable of storing multiple operator profiles. Depending on how it was provisioned by the issuing SIM provider, it may contain:
- A bootstrap profile – a minimal fallback profile that allows the device to connect to the OTA platform and receive commands or a full commercial profile.
- An active operator profile – the commercial connectivity profile the device uses once deployed.
- One or more stored profiles – secondary profiles held on the chip but not currently active.
The number of profile slots available and what is loaded into them at provisioning is defined by the SIM provider, not by the GSMA specification alone. A provider may offer a single active profile with no stored alternatives. The eUICC is capable of more – but whether that capability is exposed to you is a commercial and operational decision made by your provider.
The bootstrap profile is not neutral connectivity. Some providers configure the bootstrap profile to connect exclusively to their own OTA management platform. If the commercial relationship ends and that platform becomes unreachable, the bootstrap profile may not be able to reach any alternative platform. The device cannot receive a replacement commercial profile and becomes stranded. Ask your provider explicitly whether the bootstrap profile can reach any GSMA-compliant SM-DP+, or only theirs.
SGP.02 and the M2M control chain: who actually controls your SIM
Most plastic eUICC SIM cards deployed in industrial, M2M, and IoT contexts today use the GSMA SGP.02 specification – the M2M Remote SIM Provisioning standard. Understanding how SGP.02 works explains why the flexibility it appears to offer is more constrained than the marketing suggests.
Under SGP.02, there are two key infrastructure components:
- SM-SR (Subscription Manager – Secure Routing) – manages the eUICC itself. The SM-SR controls which profiles can be written to the chip, which profiles are enabled or disabled, and whether the eUICC can interact with any other infrastructure. Think of it as the gatekeeper for the chip.
- SM-DP (Subscription Manager – Data Preparation) – prepares and encrypts the operator profiles that get delivered to the device. The SM-DP creates the profile packages; the SM-SR authorises their delivery.
The critical point under SGP.02: your eUICC is registered on your SIM provider’s SM-SR from the moment it is manufactured or provisioned. No profile can be written to your eUICC without SM-SR authorisation. No profile can be deleted, enabled, or disabled without SM-SR instruction. Under SGP.02, profile switching is operator-initiated. Your provider’s SM-SR sends an OTA command to the device. The device processes it. The profile changes. You – the customer – do not initiate this. You do not have direct access to the SM-SR. You can request a switch from your provider, but you cannot perform one yourself.
What the provider controls, and what you do not
Under SGP.02, your SIM provider controls:
- Which operator profiles can be loaded onto your eUICC chips
- When profile switches happen, and in what order
- Whether your EIDs can be released to a different SM-SR if you change provider
- Whether your bootstrap profile can reach infrastructure other than theirs
- How many profile slots are provisioned and what is loaded in them
You control:
- Your commercial relationship with the provider (subject to contract terms)
- Which networks you have asked the provider to include in your profile portfolio
- Your device hardware (within the limits of what profiles the SM-SR will deliver to it)
Who owns the plastic eUICC SIM – and why this question matters
The plastic eUICC SIM was issued to you by your SIM provider. It was not sold to you in the way a router or antenna is sold to you. Like a standard SIM, it is a card issued under contract, registered on the provider’s infrastructure, and subject to the provider’s terms for as long as your account is active.
Your EIDs are registered on your provider’s SM-SR. This registration is the source of both the card’s functionality and your potential lock-in. Without SM-SR authorisation, no new profile can be written to any of your chips. If you want to leave your SIM provider and move to a competitor, you cannot simply ask the new provider to push their profiles to your existing plastic eUICC SIMs. The new provider has no authority over your current provider’s SM-SR.
The EID release process – what it is and why you need it in writing
In principle, under the GSMA M2M specification, there is an EID release process. The existing SM-SR can transfer custody of an EID to a different SM-SR, allowing the eUICC to be provisioned by a new provider. In practice:
- Some providers execute EID release cleanly, at a documented timescale, as part of their standard offboarding process
- Some providers execute it but only after commercial negotiation, effectively using it as a contract renewal lever
- Some providers have SM-SR platforms that do not support third-party SM-SR transfer at all
- Some contracts make no reference to EID release, leaving the situation legally ambiguous
If your provider will not release your EIDs: you face a binary choice. Stay with the provider, or physically replace every SIM card in your deployment. The eUICC capability that was supposed to eliminate physical SIM swaps does not help you in this scenario. The eUICC is working exactly as the SGP.02 spec intends – the spec was designed for operator-managed deployments, not customer-controlled portability.
Before signing any SIM contract involving plastic eUICC SIMs, get the EID release process documented in writing. Specify the maximum response timescale, any associated costs, and the format in which EID inventory will be provided for the transition.
Contract terms that create portability problems
Watch for contracts that reference ICCIDs specifically rather than EIDs. An ICCID belongs to a profile provisioned by your current operator – it changes when the profile changes. An EID belongs to the chip permanently. A contract that ties your deployment to specific ICCIDs may argue that changing provider constitutes a breach (because the ICCIDs have changed), rather than a legitimate transition. This is a commercial rather than a technical problem, but it is one that has caught customers out.
“Switch provider without a SIM swap” – what this phrase actually means
This phrase is used in two very different ways in M2M and IoT SIM marketing. Understanding the difference is important before committing to a multi-year contract.
What your provider means when they say it
Your current SIM provider can switch your devices between different underlying networks – without touching any hardware – because they have commercial agreements with multiple MNOs (Vodafone, EE, Three, O2, and others). They can instruct their SM-SR to push a new profile to your devices, moving them from Vodafone to EE for example, entirely over the air. You do not need a new SIM card for this operation. This is genuinely useful for coverage management, cost optimisation, and network steering. It is also entirely within the provider’s control.
What customers sometimes assume it means
That they can take their deployed eUICC SIM cards to any competing provider and that provider will be able to push their profiles to the existing chips. Under SGP.02, this is generally not possible without the active cooperation of the original SM-SR operator. The eUICC will only accept profile operations from the SM-SR it is registered with.
The question to ask before signing is: when the provider says “switch without a SIM swap”, are they describing switching between networks within their own portfolio, or are they offering genuine portability to competing platforms and SM-SR operators?
A useful test question: “If we moved our account to [named competitor] tomorrow, could that provider push their profiles to our existing eUICC SIM cards without your cooperation?” If the answer is anything other than a clear yes with a documented process, you are not buying genuine portability – you are buying flexibility within that provider’s network portfolio.
The eSIM router: a fundamentally different proposition
Some routers – and this category is growing rapidly – contain an eUICC chip that is soldered directly to the circuit board inside the device. You cannot remove it. You cannot slot it out and replace it. It is a permanent component of the hardware you purchased.
You own the router. You own the eSIM. This is the central ownership difference that changes everything else about how the connectivity works.
The router manufacturer loaded a bootstrap profile before shipping. This gives the device basic connectivity to reach an SM-DP+ server and download a commercial profile from an operator. Beyond that initial provision, the manufacturer has no ongoing commercial relationship with you through that chip. They are not your SIM provider. They do not control your profiles after the device leaves the factory.
The embedded eSIM in these routers is built to the SGP.22 (consumer RSP) specification. Under SGP.22, the device contains an LPA (Local Profile Assistant) – a software component that manages profile operations on behalf of the device owner. Profile downloads are device-initiated, not operator-initiated. The device connects to an SM-DP+ server and requests a profile. The SM-DP+ server delivers it. The LPA installs it. You choose which SM-DP+ to use. You are not locked to one that an existing SM-SR operator has registered your EID with.
Seven profile slots – why this matters
An SGP.22-compliant eUICC in a router typically supports seven profile slots. Only one profile is active at any time, but up to seven can be stored on the chip simultaneously. You can store profiles from multiple operators, switch between them on demand, delete old ones, and download new ones – without a physical SIM swap, and without needing your previous provider’s cooperation to do so.
This is structurally different from the SGP.02 scenario. The profiles on the chip can be managed by you, through any compliant SM-DP+ operator. The hardware you own is the gating factor – not the commercial relationship with a specific SIM provider.
Profile switching: who initiates, and why it changes everything
The difference in who initiates a profile switch is not just a technical footnote – it determines who has operational control of your deployed devices, and what your options are when you want to change something.
The operational implication of this difference scales with fleet size. In a deployment of a hundred devices, the difference between provider-initiated and owner-initiated profile switching is a process preference. In a deployment of ten thousand devices spread across multiple sites, it is the difference between operational independence and operational dependency on a third party’s platform and commercial goodwill.
SGP.32: the IoT-native specification arriving in 2026
SGP.32 is the newest GSMA specification and the one with the most significant implications for large-scale IoT deployments going forward. It was designed specifically to address the limitations of both SGP.02 and SGP.22 when applied to real-world IoT hardware at scale.
SGP.02 was designed for M2M devices that are reliably connected and managed by network operators. SGP.22 was designed for consumer devices – phones and tablets – that have displays, user interaction, reliable power, and persistent internet access. Neither maps cleanly to the reality of most IoT hardware: battery-powered sensors, intermittently connected assets, devices deployed in locations with marginal coverage, and fleets numbered in tens or hundreds of thousands of units.
What SGP.32 introduces: the eIM
SGP.32 replaces the LPA-based architecture of SGP.22 with the eIM (eSIM IoT Manager) – a lightweight remote management function that can push profile operations to devices without requiring a persistent connection or the overhead of a full SGP.22 management session.
Devices operating under SGP.32 can receive profile management commands via SMS, via a constrained binary protocol over low-bandwidth links, or via a dedicated IoT management channel. The eIM handles the coordination and queues operations until the device is available to process them. A device that wakes up once per hour to report sensor data and then sleeps can still receive and process profile management instructions – something the SGP.22 LPA architecture was not designed to support efficiently at scale.
What changes in practice
- Profile management works on intermittently connected and power-constrained devices
- Per-operation overhead is dramatically lower than a full SGP.22 session
- Large fleets can be managed centrally with asynchronous, push-based operations that match IoT operational rhythms
- The architecture supports the kind of bulk operations (simultaneous profile updates across thousands of devices) that SGP.02 and SGP.22 handle inefficiently
SGP.32 is covered in depth on sgp32.co.uk – including the full technical specification, the eIM architecture, commercial deployment timeline, and the first hardware reaching market in 2026.
The three specs compared: SGP.02, SGP.22 and SGP.32
eSIM routers also have physical SIM card slots
This is worth being explicit about because it is often omitted from product listings and marketing material. Most routers with a built-in eSIM also include one or two physical SIM card slots on the device body.
This means you can run connectivity options simultaneously:
- The built-in eSIM (soldered eUICC, SGP.22, your profiles, your control)
- A standard SIM in the physical slot from any operator you choose
- A plastic eUICC SIM in the physical slot from your MVNO provider
The combination of an embedded eSIM and physical SIM slots gives you hardware-level network redundancy. You configure one as primary, one as failover, and in most enterprise-grade routers, automatic failover between them can be set with configurable thresholds – latency, packet loss, signal strength. If one network goes down or becomes congested, the router switches without manual intervention.
This architecture is particularly valuable in critical connectivity scenarios: remote infrastructure monitoring, industrial process control, ATM and kiosk connectivity, transport telematics, and any application where a single point of network failure has operational or financial consequences.
A practical deployment pattern in 2026 is to run the built-in eSIM as a managed profile from a chosen operator for the primary connection, with a physical SIM slot carrying a different operator’s SIM as a cold standby. The physical SIM does not need to be an eUICC card – a standard SIM on a different network from a different commercial relationship provides genuine diversity that a multi-network MVNO SIM on a single SM-SR does not.
State of the market: M2M and IoT eSIM in May 2026
SGP.02: established, dominant, not evolving
The SGP.02 M2M specification remains the dominant standard for plastic eUICC SIM cards currently deployed in global M2M and IoT infrastructure. The management platforms, the commercial frameworks between MVNOs and MNOs, and the operational processes in the field are all built around it. Most of the world’s eUICC SIM cards currently in service run SGP.02. This will not change quickly – deployments have multi-year lifespans and the installed base is large.
The GSMA has not issued major revisions to SGP.02 in several years. The specification is considered complete and stable. New IoT deployments starting from 2026 have a genuine choice between SGP.02 plastic SIMs and SGP.22/SGP.32 alternatives in a way they did not have two or three years ago.
SGP.22: mainstream in hardware, expanding in commercial availability
SGP.22 eSIM routers are now mainstream hardware. Cellular router manufacturers in the mid-to-high end of the market ship with embedded eSIMs as standard. The commercial profile ecosystem – SM-DP+ operators offering multi-network profiles for routers – is established, competitive, and growing in the number of networks available per profile.
UK MNOs (EE, Vodafone, Three, O2) have SGP.22 connectivity live and are actively offering profiles through SM-DP+ operators. Coverage of European roaming networks via SGP.22 has reached near-parity with what was available on plastic SIM cards two years ago.
The hardware cost premium for an eSIM router over an equivalent router with only physical SIM slots has narrowed significantly from where it was in 2022-23. In the mid-range enterprise cellular router segment, the premium is now modest enough that the eSIM is no longer a specialist purchase – it is a considered option in most deployments above a certain size or complexity.
SGP.32: arriving in hardware, ecosystem maturing
SGP.32 hardware is in production in 2026. Initial commercial deployments are in infrastructure and industrial categories where the intermittent-connectivity benefits are immediately valuable – utility metering, environmental monitoring, logistics tracking, and agricultural IoT. The eIM operator ecosystem is forming around the established SM-DP+ operators, most of whom are extending their platforms to support SGP.32.
Device management platform vendors – the software layer above the SIM specification – are adding SGP.32 support in 2026. This is the layer that most enterprise buyers interact with (through APIs or management consoles), so the pace of platform adoption matters as much as the hardware availability.
The full SGP.32 ecosystem – eIM operators, IoT-optimised SM-DP+ infrastructure, device management platform support, and MNO roaming agreements that cover SGP.32 profiles – will reach maturity over the next 18 to 24 months. Planning new IoT deployments with hardware lifespans beyond 2027 should include SGP.32 readiness as a hardware selection criterion.
The MVNO and IoT SIM provider landscape
The major IoT MVNO providers are increasingly offering SGP.22 and SGP.32 connectivity profiles alongside their traditional SGP.02 M2M SIM products. The distinction between these product categories in their catalogues is not always clear, and the specification underlying each product is not always disclosed without asking directly. Some providers use “eSIM”, “eUICC SIM”, and “smart SIM” interchangeably across products that behave very differently.
Competition between providers is intensifying at the management platform and developer tooling layer. Providers who can offer clean APIs for bulk EID management, programmable profile switching, and transparent SLA reporting are differentiating on capability rather than network coverage alone.
Making the right hardware choice
Choose an eSIM router (SGP.22 embedded eUICC) when:
- You want to own the connectivity layer independently of any SIM provider
- Your deployment spans multiple countries or regions
- You need genuine operator flexibility without SIM logistics
- You are planning for a 3-5 year hardware lifespan and want SGP.32 optionality
- Failover between embedded eSIM and physical SIM backup is operationally valuable
- You are managing the deployment through a platform or API rather than manually
A router with physical SIM slots only may suit you when:
- Your operator relationship is stable, long-term, and not under review
- Your plastic eUICC SIM provider delivers genuine multi-network coverage across your deployment geography
- Your deployment is single-region with a known, reliable operator
- Hardware cost is a primary constraint and the eSIM premium is not justifiable
- Your MVNO has an adequate EID release policy and you have it in writing
Hybrid configurations are increasingly common in 2026. Many enterprise deployments run eSIM routers with a plastic eUICC SIM from their MVNO provider inserted in the physical SIM slot, using the embedded eSIM as a managed failover. This maintains the existing commercial relationship while adding genuine hardware-level redundancy through a different connectivity path.
See our eSIM router selection guide for hardware comparisons, coverage maps, and a breakdown of embedded eSIM specifications by manufacturer.
Making the right connectivity choice
The connectivity decision is separate from the hardware decision. You can combine them in any configuration:
- An eSIM router with a self-managed embedded eSIM profile from an SM-DP+ operator
- An eSIM router with a provider-managed profile on the embedded eSIM (the provider handles profile operations on your behalf)
- A standard router with a plastic eUICC SIM from your MVNO provider
- Any combination of the above using the physical SIM slots alongside the embedded eSIM
Red flags in SIM provider contracts and conversations
- No documented EID release process, or “we’ll discuss that at the time”
- SM-SR described as “proprietary” without reference to GSMA compliance certification
- Contract terms that reference specific ICCIDs rather than EIDs
- Bootstrap profile documented as connecting exclusively to the provider’s platform
- No SLA for OTA profile operations (provisioning, switching, deletion timescales)
- “eUICC-capable” hardware with no active OTA management infrastructure in place
- Inability to access your EID inventory on demand
- Contract minimum terms that exceed your expected hardware replacement cycle
What good terms look like
A well-structured SIM provider relationship provides: GSMA SGP.02 compliance documented with version reference; EID release process in writing with maximum response timescales and no exit fee; full EID inventory accessible to you on demand in a standard export format; bootstrap profile documented to reach GSMA-standard infrastructure, not exclusively the provider’s platform; OTA operation SLAs with compensation provisions; and commercial contract language that references EIDs, not ICCIDs, as the primary identifiers.
Twelve questions to ask your eUICC SIM provider before signing
- Which GSMA specification does this SIM implement – SGP.02, SGP.22, or SGP.32? What is the version number and when was it certified?
- Who operates your SM-SR, and is it GSMA-accredited? Is the SM-SR operated in-house or by a third party?
- Can your SM-SR accept profiles from third-party SM-DP+ servers, or only from your own platform?
- What is the documented process for EID release if we move to a different provider? What is the maximum timescale, and are there any associated costs?
- Can we receive our complete EID inventory in a standard export format at any time, on request, without requiring advance notice or commercial justification?
- Is the bootstrap profile configured to connect only to your OTA platform, or can it reach any GSMA-compliant SM-DP+?
- How many profile slots are provisioned on the eUICC? How many profiles can be stored simultaneously?
- What happens to existing profiles during a switch – are they deleted or moved to a disabled state? Is there automatic rollback if a switch fails mid-operation?
- What SLAs apply to OTA profile operations – provisioning, switching, and deletion – and what is the compensation provision if SLAs are missed?
- Does our commercial contract reference specific ICCIDs or EIDs as the primary identifiers? What portability terms apply to those identifiers?
- In the event that our account is suspended or our contract is terminated, what happens to the profiles on our devices? Can we still download a replacement profile from a different provider immediately?
- Are you able to demonstrate your SM-SR’s GSMA compliance with documentation, and will you provide that documentation before we sign?
Mini glossary of eUICC and eSIM terms
- 2FF / 3FF / 4FF
- The three physical form factors for removable SIM cards: standard (25x15mm), micro (15x12mm), and nano (12.3×8.8mm). All three form factors are available as eUICC variants. A plastic eUICC SIM uses whichever form factor fits the device’s SIM slot. An eSIM router contains a soldered MFF2 (industrial) or WLCSP chip – a form factor designed to be soldered, not slotted.
- Bootstrap profile
- A minimal operator profile pre-loaded on an eUICC that provides enough connectivity to reach an OTA management platform and download a full commercial profile. The bootstrap profile’s reach – whether it can access any GSMA-compliant SM-DP+, or only the issuing provider’s platform – is one of the most important due diligence questions for any plastic eUICC SIM deployment. Not all bootstrap profiles are equal.
- EID (eUICC Identifier)
- The permanent 32-character identifier burned into an eUICC chip at manufacture. Cannot be changed by any party. Uniquely identifies the chip regardless of which profiles are loaded. Under SGP.02, EIDs are registered on the SIM provider’s SM-SR. Portability between providers requires SM-SR release of the EID. Always use EIDs (not ICCIDs) as the primary reference in contracts and EID inventories.
- eIM (eSIM IoT Manager)
- The SGP.32-specific management function that enables lightweight remote profile management for IoT devices without requiring a persistent connection or the overhead of a full SGP.22 LPA session. The eIM can push profile operations asynchronously, making SGP.32 viable for battery-powered and intermittently connected devices at scale.
- eUICC (Embedded Universal Integrated Circuit Card)
- A SIM chip with an integrated secure element capable of storing and switching between multiple operator profiles over the air. Can exist in a removable plastic card (inserted in a SIM slot like any SIM), soldered to a circuit board (as in eSIM routers), or in industrial MFF2 or WLCSP form factors. The “embedded” in eUICC refers to the profile management capability embedded in the chip architecture, not necessarily to the physical mounting method.
- ICCID (Integrated Circuit Card Identifier)
- The 19-20 digit identifier associated with a specific SIM profile. On an eUICC, the ICCID belongs to the profile, not the chip – it changes when the active profile changes. Contracts referencing ICCIDs specifically (rather than EIDs) may create portability complications when profiles are switched or when changing provider. The EID is the correct permanent reference for a chip; the ICCID is the correct reference for an active profile.
- LPA (Local Profile Assistant)
- The software component in SGP.22-compliant devices that manages profile operations on behalf of the device owner. The LPA initiates connections to SM-DP+ servers, downloads profiles, installs them on the eUICC, and handles the switching between stored profiles. The LPA is the mechanism through which device owners exercise direct control over their connectivity under SGP.22 – there is no equivalent in SGP.02.
- M2M (Machine-to-Machine)
- Device-to-device communication without human intervention. The original use case that drove the development of SGP.02 and the basis for most industrial IoT connectivity architecture today. The term is used broadly to describe any deployment where cellular connectivity is used by a device to transmit data rather than for human communication.
- MFF2 / WLCSP
- Industrial eUICC form factors designed to be soldered directly to a PCB. MFF2 (M2M Form Factor 2) is a solderable package used in industrial-grade eSIM modules. WLCSP (Wafer Level Chip Scale Package) is a smaller variant used in consumer eSIM chipsets. Both are alternatives to the removable plastic card form factors. eSIM routers use soldered chips in one of these formats.
- MNO (Mobile Network Operator)
- A company that owns and operates its own cellular network infrastructure. In the UK: EE, Vodafone, Three, O2. MNOs provide the underlying network capacity that MVNOs resell. In an eUICC context, MNOs provide operator profiles that are prepared by SM-DPs and delivered to devices via SM-SRs.
- MVNO (Mobile Virtual Network Operator)
- A company that provides mobile connectivity by reselling capacity from one or more MNOs. Most IoT SIM providers are MVNOs, often with multi-network commercial agreements allowing automatic steering between MNO networks. The MVNO typically operates or contracts the SM-SR infrastructure that manages the eUICC SIM cards they issue.
- OTA (Over The Air)
- Any operation performed on a SIM or eUICC remotely, via the cellular network, without physical access to the device. Profile provisioning, switching, deletion, and parameter updates are all OTA operations. Under SGP.02, OTA operations are initiated by the SM-SR. Under SGP.22, OTA operations are initiated by the device’s LPA. Under SGP.32, OTA operations are coordinated by the eIM.
- RSP (Remote SIM Provisioning)
- The general GSMA framework enabling OTA management of eUICC profiles. The three RSP specifications – SGP.02 (M2M), SGP.22 (consumer), and SGP.32 (IoT) – define different architectures for who initiates profile operations, how profiles are secured and delivered, and what infrastructure is required. The RSP specification determines the operational model of any eUICC deployment.
- SGP.02
- The GSMA M2M Remote SIM Provisioning specification. The established standard for industrial and M2M eUICC deployments. Profile management is operator-initiated via SM-SR infrastructure. The device owner does not directly initiate profile operations. Most plastic eUICC SIM cards currently deployed globally use SGP.02. The specification is considered complete and stable – the GSMA’s development focus for new functionality has moved to SGP.32.
- SGP.22
- The GSMA Consumer Remote SIM Provisioning specification. Used in eSIM routers, consumer smartphones, and tablets. Profile management is device-initiated via the device LPA. Supports up to seven profile slots. The device owner has direct control over which SM-DP+ servers the device connects to and which profiles are downloaded and activated. The specification used in all major consumer eSIM hardware from 2018 onwards.
- SGP.32
- The GSMA IoT Remote SIM Provisioning specification. Designed for large-scale IoT deployments on resource-constrained and intermittently connected devices. Introduces the eIM (eSIM IoT Manager) for asynchronous, lightweight profile management. Hardware arriving in 2026. Will become the default specification for serious IoT deployments over the next two to three years.
- SM-DP / SM-DP+ (Subscription Manager – Data Preparation)
- The server infrastructure that creates, encrypts, and stores operator profiles for delivery to eUICC devices. SM-DP is the SGP.02 variant. SM-DP+ is the updated version used in SGP.22 and SGP.32, with improved security and flexibility. The SM-DP+ is the server an eSIM router’s LPA connects to when downloading a new operator profile. Under SGP.22, the device owner chooses which SM-DP+ to use.
- SM-SR (Subscription Manager – Secure Routing)
- The SGP.02 infrastructure component that manages the eUICC itself. The SM-SR is the gatekeeper for the chip: it controls which profiles can be written to the chip, which profiles are active or disabled, and which SM-DPs are authorised to deliver profiles. The SM-SR operator controls the eUICC even after the card has been issued to a customer. There is no equivalent in SGP.22 – its function is distributed across the LPA on the device and the SM-DP+ on the server.
About this guide: This article was written in May 2026 and reflects the current state of the GSMA RSP specification landscape, the M2M and IoT SIM market, and the cellular router hardware market as of that date. The SGP.32 ecosystem section will be updated as commercial deployments progress. For the latest on SGP.32 specifically, see sgp32.co.uk.