Demystifying the New eSIM for IoT: What Every Enabler Should Know

One of the first challenges in any eSIM conversation is the terminology. Even within the telecom industry, there’s ongoing disagreement over what “eSIM” really means. 

Some interpret it as an Embedded SIM—a soldered chip (e.g., MFF2) on a circuit board. Others, like Simplex Wireless, define eSIM as an Electronic SIM, referring not to the physical form factor but to the network profile that can be downloaded or swapped remotely.

At Simplex, we emphasize that the form factor—2FF, 3FF, 4FF, or MFF2—does not matter when determining whether a SIM is eSIM-enabled. What defines an eSIM is the operating system running on the Universal Integrated Circuit Card (UICC). Whether it’s a soldered chip or a removable xFF-SIM, if it supports remote profile management, it’s eSIM-capable.

This distinction matters because IoT enablers—connectivity providers, device makers, and solution builders—must design systems that manage network access dynamically, not based on the size or type of card.

A Short History of eSIM Evolution

To understand where eSIM for IoT is headed, it helps to look back at how it began:

From SGP.02 to SGP.22 to SGP.32

In the beginning, the SGP.02 specification (often referred to as M2M eSIM) gave network operators remote control over eSIMs. The idea was solid—remotely switch a device’s carrier profile without swapping a SIM card—but in practice, it was heavily centralized around Mobile Network Operators (MNOs). 

The required backend integrations made it nearly impossible for small or medium-sized enterprises to participate. Switching networks required direct MNO-to-MNO coordination and was operationally cumbersome.

Then came SGP.22, which reimagined eSIM management for the consumer world. It introduced the Local Profile Assistant (LPA), allowing users themselves to download and activate eSIM profiles directly on their devices. It introduced the Local Profile Assistant (LPA), allowing users themselves to download and activate eSIM profiles directly on their devices with QR codes. 

This “liberal eSIM” model enabled freedom of choice and simplified onboarding, but it was not optimized for IoT devices that do not have user interfaces couldn’t easily use LPAs or scan QR codes.

The latest evolution, SGP.32 eSIM for IoT, merges the best of both worlds. It retains standardized remote management (like SGP.02) but introduces flexibility and accessibility (like SGP.22). It’s a fundamental shift designed specifically for IoT.

What SGP.32 Brings to IoT

The SGP.32 specification introduces several powerful mechanisms that make eSIM scalable, secure, and practical for IoT deployments.

#1: The EIM Server – A New Standardized Remote Management Platform

At the center of SGP.32 is the EIM (eUICC Identity Module) Server.

Think of it as the “brain” that orchestrates eSIM management across millions of devices. The EIM handles authentication, profile downloads, and remote updates in a standardized, vendor-neutral way—reducing the need for proprietary integrations.

For IoT enablers, this means interoperability and vendor flexibility. A properly implemented EIM can talk to any compliant eUICC, removing one of the biggest bottlenecks in earlier architectures.

#2: IPAd and IPAe – Two Approaches to Remote Management

SGP.32 defines two client-side agents:

• IPAd (IoT Profile Assistant Device) – A software agent running on the device. It manages the communication between the device and the EIM or DP+ (Data Preparation+) server.
• IPAe (IoT Profile Assistant eUICC) – An agent built into the SIM card’s operating system itself.

The IPAe model is particularly exciting because it enables legacy devices—those that never had eSIM support built in—to participate. Since the intelligence resides in the SIM, not the firmware, even older hardware can benefit from modern eSIM capabilities.

This “retrofit compatibility” is a game-changer for enablers managing mixed fleets of devices across multiple generations.

#3: Built-In APN Configuration

A subtle but critical feature in SGP.32 is the ability to embed the APN (Access Point Name) within the eSIM’s metadata.

Why is this important? When an eSIM profile is downloaded to a new device, the connection can initialize immediately without manual configuration—eliminating the risk of “stranded” devices that can’t reach the network after profile activation.

#4: Rollback for Connection Resilience

SGP.32 also introduces a rollback mechanism.

If a newly downloaded eSIM fails to connect within a defined time window (often around 10 minutes), the IPA automatically reverts to the previous working profile.

This ensures service continuity and protects IoT deployments from field failures—a crucial advantage when devices are remote, unmonitored, or inaccessible.

However, this mechanism depends on proper APN handling by the device, reinforcing why standardized metadata and EIM orchestration matter so much.

#5: Adding a New EIM – Redundancy and Reliability

The ADD EIM feature allows an IoT Profile Assistant to begin polling an additional EIM server.

This means a device can be moved to a new EIM, and the IPA can simultaneously communicate with two EIMs until one is removed, further reducing the risk of stranded or orphaned devices if a management server becomes unavailable.

For enablers operating across global markets, this dual EIM setup can also provide geographical redundancy and compliance flexibility.

#6: Direct vs. Indirect Download

SGP.32 allows two eSIM download modes:

• Direct Download – The IPA communicates straight with the DP+ server to fetch the profile.
• Indirect Download – The IPA retrieves the profile via the EIM server, which intermediates the process.

At Simplex Wireless, we see a clear pattern emerging:

• IPAe (SIM-based agents) should typically use indirect download, leveraging the EIM for management and security.
• iPad (device-based agents), on the other hand, often perform best with direct downloads, streamlining the process when device resources allow.

This dual-path flexibility shows the maturity of the technology when writing the specification, allowing the adopters of the technology to choose which method works best for them.

Why It Matters for Enablers

For IoT enablers—connectivity providers, MVNOs, device makers, and service aggregators—SGP.32 is more than a technical update. It’s the blueprint for the next decade of scalable IoT connectivity.

It enables:

• Faster onboarding – Download eSIMs directly from DP+ repositories.
• Vendor independence – Thanks to standardized EIM interfaces.
• Broader device compatibility – Through IPAe retrofits.
• Operational reliability – With rollback and dual EIM support.
• True remote lifecycle management – Without proprietary integrations.

Ultimately, SGP.32 aligns the IoT ecosystem around openness, automation, and resilience—three pillars that will define the next wave of connected solutions.

More than GSMA Update

The new eSIM for IoT specification isn’t just another GSMA update—it’s a paradigm shift that finally bridges the gap between telecom control and IoT flexibility.

By combining standardized remote management with easy provisioning and built-in reliability, SGP.32 empowers enablers to deploy and manage devices at scale without vendor lock-in.

At Simplex Wireless, we’ve embraced this transformation through our in-house EIM platform and xoSIM product line, helping solution builders and OEMs adopt SGP.32 effortlessly—whether their devices are brand new or already deployed in the field.