eSIM vs eIM: the real cost of remote IOT profile switching

The pitch for SGP.32 is compelling: deploy a device once, manage its connectivity remotely for the next ten years without ever touching it. No field visits when operators change, networks shut down, or roaming costs make a carrier switch necessary.

The technology exists. The standard is published. But between the promise and a working production deployment lies a set of practical, commercial and technical obstacles that most vendor materials leave out.

This article gives you an honest picture of what SGP.32 and eIM actually require, and what it really costs.

The difference between SGP.32, eIM and a traditional eSIM:

With a traditional SIM card, changing operator means a physical swap. With a traditional eSIM (SGP.22), a user can download a new profile remotely, but only by initiating the process themselves via a QR code, an activation code or an operator app. That model works for a smartphone. For a device bolted to infrastructure in a remote location, it does not.

SGP.32 is the GSMA standard built specifically for IoT. The eIM platform (eUICC IoT Manager) adds a management layer that allows an operator or connectivity manager to trigger profile downloads, swaps and deletions across an entire device fleet without any interaction at the device. That is the promise.

What needs to be in place before eIM works

Three dependencies need to align before eIM delivers on that promise. Each one is a project on its own.

1. Operator cooperation

The operator whose profile you want to download to your device needs to make that profile available through the eIM platform you are using. That is not automatic. Operators have commercial terms, minimum commitments and integration requirements. The eIM sits as an independent, centralized management layer that communicates with each operator’s SM-DP+ (Subscription Manager Data Preparation) server.That integration will have a cost associated and defined by operator, taking time to negotiate and implement.

MVNOs add a further layer of complexity. They sit between the underlying network and the end customer, and they have their own commercial agenda. Expecting them to make their profiles freely available for remote switching on demand is, at this stage of the market, optimistic.

2. IPA strategy

For a device to receive and execute profile commands from an eIM platform, it needs dedicated software in place. That software is called an IPA (IoT Profile Assistant). Without it, the eIM platform has no way to communicate with the device. There are two ways to implement an IPA, and choosing between them is one of the most consequential technical decisions in an SGP.32 deployment.

• IPAd runs on the device itself. It gives you full control over how profiles are managed and which eIM platform the device connects to. The trade-off is that IPAd requires custom development for each device type, because every manufacturer uses different low-level modem commands. It also needs ongoing maintenance whenever the eIM platform updates or a new provider is added.
• IPAe runs on the eUICC chip itself. It is a ready-to-use solution where the chip provider handles compatibility, updates and the technical roadmap. The implementation burden on your side is significantly lower.

Thingsdata supports both options. Our eUICCs carry an embedded IPAe, and we can assist with IPAd development where needed. More importantly, we help you make the right choice for your specific deployment before you commit to either path.

3. APN configuration

When a device switches to a new operator profile, it also needs the correct APN (Access Point Name) to connect to that operator’s network. Each operator uses different APN settings. Unless every operator in the world agrees on a single universal APN standard, which they have not, the device needs logic in place to configure the APN correctly after each profile swap. Without it, the device has a new profile but no working connection.

The full cost structure of an eIM deployment

Most SGP.32 articles focus on profile download transaction fees. That is the smallest part of the picture. The full cost structure looks like this:

• A eIM platform costs
  

At the eIM vendor level there is a SaaS licensing fee to access the platform, a monthly profile hosting fee per profile held in the repository (indicatively in the range of two to ten cents per profile per month depending on volume), a one-off provisioning fee each time a profile is pushed to a device (typically no less than thirty cents, with the ceiling depending heavily on vendor and volume), an integration fee per operator added to the platform, and a termination fee per SIM at the end of its lifecycle.

• Operator costs
  

At the operator level there are activation and termination costs, potential minimum term penalties, an integration fee that the operator charges the eIM vendor for SM-DP+ access and passes downstream, a dormant monthly recurring cost even when a profile is not active, and ongoing fees that reflect operators’ desire to monetise every touchpoint in a market they do not consider high value.

• Device-level costs
  

At the device level there are IPA development or licensing costs, custom firmware work per device type, and the ongoing cost of maintaining that firmware as both the device platform and the eIM standard evolve.

None of these cost categories are captured in a comparison of transaction fees alone.

When does SGP.32 make sense?

The economics of eIM improve significantly with scale and with deployment scenarios where the alternative is a physical site visit. The business case is strongest when:

• Your device fleet exceeds tens of thousands of units
• Devices are deployed in hard-to-reach or geographically distributed locations
• You anticipate operator changes or network migrations over the device lifecycle
• You operate across multiple countries and want to optimize for local connectivity without hardware changes
• The cost of a single field visit to swap a SIM card exceeds the total eIM cost per device

In these scenarios, the upfront investment in platform integration and firmware development amortizes over time.

When does it not?

SGP.32 adds cost and complexity that cannot be justified when:

• Your fleet is small and profiles are unlikely to change
• Devices are easily accessible and a physical SIM swap costs little
• Your operators are not yet integrated with available eIM platforms
• Your device hardware does not support SGP.32 and a hardware refresh is not planned

In these cases, a well-managed multi-roaming SIM card with a solid connectivity management platform delivers the same operational reliability at significantly lower complexity.

How Thingsdata helps you evaluate SGP.32 for your IoT deployment

SGP.32 is a genuine step forward for IoT connectivity. The standard is real, the use cases are valid, and the technology will mature. But the market is early, the ecosystem is still forming, and the path from standard to working deployment requires careful evaluation of operator relationships, device capabilities and total cost of ownership.

Thingsdata supports SGP.32 and works with organizations that are evaluating whether eIM fits their deployment. As an independent IoT connectivity partner, not tied to any single operator or platform vendor, we help you assess the full picture: not just the transaction costs, but the integration costs, the firmware requirements and the commercial realities of operator cooperation.

If you are building a business case for SGP.32, talk to us before you commit. Thingsdata is happy to think along with you in concrete terms, from business case to implementation. Get in touch at +31-85-0443500 or email info@thingsdata.com.