In consumer eSIM (SGP.22), there's one piece of software that does almost everything on the device side: the Local Profile Assistant (LPA). It's what your phone runs when you tap "download a new eSIM" and scan a QR code. 

But IoT devices don't have anyone to tap anything. 

So GSMA split the LPA in two, gave the two halves different names — IPA and eIM — and moved the latter completely off the device. That single architectural decision is most of the reason IoT eSIM needed its own standard instead of reusing the one built for phones.

This is a technical walkthrough of that standard: the entities involved, what each one actually does, and the mechanics of how a profile moves from a server to a device with nobody present to approve it. For the buying-decision version of this — what to check before you sign with a connectivity provider — see our companion piece on the SGP.32 stack for buyers.

_{Where SGP.32 sits in the eSIM family}

GSMA has published three remote SIM provisioning specifications, each solving for a different deployment context. 

SGP.02 came first, built for M2M (machine-to-machine) devices. 

SGP.22 followed, built for consumer devices — phones, tablets, watches, anything with a screen and a user who can scan a QR code. 

SGP.32 is the third: purpose-built for IoT devices that have neither a user interface nor, often, reliable SMS connectivity.

GSMA published the SGP.31 architecture specification — the high-level design — on April 19, 2022. The SGP.32 technical specification, the actual implementable standard, followed on May 29, 2023. Both are now at v1.2. SGP.33, the test specification that eUICCs, IPAs, and eIM/SM-DP+ platforms get certified against, was published in three parts on January 27, 2025: SGP.33-1 for the eUICC, SGP.33-2 for the IPA, and SGP.33-3 for the eIM and SM-DP+.

_{What SGP.32 actually fixes}

SGP.02's core limitation was structural, not incidental. 

Every M2M eUICC is bound to a single SM-SR (Subscription Manager – Secure Routing), and that SM-SR can only deliver profiles from SM-DPs it has been pre-integrated with — a commercial agreement typically negotiated between competing operators, who have limited incentive to make it easy. 

In plain terms: think of the eUICC as the SIM card itself, the SM-SR as its one designated "gatekeeper" server, and the SM-DP as a "vault" that holds the actual mobile network profiles a device could switch to. The gatekeeper will only accept keys from vaults it has already agreed to work with — and getting a new vault added to that approved list means two rival telecom operators have to sit down and sign a deal. Since neither one particularly benefits from making it easy for customers to leave, that approval process tends to move slowly, if it happens at all.

On top of that, SGP.02 profile downloads were triggered over SMS, which is unreliable or unavailable on constrained IoT technologies like NB-IoT and LTE-M. 

In a nutshell, the standard technically allowed profile switching. The market structure around it mostly prevented it from happening.

SGP.32 addresses both issues directly, with three specific changes: 

• Eliminates the SM-SR entirely, so any eUICC can receive a profile from any GSMA-compliant SM-DP+ once it has a valid activation code; 
• Removes SMS dependency, replacing it with IP-based communication that works over constrained networks;
•  Supports both push and pull download models, instead of forcing every device into one pattern.

_{The entities}

SGP.32 defines (or reuses) six functional entities:

• eUICC — the embedded chip that stores and runs profiles. Physically unchanged in principle from SGP.02/SGP.22 eUICCs, but running IoT-specific logic.
• EUM — the eUICC manufacturer. Companies like Kigen, Thales, G+D, and Idemia. Produces the chip and, critically, performs the initial eIM binding at manufacturing time.
• eIM — eSIM IoT Remote Manager. The new server-side entity SGP.32 introduces. Orchestrates profile lifecycle operations across a device or an entire fleet.
• IPA — IoT Profile Assistant. The new device-side entity. Executes what the eIM instructs, and is the local interface to the eUICC.
• SM-DP+ — Subscription Manager – Data Preparation. Reused directly from SGP.22 rather than reinvented. Prepares and hosts the actual profile packages.
• SM-DS — SM Discovery Server, optional. Lets a profile be made discoverable rather than pushed via a specific activation code, used less often in IoT deployments than in consumer ones.

The reuse of SM-DP+ from the consumer standard is deliberate: it means existing SM-DP+ infrastructure and expertise carries over, and it's one of the reasons SGP.32 could move as fast as it did once GSMA started publishing.

_{eIM: what it actually does}

The eIM is the control plane, and its function set breaks into two categories.

Profile download orchestration covers both directions the spec supports: direct download, where the eIM triggers the process but the device authenticates with the SM-DP+ itself, and indirect download, where the eIM authenticates with the SM-DP+ on the device's behalf and relays the result. The eIM also handles notification management — receiving status updates from the device (successful install, failure, current state) and forwarding them onward to the SM-DP+ where required.

Profile State Management Operations (PSMO) are the lifecycle commands the eIM issues to a profile already on the eUICC: enable, disable, delete. eIM Configuration Operations (ECO) are a separate set, and they're the ones that matter most for anyone thinking about vendor flexibility: add, delete, update, and list eIM associations on a given eUICC. In practice, these are the three operations — addEim, deleteEim, updateEim — that determine whether an eUICC can be handed off to a different eIM after deployment. The standard defines them. Whether a given provider's eIM actually exposes them to you is a separate, commercial question.

_{IPA: what it actually does, and the IPAd/IPAe fork}

The IPA is the device-side counterpart, and it has no user-facing role at all — no screen, no interaction, purely an execution layer. Its functions: acting as a proxy for profile downloads (receiving the Bound Profile Package and passing it to the eUICC, in segments if needed), handling discovery (querying an SM-DS for pending events, when one is in use), forwarding notifications, and conveying the results of PSMO and ECO operations back up the chain.

Where that logic actually runs is the one major implementation choice SGP.32 leaves open. IPAe hosts it inside the eUICC itself — the EUM builds it into the chip, and the device only needs to support standard SIM Application Toolkit commands under CAT (Card Application Toolkit, per ETSI TS 102 223 and GSMA SGP.32 Annex A): SIM lifecycle management (REFRESH, TERMINAL PROFILE, SET UP EVENT LIST), device information retrieval, SMS operations, timer management, and packet data service handling. No device firmware changes required. IPAd hosts the logic on the device itself — its application processor, its own firmware — and has to independently meet the SGP.33-2 test specification. It requires real development effort and a device with adequate processing headroom, but it gives the device manufacturer direct control over triggers, fallback behavior, and how the device negotiates with the eIM, rather than inheriting that behavior from the eUICC vendor's implementation.

_Interfaces

^Four defined interfaces carry the traffic between entities:

• ES9+ — profile reception directly from the SM-DP+.
• ES10b — direct communication between the IPA and the eUICC for lifecycle management commands.
• ESipa — the interface used for eIM-to-device interaction, central to the indirect download path for constrained devices.
• ES11 (optional) — communication with an SM-DS for profile discovery.

Underneath these, the actual transport depends on the device's connectivity profile. Broadband or always-powered devices typically run HTTP over TCP with TLS. Constrained devices — LPWAN technologies like NB-IoT — use CoAP over UDP with DTLS, a lighter-weight stack designed for intermittent, low-bandwidth connections. Providers on both ends need to support matching protocols; a mismatch here is a common, avoidable source of provisioning failures.

_{Profile lifecycle, mechanically}

The bootstrap profile — the connectivity a device ships with — is not delivered by SM-DP+ at all. The connectivity provider sends profile data (credentials, keys, configuration) to the EUM ahead of manufacturing, and the EUM loads it directly onto the eUICC at the factory, while simultaneously binding the eUICC to the provider's eIM. Both steps happen before the device exists as a finished product. SM-DP+'s role starts later, the first time a profile beyond that original bootstrap is needed.

At that point, direct and indirect download are functionally the same triggered process, differing only in who authenticates with the SM-DP+ — the device itself (direct) or the eIM on the device's behalf (indirect, for devices that can't run the full authentication and transport stack themselves). Once a profile is downloaded, PSMO commands from the eIM handle enabling, disabling, or deleting it. If the device or the operator relationship changes entirely, ECO commands handle moving the eUICC to a different eIM — assuming the current eIM is configured to allow it.

_{Triggers and polling}

A device has to learn that an instruction is waiting, and SGP.32 doesn't mandate one single mechanism for that. Interval-based polling is the baseline: the device checks in with the eIM on a schedule, anywhere from every few minutes to once a day depending on power constraints, and executes whatever's pending at that check-in. Well-designed implementations layer event-driven checks on top of the fixed interval — triggering a check-in on a device restart, or when the device attaches to a different network, rather than waiting for the next scheduled poll. Given that a polling interval directly trades responsiveness against battery life, and that fixed intervals mean an operator-initiated change can sit unactioned for hours, this is one of the areas where implementation quality varies most between vendors, despite all of them meeting the same standard.

_{Where the spec and the market stand today}

As of mid-2026, all three GSMA specifications are complete: SGP.31 and SGP.32 at v1.2, SGP.33 fully published across its three parts since January 2025. GSMA has been running SAS-SM certification audits for IoT eSIM infrastructure since the beginning of 2024, and multiple EUMs — including G+D, Thales, and Idemia — have certified IoT eSIM cards against the standard.

But the specification being complete and the ecosystem being production-ready are two different milestones, and the second one only caught up recently. Commercial-grade SGP.32 eUICCs are now shipping — 1oT received production cards in April 2026, roughly three years after GSMA published the technical spec — and the first live deployments are underway rather than still confined to lab testing and interoperability trials. For most of 2023 through 2025, SGP.32 was a standard you could read but largely not yet deploy against real, certified hardware at scale. That window has closed.