Why Your IoT Device Keeps Losing Connection — and What a Multi-Carrier SIM Does About It
May 14, 2026
eIM Explained: The Server That Lets You Switch Carriers Without Touching the Hardware
SGP.32 introduced a management layer built specifically for IoT fleets. Here’s what it does, how it differs from what came before, and why the architecture choices you make now will matter at scale.
Consumer eSIM works because there’s always a person holding the device. You scan a QR code, tap “Activate,” and the carrier profile downloads. IoT devices don’t have that option — they’re sealed inside a meter cabinet, mounted on a highway gantry, or bolted to a shipping container. SGP.32’s eSIM IoT Manager — the eIM — was built to handle that reality. It’s not just a new server. It’s a redesign of who is in charge of SIM provisioning when no human is available.
What the eIM is — and why the old infrastructure wasn’t enough
The consumer eSIM specification, SGP.22, was built around two components: the SM-DP+ (Subscription Manager – Data Preparation Plus), which stores operator profiles, and the LPA (Local Profile Assistant), which runs on the device’s OS and waits for the user to initiate a download. The earlier M2M specification, SGP.02, replaced the LPA with an SM-SR (Subscription Manager – Secure Routing) that handled profile delivery server-side — but still required the MNO to coordinate each swap, not the enterprise customer.
Neither architecture was designed for the scenario where a fleet operator needs to switch 10,000 devices to a different carrier at 2am without dispatching a technician.
SGP.32 changed this by introducing the eIM (eSIM IoT Manager). The eIM is the server-side component that handles all profile lifecycle operations — push, enable, disable, and delete — for eUICCs (the embedded SIM chips) inside IoT devices, without requiring user interaction or MNO mediation. It communicates with each device through the IPA (IoT Profile Assistant), which can live either on the SIM card itself (IPAe) or on the device’s application layer (IPAd).
The critical architectural shift: control moves from the carrier’s portal to the enterprise’s operations platform.
What a fleet operator controls via the eIM
Four operations define what the eIM can do, and all four share one important property: the device doesn’t need to initiate anything.
Profile push. Load a new operator profile onto a device running a bootstrap or existing profile. The eIM sends the instruction. The IPA on the eUICC executes it.
Profile enable/switch. Activate a different stored profile, moving the device to a new carrier without physical access. What used to require a truck roll now requires a command.
Profile delete. Remove profiles that are no longer needed from the device’s storage.
Inventory and state management. Track which profiles are loaded on which devices and in what state — active, inactive, or pending.
The eIM also acts as the intermediary between your fleet and the SM-DP+ servers where operator profiles are stored. You’re not going through the MNO’s portal every time you need a profile change — the eIM handles the coordination. And because SGP.32 was designed for unattended devices, the spec defines behavior for devices that are temporarily offline: profile operations queue and execute when connectivity resumes, rather than failing silently.
That design requirement — unattended — is architectural, not just a feature claim.
What can go wrongThe eIM architecture is well-specified. How it’s implemented, and who sells it to you, determines whether you get genuine independence or just a new layer of the same problem.
Buying eIM from your connectivity provider. If your MNO bundles the eIM with your data plan, you’ve moved the lock-in up one layer. You can technically switch profiles — but only to profiles the same provider controls. The independence SGP.32 makes possible requires an eIM that operates outside any single MNO’s commercial relationship with you. The shift eSIM standards are creating for enterprise fleet buyers is exactly what’s at stake when you make this procurement decision.
Skipping EUM compatibility verification. An eIM tested against only one EUM’s (eUICC Manufacturer’s) chips is a pilot platform, not a production system. The GSMA spec allows for implementation differences between EUMs, and those differences surface in edge cases: state machine transitions, error handling, timing under load. Before you deploy, ask your eIM provider which EUM chips they’ve validated against — and ask for specifics, not just “yes, we’re compatible.”
Underestimating throughput requirements. A fleet of 1,000 devices feels manageable. 10,000 devices with simultaneous profile operations is a different engineering problem. Some eIM platforms were built for pilots and start queueing operations when fleet-scale load hits. Verify that the platform’s throughput ceiling fits the fleet size you’re planning for, not the one you have today.
What to do
Three steps to get SGP.32-ready with an eIM that delivers what the spec promises.
Confirm your eUICC exposes the IPA interface. Not all devices marketed as “eSIM-ready” are SGP.32-compliant. The eUICC must implement the IPA — either as IPAe (on the SIM) or IPAd (on the device). If your existing hardware doesn’t have this, a turnkey IPAe SIM card — one where the IPA is built into the SIM itself — lets you bring SGP.32 capability to deployed devices without a hardware refresh.
Choose an eIM that operates independently from your connectivity provider. The eIM should work with any MNO’s profiles, not only the profiles of the vendor selling it to you. If the same company is selling you the eIM and the connectivity, ask directly: can this eIM manage profiles from a different carrier? The answer tells you what independence you’re actually buying.
Ask which EUMs the platform has been tested with — by name. Interoperability claims without named EUM validation are not interoperability. A credible eIM provider can tell you exactly which chip manufacturers they’ve certified against and describe what that validation covered.
The eIM is the piece of SGP.32 that turns fleet SIM management into a software operation rather than a logistics one. Getting the architecture right — who controls the eIM, whether it’s independent, and whether it’s been validated against your hardware — is the decision that determines whether you realize that.
Explore how Simplex Wireless built its eIM platform in-house, on private cloud infrastructure, with carrier-grade throughput designed for production fleets.
This article was curated by Jan Lattunen, CCO Simplex Wireless
About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen