Exploring eIM’s Functions and Importance in IoT eSIM

Tags: eSIM
A picture of Mikk Lemberg
Written by
Mikk Lemberg

Welcome back to the latest update on our journey to IoT eSIM.

Since the last update, we have news regarding the eSIM IoT Remote Manager (eIM). The GSMA’s SAS group recently published the latest version of the SAS documentation, confirming that eIM falls within the scope of SAS-SM. This means the eIM has the same physical and logical security requirements as the existing SM-DP, SM-SR, SM-DP+, and SM-DS platforms in the RSP M2M and Consumer variants.

In today's update, we also focus on eIM. Last time, we discussed the different download methods defined in the IoT eSIM specification, with eIM playing a pivotal role in determining whether it is an indirect or direct download.

Today, let's review the functions of eIM and study its role in the IoT eSIM architecture.

eIM within the IoT RSP architecture

To delve deeper, we see four interfaces connected to the eIM, each playing a particular role:

  • ES9+': Connects the eIM to SM-DP+ and ensures secure transport of the eSIM profile (Bound Profile Package).
  • ES11+': The interface between the eIM and SM-DS (Alternative SM-DS or Root SM-DS) to trigger downloads through SM-DS.
  • ESipa: Connects the eIM with the IPA and triggers a profile download or provides secure transport for eSIM profile delivery (Bound Profile Package).
  • ESep: An interface between the eIM and eUICC that runs profile state management operations (PSMO) or associates eIMs with eUICCs.

Each interface is crucial for the profile download process, but it's essential to understand that an eIM must be associated with an eUICC to perform any operation.

Associating an eUICC with an eIM

The associated eIM stores eIM Configuration Data, which the eUICC uses for verification to respond to commands, preventing unauthorized control or misuse of eUICCs.

Let's consider when and how to associate an eIM with an eUICC.

The GSMA spec SGP.32 outlines scenarios for associating an eIM with an eUICC, leaving room for implementation details.

From our perspective, there are three use cases:

  1. The eUICC manufacturer (EUM) pairs manufactured eUICCs with a dedicated eIM.
  2. The device manufacturer develops a method to inform the IPA (IPAd) which eIM to associate with the eUICC.
  3. The current eIM (eIM_A) associates the eUICC with a new eIM (eIM_B).

We believe the first scenario will be the most common. Cellular connectivity providers source eUICCs to sell to IoT enterprises, associating them with the provider's eIM.

Additionally, a large multinational company may have its own eIM and request that eUICCs be manufactured with the provider's connectivity but paired with their eIM.

Who controls the eIM is crucial because replacing an associated eSIM requires adding a new eIM. Deleting the old eIM is optional, as eUICC can be associated with multiple eIMs. Still, the current eIM owner (perhaps an MNO) must allow the IoT enterprise to associate a new eIM with the eUICC.

I'll discuss profile swap scenarios later, but first, we'll see why eIM ownership is crucial. At the very least, you should have clear agreements on how the eIM can be used by the IoT enterprise to prevent misunderstandings.

If the IPA can execute an “EuiccMemoryReset” function, this is a workaround to overcome a possible eIM lock-in. This function resets the eIM Configuration Data in the eUICC and frees it from the previous eIM association. The eUICC can then be associated with any eIM, but only via the IPA — the second scenario mentioned above.

To add context to the third scenario, eIM configuration operations (referred to as eCO) include:

  • Adding an eIM: Associates a new eIM with the eUICC.
  • Deleting an eIM: Removes an associated eIM from the eUICC.
  • Updating an eIM: Updates the configuration data of an associated eIM.
  • Listing eIMs: Provides a list of all associated eIMs on the eUICC.

In addition to eSIM configuration operations, eIM triggers profile downloads and profile state management operations (PSMO).

These operations include actions from the M2M eSIM variant, such as activating, disabling, and deleting the profile on the eUICC.

Receiving a new profile

In a previous article, we explored methods for downloading profiles. To recap, the eIM can initiate a download in three ways:

  • by providing an activation code
  • by asking the IPA to contact the default SM-DP+ in the IoT device
  • by asking the IPA to contact SM-DS

We believe activation codes will be the primary way to activate a new telecom profile, as mentioned before.

The default SM-DP+ is useful for initial connectivity but has limitations. Using an SM-DS is not very popular, even for consumer eSIMs (SGP.22), because it requires significant coordination from device and cellular module manufacturers.

Let's start downloading a profile from an SM-DP+ using the activation code.

You can switch to another connectivity provider in two ways:

  1. IoT enterprises can use activation codes for the associated eIM from a new network operator. This depends on the agreement of the current network operator as they control the eIM.
  2. The other option is to first associate a new eIM with the eUICCs and then trigger the profile download from the desired network operator's SM-DP+.

If commercial terms and agreements aren't crafted suitably for IoT enterprises seeking flexible, future-proof cellular connectivity, there is a small risk of vendor lock-in.

To switch network operators, you need to start with a new connectivity management platform, such as integrating new APIs, setting up automation rules and notifications (if available on the platform), and so on.

Now follows a quick self-promo of 1oT.

As an IoT enterprise, you want to avoid dealing with multiple network operators or connectivity management platforms, so an independent middleman who coordinates and manages complexity is crucial.


That's why we integrate eIM functionality into our eSIM management tool (supporting M2M eSIM, SGP.02) in the 1oT Terminal. This lets us give customers a wider choice of network operators and enables them to bring their own connectivity deals under the 1oT Terminal umbrella.

As eSIM integrations become easier and easier, we focus on our mission to provide integrations with various network operators so that everything can be managed through the same platform.

Join 1oT's eSIM SGP.32 mailing list to stay updated with our blog series and learn about our process of developing the new IoT eSIM spec.