eSIM Orchestration: Does SGP.32 shift the role of the MVNO?

2026 marks the year where commercialisation of fully-compliant SGP.32 (eSIM IoT Specification) eSIM solutions come to market. After several years of development, testing and certification eSIM within the IoT ecosystem has now, in theory at least, been decoupled from the MNO which historically owned the SM-SR and associated ability to support OTA (Over-the-Air) carrier profile switches during the SGP.02 (eSIM M2M Specification) era. The eIM (eSIM Remote IoT Manager) and the onboard IPA (IoT Profile Assistant) now provide the foundation for eSIM profile access, whereby the owner or operator of the eIM can instruct the IPA to connect the eSIM to a relevant profile repository to provision connectivity.

Despite high interest in SGP.32, deployments are not expected to reach significant volumes for at least another year or two: IoT devices have design lifecycles to consider, and the supporting ecosystem must also adopt the technology and ensure certification requirements are met. This means that there is a window for players to develop strategies and consider how the technology can be effectively monetised.

Emergence of the ‘eSIM Orchestrator’

IoT MNVOs are by and large carrier-neutral connectivity players; that is to say, they are not bound to a single MNO partner’s network accesses, platforms or technology. In turn, this has led many players to consider promoting themselves as ‘eSIM orchestrators.’ Orchestration is a rather overused and nebulous term, but in essence here refers to the process where, by virtue of the simpler architectural stack supporting SGP.32 provisioning and operations, relevant profiles can be downloaded to the eSIM according to a range of underlying policies and automated workflow processes. This undoubtedly opens a new revenue stream opportunity: managing this on behalf of end customers creates service wrap monetisation potential that could be based on volumes, monthly recurring fees or tied to SLA-based outcomes. So far so good: incremental margin over and above airtime connectivity resale helps solidify the business where resale margins have been consistently falling over the past decade.

The Orchestration ‘Sandwich’

As with all things in IoT, the issue is not cut-and-dried, given there are different layers to the overall orchestration solution:

• Configuration can typically be applied at the RSP platform layer, whereby logic can be applied according to eSIMs’ location, in addition to adjustments to elements such as eIM polling intervals and so on. This is largely geared towards initial configuration for eSIMs, and is unlikely to be readily accepted as an ongoing Opex cost.
• This functionality, and more, such as a broader range of SIM- and network-related events may be incorporated into the CMP (Connectivity Management Platform). The ability to ingest and act upon a rich level of data here creates a potential differentiation point for intelligent orchestration.
• The ability to act on data can be extended further by incorporating device level context, or context from other external sources. The CMP may be capable of ingesting this, thus offering a more holistic approach, while also allowing API/MCP requests for eSIM profile actions. This offers a further differentiation point, albeit with the caveat the programmatic control of connectivity will require monitoring and guardrails to prevent potential malicious activity as well as ensure connectivity continuity.

Key Considerations for eSIM Orchestration

SGP.32 has been heavily promoted as preventing the lock-in effect present during the SGP.02 era and espouses an open ecosystem for connectivity, but the reality can often be quite different.

• While some of the policy logic that orchestrates eSIM profile management can be configured in RSPs’ (Remote SIM Provisioning) platforms, for the most part, intelligence is expected to live at the Connectivity Management Platform layer. If a customer decides that they wish to move their devices to another player’s solutions, transferring that logic to the other provider is not a simple one-to-one mapping, but a project that must be carefully tested before impacting live SIMs. In some cases, functionality may not be transferrable. Here, simply offering the ‘freedom to leave’ is not enough when large device volumes are involved: players must actively support service ownership transfers.
• If an eIM change is required during the migration process, there are cost implications to consider, given that during the process of migration, the eSIM will need to be associated with 2 eIMs and thus incur additional charges. Players must consider how to handle this situation commercially and negotiate these exit terms with end customers.
• Despite baseline interoperability required under GSMA certification processes, multi-vendor interoperability between eIMs, profiles, eSIM OSs etc is not guaranteed. If eSIMs cannot work with different eIM implementations and profiles from diverse providers, ‘freedom to leave’ simply becomes a note on a slide deck. Testing, in particular with eSIMs from various suppliers, OSs and profiles is essential at this stage of ecosystem development.
• eSIM profiles will live on many different platforms and be provisioned across many different core networks. Effectively this extends the approach that many IoT MVNOs have historically taken, and requires an overlay, or Single Pane of Glass, strategy that ultimately defines how seamless the user experience is, and what sort of swivel-chair mechanics are involved where functionality cannot be translated across platforms. More complex customer requirements, such as those heavily impacted by regulations, or those with hierarchical structures and diverse billing requirements will require deeper integrations.