An eIM (eSIM IoT Remote Manager) is the software that allows IoT fleet managers to control which mobile operator profile runs on a deployed device. It downloads, enables, disables, and deletes profiles on eUICCs over the air, one device at a time or across an entire fleet, without anyone touching the hardware.
It’s one of three components introduced by the GSMA’s eSIM IoT specification, and it’s the one that lets you control connectivity after your devices ship. This guide covers what an eIM does, how it works with the other components, and the single question worth asking any vendor before you commit.
→ For the specification itself, including how it developed and how it compares to the earlier eSIM standards, read our guide to GSMA SGP.32.
What an eIM does
The eIM handles remote profile state management operations, or PSMOs. In practice that means 4 things:
- Download a profile. The eIM triggers a profile download from an SM-DP+ server onto the eUICC in a deployed device.
- Enable or disable a profile. A device running on one operator switches to another, over the air.
- Delete a profile. Old or unused profiles come off the eUICC to free space.
- List profiles. Display the profiles an eUICC has stored.
- Do all of it in bulk. The same operation runs across a fleet rather than one device at a time, with operations queued rather than executed one by one.
That last point is the reason the eIM exists. Remote SIM provisioning wasn’t new when SGP.32 arrived — the earlier standards already removed the physical SIM swap. What they didn’t cover was scale and management without a user interface.
→ If you want the background on how provisioning works more generally, we cover it in remote SIM provisioning for IoT.
How an eIM works with the IPA and the SM-DP+
An eIM doesn’t work alone – it’s a simple tool that serves as a medium between fleet managers and eUICCs. Three components have to be present, and each has a distinct job:
| Component | What it is | What it does |
|---|---|---|
| eIM | eSIM IoT Remote Manager | Decides what should happen to a profile and issues the signed instruction |
| IPA | IoT Profile Assistant | Sits on the device or the eUICC and carries the instruction out to the eUICC |
| SM-DP+ | Subscription Manager Data Preparation+ | Prepares and delivers the operator profile itself |
The IPA is the bridge between the eIM and the eUICC. It is the pull function that connects to the eIM, proactively and in regular intervals. IPA the IoT adaptation of the LPA, the component that does the same job on consumer phones. It’s unique to every eUICC or device and can live in either of these two places: on the device itself (IPAd) or on the eUICC (IPAe). For device makers, IPAe generally means less development work, because the integration is already in the SIM. The IPAd requires for the device manufacturer –whether that’s a modem manufacturer, a design house, or the end-operator of the fleet– to embed it into the device.
When a user orders the eIM to add a new profile, the eIM passes on the command to the IPA the next time the IPA reports to the eIM. The IPA then executes the command: It connects to the SM-DP+ and downloads the profile to the eUICC. From that moment on, the profile lives in the eUICC and the user can manage it via the eIM.
The SM-DP+ is a component already in use since eSIM consumer, SGP.22. The IPA is the equivalent of SGP.22’s LPA – the enabler of the pull function, which didn’t exist in SGP.02, eSIM M2M. The eIM is a brand new, open component in SGP.32, eSIM IoT, developed to absorb complexity outside the traditional device-network boundary.
→ If you want the component-by-component comparison, check out the differences between SGP.02, SGP.22, and SGP.32.
The one question to ask: is the eIM configurable?
Here’s where the specification gets interesting, and where a lot of buyers get caught.
SGP.32 says any eSIM IoT setup should let you add, manage, update, and list eIMs. Four commands: addEim, deleteEim, updateEim, listEim. Straightforward enough. But when reading the requirement levels carefully. The eUICC must support these operations. The eIM may.
Configurability is optional for the eIM and mandatory for the eUICC. That asymmetry has a consequence most vendors won’t volunteer.
You need an eIM to perform any eSIM IoT function — including installing a second eIM. So if your first eIM isn’t configurable, you can’t add another one. The eUICC will happily support the operation; you just have no way to issue it. Your devices are tied to that initial eIM, and to the profiles attached to it, for as long as they’re in the field.
This is why the first eIM you choose might be the last one you ever get to choose. Flexibility is written into the standard, but whether you can actually use it depends entirely on what the component in front of you allows.
When an eIM is configurable, introducing a second one is simple: the existing eIM sends its configuration data across, with no technical integration needed between them. Associations can also be removed. That’s what prevents the lock-in problem that dogged the M2M standard, and it’s the mechanism behind the freedom to leave a connectivity provider.
Do you actually need an eIM?
You need an eIM if your fleet is using SGP.32 eUICCs – but not every deployment needs SGP.32 to solve its problems, and it’s worth being honest about that before anyone signs anything.
If your devices operate in markets where you can roam without restriction, you’re not constrained to a single hardware SKU, and you’re comfortable with your current operator relationships, a multi-network roaming SIM may cover you perfectly well. eSIM IoT adds capability, and capability adds integration work.
An eIM platform –and eSIM IoT altogether– starts to earn its place when one of these is true:
- You’re launching into a market that restricts permanent roaming. Some countries require a local operator profile, which means loading one remotely or shipping different hardware per market. We’ve written about the permanent roaming problem in IoT in more detail.
- You need one hardware SKU across every market. Assign the operator profile after manufacture rather than committing to it on the production line.
- Your SIM is soldered in. With an MFF2 form factor, there’s no swapping it later. Whatever control exists at manufacture is all the control you’ll ever have.
- You want leverage at renewal. The credible ability to move fleet volume between operators changes a negotiation, even if you rarely act on it.
Where SGP.32 stands today
The standard is real and being used commercially. In April 2026, the IoT community IoT Stars ran the first independent, public, real-world test of SGP.32 across multiple vendors, migrating live devices between connectivity providers over the air. Onomondo was one of the connectivity providers that demonstrated full commercial delivery of its production profile and profile swapping under the standard.
Onomondo’s connectivity comes preloaded onto certified SGP.32 SIMs at the factory through our partnership with Kigen, so devices arrive with connectivity already on board — nothing to scan, download, or activate after they ship. Customers are testing and deploying on it today in Europe and North America.
One caveat to carry into any vendor conversation: eSIM IoT isn’t backward compatible with the M2M standard, and there’s no standardized migration path from SGP.02 to SGP.32.
Frequently asked questions
What is eIM in SGP.32?
The eIM, or eSIM IoT Remote Manager, is the component that handles remote profile state management for eSIM IoT devices. It downloads, enables, disables, and deletes operator profiles on eUICCs, across a single device or an entire fleet.
Is an eIM the same as an eSIM?
No. The eIM is a software tool through which you manage eSIMs. It is necessary to remotely manage the connectivity profiles in headless devices with SGP.32-compatible eUICC SIMs – or eSIMs.
What is the difference between an eIM and an SM-SR?
The SM-SR (Subscription Manager Secure Routing) played a comparable role in the older M2M standard, SGP.02. The eIM replaces it in SGP.32, with 2 practical differences: it handles bulk operations across fleets, and it can talk to any SM-DP+ without a pre-arranged agreement. It also introduces cryptographic authentication of profile operations.
Can I use an eIM without changing my connectivity provider?
Yes. The eIM manages profiles on the eUICC; it doesn’t affect whose network those profiles connect to. This means that you can keep your connectivity provider and manage their profiles with the eIM. That separation is deliberate, and it’s part of what interoperability under SGP.32 is supposed to deliver.
Does an eIM work with any SIM?
No — it needs an SGP.32-capable eUICC with an IPA available, either on the device or built into the SIM. Standard SIMs and older eUICCs can’t be managed this way.