SGP.32 eIM Deployment: Multi-Carrier Fallback, Rollback and Profile Switching for IoT eSIM

Definition: In an SGP.32 IoT eSIM deployment, the IoT SIM is an eUICC holding several operator profiles, while an eIM sends signed instructions that decide which profile is enabled and how the device recovers when a switch fails.

The practical answer: an SGP.32 rollout gives you three different recovery tools, and they solve different failures. Rollback undoes a profile change that the eIM just made. Fallback moves the device to a designated backup profile when the device decides it has lost connectivity. Application-level switching, where device software compares signal readings and swaps profiles, is a design some OEMs add on top. Decide which of the three your device will use, who triggers each one, and how you will test them, before the first production batch is flashed. A multi-carrier eSIM that cannot recover from a bad switch is a single-carrier device with extra failure modes.

What changed from SGP.01, and why buyers notice

The first IoT eSIM architecture, SGP.01 from 2013, put the operator side in control: the operator’s platform drove activation and download on the device, and the SM-SR had to integrate with each operator’s SM-DP+ and SMS gateway, which raised integration cost and required terminals to support BIP and HTTPS (Li, 2024). The 2022 SGP.31 architecture borrowed from the consumer model and added the eIM, which manages profile state and can run as a standalone service or inside an SM-DP+ (Li, 2024). SGP.32 is the technical specification that implements it; the GSMA published it in July 2023 for network- and UI-constrained devices, and version 1.1 followed in April 2024.

Three changes matter in procurement. Profile download is triggered by activation codes rather than SMS, with mutual authentication between the eUICC and the SM-DP+. Asymmetric keys mean eUICC keys no longer have to be written during production. And the transport options fit constrained devices: SGP.32 binds the eIM-to-IPA interface, ESipa, over HTTP and over CoAP, with an annex for LwM2M (Li, 2024; GSMA SGP.32). For a buyer, that removes the old dependence on one operator’s SM-SR and SMS platform, but it adds a new party to the contract: whoever runs the eIM.

Who runs the eIM, and how you change it later

The eIM holds signing keys and certificates that the eUICC trusts, and it sends eUICC Packages carrying profile state operations: enable, disable, delete, list, and setting or clearing the Fallback Attribute. SGP.32 caps each package at one enable and one disable command, which keeps every change a small, auditable step. The eIM can be operated by the device maker, the enterprise customer or a connectivity provider. Each choice moves operational responsibility and key custody to a different company.

Plan the exit on day one. SGP.32 defines how eIM Configuration Data is added, updated and deleted on the eUICC, and how a list of associated eIMs is requested, so a fleet can be handed from one eIM to another without touching the hardware. Ask any supplier to demonstrate that handover on a sample device, and write the obligation into the contract. Our overview of eSIM versus physical SIM for IoT covers the commercial side of profile ownership.

Rollback, fallback and signal-based switching compared

Rollback protects an eIM-initiated change. When the eIM enables a new profile it can set a rollback flag. If the newly enabled profile does not provide connectivity, the IPA may call ProfileRollback, and the eUICC re-enables the profile that was active before the last package. The eUICC refuses with “rollbackNotAllowed” when the eIM did not grant it, and the operation is atomic: on any error both profiles stay as they were.

Fallback protects against losing the network later, long after a change. The eIM marks one operational profile with the Fallback Attribute. When the device detects a permanent loss of connectivity on the enabled profile, the IPA may call ExecuteFallbackMechanism, which disables the current profile and enables the fallback profile; ReturnFromFallback reverses it. Two details catch teams out. The function is optional for the eUICC, so a part may not support it at all. And SGP.32 leaves the definition of “permanent loss of connectivity” to the device implementation. Your firmware team writes that rule: how many failed attaches, over what period, in which radio conditions.

Signal-based switching is an application design rather than a standard function. One published method adds a control program and a local profile agent to the device, stores several operators’ profiles, and attaches a signal threshold to the profile template per device type. The program reads signal quality with AT+CSQ three times and averages it; in the worked example a threshold of 26 met readings of 13, 12 and 14, an average of 13, so the device switched to the second operator, but only when no data transfer was in progress, and switched back when the second profile measured weaker (Min, 2022). The study is a procedural design with a two-operator example and no field results, so treat it as a pattern to adapt, not a tuned algorithm.

Designing the fallback profile itself

A fallback profile is only useful if it attaches where the primary did not. Pick it for diversity: a different operator, ideally a different radio network in each target country, and commercial terms that allow it to sit idle for months and carry traffic when needed. If the primary and the fallback roam onto the same host network, a local outage takes both down and the mechanism only adds delay.

Keep the fallback profile able to reach the eIM. After a fallback the first task is usually to report what happened and receive a new instruction, so the fallback APN, firewall rules and data allowance must let the IPA talk to the eIM and the SM-DP+. A fallback profile restricted to application traffic strands the device on a link that cannot be managed. Also note the guards in the specification: fallback is refused while an emergency profile is enabled, and the eUICC rejects deletion of the disabled primary profile while a fallback or rollback can still return to it, although the fallback profile itself may be deleted.

Finally, write the return rule. ReturnFromFallback exists, but deciding when the primary has recovered is again device logic. A device that falls back and never returns can quietly run up charges on the backup operator. Report fallback events to the CMP so operations staff can see which devices, sites and countries depend on the backup; see how CMP platforms help manage global IoT SIM deployments.

Questions for module, eUICC and eIM suppliers

Ask the eUICC vendor whether ExecuteFallbackMechanism and ProfileRollback are implemented, and on which product versions. Ask the module vendor where the IPA runs, in the device (IPAd) or in the eUICC (IPAe), and whether its firmware exposes the calls your recovery logic needs. Ask the eIM provider which ESipa binding it supports, HTTP or CoAP, how it signs packages, how it reports profile state, and how a fleet moves to another eIM. Ask the profile owners whether each profile may be used as a fallback in each country. The earlier article on eSIM profile download for smart electricity meters covers the first-download path that precedes all of this, and our SGP.32 remote provisioning overview introduces the components.

How this maps to Quanqiu IoT and the project quote

Single-profile deployments in one or two countries can start with a Global IoT SIM catalog plan. A multi-carrier SGP.32 design is a project quote: we need the target countries, the eUICC and module models, the IPA location, who will operate the eIM, the expected traffic on primary and fallback profiles, and the recovery rules your firmware will apply. Which operator profiles can be supplied, whether a given profile may act as a fallback in a country, and how eIM operation is arranged are confirmed during project validation; we do not promise operator authorisation or coverage in advance.

FAQ

Is fallback the same as rollback in SGP.32?

No. Rollback reverses the last eIM-initiated profile change and only works if the eIM granted it. Fallback enables a pre-designated backup profile when the device judges that its current profile has permanently lost connectivity.

Does every eUICC support the fallback mechanism?

No. SGP.32 makes the fallback function optional for the eUICC, so confirm support on the exact part and firmware version before you design around it.

Who decides when the device has lost connectivity?

The device maker. SGP.32 leaves that detection to the device implementation, so your firmware must define the failure count, time window and conditions that trigger fallback.

Can we change eIM providers after devices are deployed?

The specification provides for adding, updating and deleting eIM configuration on the eUICC, which makes a handover possible. Whether it works smoothly depends on the parties involved, so test it and put it in the contract.

Should the device switch operators whenever the signal drops?

Not on every dip. Switch only after averaged readings stay below a threshold set per device type, switch while no data is moving, and include a rule for returning, otherwise devices oscillate between profiles.

Official References

• GSMA SGP.32 eSIM IoT Technical Specification, Version 1.1 (26 April 2024)
• GSMA: IoT RSP, Enabling the growth of Massive IoT
• Li Jie (2024). New Branches on an Old Tree: An Analysis of the GSMA SGP.31 IoT eSIM Architecture (in Chinese). 通信企业管理, (05), 78-80.
• Min Qingxue (2022). Automatic Switching Between Multiple Operators for IoT Device Communication Based on eSIM Technology (in Chinese). 通信管理与技术, (5), 45-49.
• Cheng Linlin (2025). Connecting Heaven and Earth with One Chip: How Does eSIM Achieve Seamless Roaming Between Terrestrial and Satellite Networks? (in Chinese). 通信世界, (11), 29.
• (2020). Rohde & Schwarz and COMPRION Provide Combined Test Solution for Remote SIM Provisioning of Embedded SIM (eSIM) (in Chinese). 电子测量与仪器学报, 33, 202.