The eIM Is the First Enterprise System eSIM Has Ever Had

Every eSIM spec before SGP.32 put control in the hands of the OEM or the MNO. This one hands the keys to the person actually running the fleet.

Ask an enterprise IT admin who controls their laptops and they’ll point to a mobile device management console. Ask the same person who controls their cellular subscriptions and, until recently, the honest answer was: not them. That’s what changes with the eIM, and it’s worth being precise about why.

What the eIM actually is

The GSMA’s official name for it is the eSIM IoT Manager, the new server-side component defined in the SGP.32 specification. But that name undersells what it does. Functionally, the eIM is Enterprise eSIM Management: it’s the first component in the entire eSIM ecosystem built to be operated directly by enterprise IT, not routed through a carrier’s back office or baked into a device’s firmware at manufacturing.

That’s a genuinely new role. Earlier specs split control between two parties who were never the enterise’s own staff. SGP.22, the consumer-facing standard, relies on the LPA (local profile assistant), software living on the device and controlled by the OEM. SGP.02, the M2M standard, relies on the SM-DP+ (subscription manager data preparation), a profile server controlled by the MNO. In both cases, if you wanted to change a subscription, you were asking someone else’s system to do it for you.

The eIM changes that by giving enterprise IT a system they can operate themselves, provisioning, switching, and monitoring eSIM profiles across a fleet the same way an SGP.32 approach was designed specifically for unattended devices that do not have user interfaces and must be managed autonomously. It’s a close cousin of mobile device management (MDM), the category IT teams already use to push software and policy to a fleet of laptops and phones. MDM manages what’s installed on the device. The eIM manages the mobile subscription itself, the eSIM profile that determines which network the device talks to.

Why this is a paradigm shift, not an upgrade

Call it a spec update and you’ll undersell it. Every prior eSIM generation assumed the enterprise deploying the device was a passive party, someone who negotiated a contract, then lived with whatever provisioning process the OEM or MNO had built. SGP.32 was designed specifically for unattended devices that do not have user interfaces and must be managed autonomously, and that autonomy requirement is what forced the spec to define a genuinely independent management layer for the first time.

The practical result: an enterprise IT admin can now sit in front of a single console and provision, swap, or retire eSIM profiles across thousands of devices without opening a ticket with a carrier or waiting on a firmware update from an OEM. That’s the same shift MDM caused when it moved software management off the manufacturer’s release cycle and onto the IT team’s own timeline.

What independence actually requires

Here’s where the paradigm shift can quietly fail. An eIM only delivers on this promise if it’s genuinely independent of three parties: the MNO, the OEM, and the EUM (the eUICC manufacturer, the company that makes the physical SIM chip). If an eIM is built or operated by any one of those three, the enterprise hasn’t gained control, it’s just moved the lock-in one layer up the stack.

This is exactly where Simplex built its eIM differently from day one. It’s designed to give enterprises independence rather than route control through a single connectivity provider, with interoperability tested across multiple EUMs rather than tied to one manufacturer’s chip. The R&D and support behind it are based in the US, which matters practically: when an enterprise IT admin needs to escalate a provisioning issue at 2am, they’re talking to the team that built the platform, not a support queue three time zones away.

Where this goes wrong

The most common failure mode isn’t a technical one, it’s a vendor relationship that recreates the old lock-in under a new name. If the eIM you adopt is operated by your existing MNO, you haven’t gained carrier independence, you’ve just moved the control panel. If it only supports one EUM’s eUICC, your next hardware order is constrained by whatever chip that eIM was built around. And if the eIM vendor has no track record running systems at carrier-grade reliability, unattended fleets are the wrong place to find that out. The lessons from running SGP.32 at scale point the same direction: the platform has to stay available under all conditions, because devices depend on it to restore their own connectivity.

The eIM didn’t just add a feature to eSIM, it added a stakeholder. For the first time, the enterprise IT admin running the fleet has a system built for them, not adapted from something the OEM or MNO already had. That’s worth evaluating carefully before you pick a vendor, because the independence is the entire point, and it’s the one thing that’s easy to lose if you’re not checking for it.

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