SGP.32 and the eSIM IoT Manager: How the New Standard Changes IoT SIM Management

SGP.32 is the GSMA’s IoT-native eSIM specification – and the eSIM IoT Manager (eIM) is the component at its heart. This post explains what the eIM does, why it matters, how it differs from the management architectures that came before it, and what it means in practice for organisations managing IoT SIM deployments at scale.

For the complete technical background on SGP.32 – including the full comparison with SGP.02 and SGP.22, the CoAP transport architecture, and a sector-by-sector breakdown of where the standard changes things – read the SGP.32 eSIM and IoT SIM Cards guide at IoTSIMs.co.uk. This post focuses on the eIM specifically: what it is, what it replaces, and why it is the component that makes SGP.32 operationally meaningful for IoT fleet managers.

What is the eSIM IoT Manager?

The eSIM IoT Manager (eIM) is the server-side management platform introduced in GSMA SGP.32. It is responsible for orchestrating eSIM profile lifecycle across an IoT device fleet – pushing provisioning commands to devices, managing profile activation and deletion, and coordinating with mobile operators’ SM-DP+ servers to prepare and deliver profiles to the right devices at the right time.

If you are familiar with SGP.02, the eIM replaces the SM-SR (Subscription Manager Secure Routing). If you are familiar with SGP.22, the eIM replaces the functionality of the SM-DP+ routing layer and the LPA interactions that required user intervention. In both cases, the eIM represents a significant architectural improvement – and removes the most significant operational constraints that made previous eSIM standards impractical for large-scale IoT deployments.

The core capabilities of the eIM are:

Server-initiated profile management – the eIM pushes profile changes to devices. Devices do not need to poll, initiate sessions, or have a user present. This is the fundamental shift that makes headless IoT device management viable.
Multi-operator orchestration – a single eIM can manage profiles from multiple mobile network operators simultaneously. Operator changes, profile switching, and multi-geography deployments are handled from one management layer without operator-by-operator integrations.
Asynchronous operation – devices that sleep between transmissions – NB-IoT sensors, battery-powered monitors, periodic-reporting field devices – can receive eIM commands on their next active window. The eIM queues instructions and delivers them when the device is available, without requiring an always-on connection.
eIM portability – the eIM relationship with a device fleet can be transferred from one eIM provider to another without a physical SIM change. This removes the vendor lock-in that was a structural feature of SGP.02’s SM-SR architecture.

What the eIM Replaces: SM-SR and Why It Mattered

Under SGP.02 – the M2M eSIM standard that preceded SGP.32 – the SM-SR sat between the operator’s profile preparation infrastructure and the eUICC in the device. Every profile operation went through the SM-SR, and the SM-SR was typically operated by or tightly coupled to a specific operator or connectivity platform.

This created three problems that limited SGP.02 adoption outside automotive.

First, operator lock-in. Changing operators on a deployed SGP.02 device required a complex SM-SR transfer procedure – effectively a handover of device management rights from one operator’s infrastructure to another. In practice, this was so cumbersome that many deployments simply stayed with the original operator for the device’s entire lifetime, negating the commercial benefit of remote operator switching.

Second, no multi-operator flexibility. A single SM-SR could not easily coordinate profiles from competing operators. Multi-operator deployments required either multiple SM-SR relationships or a connectivity platform that abstracted the complexity – adding cost and reducing transparency.

Third, operator dependency for management. Because the SM-SR was operator-adjacent infrastructure, the enterprise had limited direct control over its own device fleet. Management actions depended on the operator’s systems and SLAs.

The eIM resolves all three. It sits as an independent management layer above the operator infrastructure, coordinates with multiple operators’ SM-DP+ servers directly, and is portable – meaning the enterprise’s relationship with the eIM platform is separate from its relationships with the mobile operators whose profiles that eIM manages.

eIM Portability: Why It Matters More Than It Sounds

eIM portability is the SGP.32 feature that receives less attention than it deserves. In SGP.02, the SM-SR created a binding between the device and a specific platform that was effectively permanent for the device’s deployed lifetime. Changing SM-SR provider required physical SIM replacement or complex migration procedures – neither acceptable at scale.

SGP.32 defines a standardised eIM transfer procedure. A device fleet can be migrated from one eIM platform to another without physical access to any device. The eIM transfer is coordinated at the server level – the current eIM and the receiving eIM authenticate with each other, transfer device management rights, and the devices themselves transition transparently on their next active window.

For enterprises evaluating eSIM management platforms, this changes the commercial dynamic significantly. You are not making a permanent hardware-lifetime commitment to a single platform when you deploy SGP.32 devices. You are choosing an eIM platform for its current capabilities and commercial terms, with the option to migrate if better options emerge. That is a meaningful difference from the lock-in model that characterised previous generations.

For a detailed technical walkthrough of how eIM portability works in practice, see the eIM portability guide at SGP32.co.uk.

The IPA: The On-Device Half of the eIM Relationship

The eIM is the server side. The IPA (IoT Profile Assistant) is its counterpart on the device. The IPA receives commands from the eIM, communicates with the eUICC to execute profile operations, and reports status back. It replaces the LPA (Local Profile Assistant) from SGP.22 – with the critical difference that the IPA requires no user interaction.

SGP.32 defines two IPA variants with different hardware implications:

IPA-d (device) – the IPA runs directly on the IoT device itself. This requires sufficient processing capability and memory on the device to run the IPA software stack alongside the device’s primary application. Appropriate for more capable IoT hardware – industrial gateways, connected equipment with embedded compute.
IPA-e (external) – the IPA runs on a companion device, typically an IoT gateway, that manages the eUICC on behalf of the constrained end device. This allows even the most resource-constrained IoT hardware – simple NB-IoT sensors with minimal processing capability – to participate in SGP.32 management via a gateway that handles the IPA function.

The IPA-e approach is particularly significant for large-scale sensor deployments where the end devices genuinely cannot run the IPA stack themselves. The gateway handles eIM communication on behalf of the sensor cluster, making SGP.32 management viable across a heterogeneous fleet with widely varying device capabilities.

The full IPA-e vs IPA-d comparison – including which deployment architectures suit each variant – is covered at SGP32.co.uk.

How the eIM Fits Into the SGP.32 Architecture

The full SGP.32 architecture has four primary components. Understanding how the eIM sits relative to the others makes its role clearer.

eUICC – the embedded SIM chip in the device. Stores profiles, executes switching commands from the IPA. For a full explanation of the eUICC itself, see euicc.co.uk.
IPA – the on-device (or companion-device) software that bridges the eUICC and the eIM. Receives commands from the eIM and executes them locally.
eIM – the server-side management platform. Orchestrates profile lifecycle, coordinates multi-operator provisioning, handles fleet management operations. This is the platform that eSIM IoT Manager provides.
SM-DP+ – the operator’s profile preparation server. Prepares and secures profiles for delivery. The eIM communicates with SM-DP+ servers at multiple operators to retrieve and deliver profiles on demand. SGP.32 deliberately reuses the SM-DP+ infrastructure already deployed for SGP.22, lowering the barrier to operator adoption.

The eIM’s position in this stack – above the operator infrastructure but below the enterprise application layer – is what gives it both its flexibility and its significance. It is the control plane for the entire IoT SIM estate. The full SGP.32 architecture breakdown at SGP32.co.uk maps all four components and their interfaces in detail.

What the eIM Means for IoT Fleet Management Today

SGP.32 hardware – certified modules with IPA-d or IPA-e support – is reaching commercial availability through Quectel, Thales (Cinterion), and others through 2025-2026. Most IoT devices in the field today run SGP.02, SGP.22, or physical SIMs. The eIM as an SGP.32 management layer is a forward architecture – the right foundation for new hardware designs, not a retrofit for existing fleets.

That said, the operational principles the eIM embodies – centralised remote profile management, multi-operator flexibility, server-initiated provisioning, no physical SIM access required – are exactly the outcomes that IoT fleet managers need right now. For current deployments on physical IoT SIM cards, multi-network IoT SIMs from IoTSIMs.co.uk provide the network flexibility and management capability that the market requires while the SGP.32 hardware ecosystem matures.

For organisations planning new hardware designs or multi-year deployment programmes, building eIM-ready architecture into the specification now – selecting SGP.32-capable modules where available, choosing eIM platforms with documented portability support, and planning connectivity strategy around the operator flexibility SGP.32 enables – is the right approach.

eIM Security: The Platform That Manages Everything Is the Platform That Must Be Secured

The eIM’s centralised control over an entire IoT SIM estate makes it a high-value target. An eIM platform compromise does not just affect one device – it potentially affects every device under management. Platform security is therefore a first-order requirement, not an afterthought.

The key security requirements for an eIM platform are:

Strong authentication and MFA for all administrative access to the eIM management console.
Role-based access control – operators, administrators, and read-only users should have access limited to the functions and device groups they legitimately need.
Full audit logging of all profile operations, administrative actions, and authentication events – with tamper-evident log storage.
Cryptographic integrity of profile delivery – all provisioning commands should be authenticated end-to-end between the eIM and the eUICC, preventing injection of malicious profile commands by an attacker with network access.
Incident response capability – the ability to suspend profile operations for specific devices or groups immediately if a compromise is detected.

The eSIM security landscape – covering eIM attack surface, bootstrap security, and defensive architecture – is covered in detail at SGP32.co.uk’s eSIM security guide.