Insights
IoT eSIM explained: SGP.32, the eIM and who controls your fleet
What the label IoT eSIM actually covers
SGP.31 sets the architecture and requirements, and SGP.32 gives the technical solution. Both address IoT devices that are network constrained, user interface constrained or both. SGP.31 must be used together with the general RSP architecture in SGP.21, so a single document does not describe the whole system.
Versions matter. On 3 November 2026 the GSMA index listed SGP.32 V1.2 and V1.3 as active and V1.1 as expired, with SGP.33 V1.2 test specifications active. A datasheet that only says eSIM tells you none of this, so ask for the exact specification and version for the card, the device software and the management platform.
The parts of the system and the question each one raises
The architecture separates the secure element, the device software and the servers. They can come from different companies, which is why a single supplier statement rarely settles compatibility.
| Element | Role in the specification | Ask |
|---|---|---|
| eUICC | Secure element that holds profiles and verifies signed instructions | Which specification version, and which optional mechanisms are supported? |
| IPA | IoT Profile Assistant in the device (IPAd) or in the eUICC (IPAe); at most one is active per eUICC | Who supplies it, and does our module and firmware include it? |
| eIM | eSIM IoT Remote Manager that performs remote profile state operations on one device or a fleet | Who operates it, and under whose contract? |
| SM-DP+ | Prepares and delivers the protected profile package | Which SM-DP+ issues the profiles we would use? |
| SM-DS | Discovery service; use is optional for the device, the eIM and the SM-DP+ | Is it needed in our download flow? |
| Mobile service provider | Issues the subscription and the profile; the commercial terms are outside the specification | Which contract covers each country? |
Who controls the eIM is the real lock-in question
The specification leaves room for flexibility. An eUICC can be associated with zero, one or multiple eIMs, and the solution must not require a specific eIM to be fixed at manufacturing. Annex B describes eIM configuration during eUICC manufacturing, during device production, in the field by a backend system, or by an existing eIM.
Control tightens after the first association. From then on the eUICC only accepts further configuration operations signed by an associated eIM, and adding another eIM is that eIM's responsibility. Support for these configuration operations is optional in the eIM and the IPA, and a complete-removal function is also optional.
Our reading for procurement: a standard architecture does not by itself guarantee an exit. If the current eIM cannot or will not sign a handover and the device has no protected reset, changing manager may be hard in the field. Put the handover procedure, its cost and the party responsible into the contract before the first association is made.
A bench test before you commit to a fleet
The eUICC must support the rollback mechanism, but it runs only when the eIM has requested it and the IPA reports that it cannot reach the eIM after a profile change. A fallback profile is a separate optional mechanism: at most one profile may carry the attribute, and the profile owner must authorise it. Do not assume either is configured in your product.
SGP.31 also lists aims such as working without SMS and without TCP/IP, and handling devices that wake only after long PSM or eDRX cycles. It states that this version focuses on devices using a remote manager and marks some related principles for further study. SGP.32 defines ESipa over HTTP and CoAP with an informative LwM2M option, so check which transport your device and eIM really share.
The steps below are our suggested acceptance procedure, not a test defined by GSMA. Record the results for each module and firmware combination.
- Record the EID, module, firmware, IPA location and specification version of the sample device.
- Confirm which eIM is associated, and how the association was made.
- Download a second profile on the bench and measure the data used by the download.
- Enable that profile with rollback requested, block its connectivity, and check that the earlier profile returns and the eIM receives the signed result.
- Send an operation while the device sleeps or is offline, and check when it runs and how much polling it causes.
- If the contract promises an exit, test adding a second eIM or the agreed removal procedure.
- Repeat the test after each firmware update that touches the modem, the IPA or the connectivity logic.
What IoT eSIM does not solve
The specifications define how a profile is delivered and managed, not what the subscription allows. They leave the description of profiles and subscriptions to the mobile service provider. An eSIM adds no coverage by itself: each profile still depends on its own operator, roaming agreement, device bands and contract terms.
A removable physical SIM may be the simpler choice when devices are easy to reach and one supplier fits the deployment. IoT eSIM earns its added integration work when replacing cards is impractical, for example with sealed devices, remote sites or a long service life. Our physical SIM versus eSIM framework covers that decision in more detail.
Compliance is also a question to check rather than assume. SGP.31 calls for an eIM compliance process under SGP.24, and it says an eIM may be declared compliant. Ask for the declaration and its version if a supplier uses compliance as a selling point.
Frequently asked questions
What is the difference between an IoT SIM and an IoT eSIM?
An IoT SIM describes a subscription and connectivity service for machines. eSIM describes how the operator profile is held and delivered: it is downloaded to an eUICC rather than fixed on one removable card. A project can use either, and the commercial terms still have to be confirmed.
Does SGP.32 let me change operator whenever I want?
Not on its own. A change needs a profile from a provider you have a contract with, an eIM that can trigger the download, a device with a working IPA, and network access to complete it. Test the switch and its recovery before you rely on it.
Do I need an eIM for every IoT eSIM device?
SGP.31 focuses on devices using a remote manager, but it allows an eUICC to have no associated eIM, and it allows optional profile download with immediate enabling from a default SM-DP+. Which route applies depends on the device and the supplier, so ask for it in writing.
Does Quanqiu IoT provide SGP.32 eSIM?
This article explains the standard and does not claim conformity or a specific capability. Send us your device, module and countries, and we will confirm in writing which SIM or eSIM route is available for that project.
Official references
Related reading
More insights
Send Quanqiu IoT your device model, module, countries and quantity, and we will confirm in writing which SIM or eSIM route fits the project.
Discuss your project