How CSL delivers eSIM management together with rSIM resilience

Combining eSIM orchestration with local resilience

CSL Group announced the acquisition of IoTM Solutions Ltd on 13 July 2026, bringing eSIM management together with CSL’s patented rSIM® resilience in one managed-service proposition. This combination is increasingly important for distributed IoT estates, where remote profile management can provide the flexibility to change connectivity as operational, commercial and regulatory requirements evolve. That flexibility, however, does not by itself provide a local response when the active communications path to a device becomes unavailable. CSL addresses this by combining remote profile management and connectivity orchestration with the local, SIM-level resilience that rSIM delivers, providing complementary capabilities within one managed-service proposition.

This distinction becomes more important as connected assets remain in service for years while their locations, mobile operator contracts and surrounding network conditions change. A distributed estate needs a remote way to prepare, manage and change connectivity throughout that lifecycle. It may also need a local way to respond when the active path stops working, such as during a local network failure or a wider mobile core outage affecting multiple devices.

The GSMA SGP.32 specification provides the architecture for remote profile provisioning and management, while the CSL IoTM platform coordinates the operational workflows around profile and connectivity management. Within this combined solution, rSIM provides the local resilience capability: its SIM-resident logic can select an alternative profile already present on the SIM when the active connectivity path remains unavailable under the configured switching policy.

CSL therefore combines the flexibility of multi-operator eSIM orchestration with local, SIM-level resilience. The CSL IoTM platform prepares and manages profiles across devices, operators, platforms and countries throughout the life of an estate. rSIM acts locally when the active path fails, selecting between the profiles available on the SIM without requiring the remote management platform to reach the device at that moment.

Over the life of the estate	During a connectivity incident
Management and orchestration prepare, download, enable, disable and govern profiles across devices, providers and countries.	SIM-resident logic tests the active path and can select the alternative profile after a configured period of sustained failure.

Remote orchestration requires a usable communications path to the device. If the active path becomes unavailable, the rSIM switching decision is made locally using logic and policies already present on the SIM, without requiring the eIM or remote management platform to reach the device at that moment.

Six terms that make the eSIM architecture understandable

The term eSIM is often used broadly to describe several related elements of remote SIM provisioning. The architecture and delivery model become clearer when the principal components are considered separately.

Term	What it does
eSIM	The technology that allows mobile network subscriptions to be provisioned and managed digitally, rather than being permanently tied to a pre-programmed SIM. In GSMA terminology, the eUICC is the physical secure SIM component.
eUICC	The secure SIM hardware and software that can store and manage one or more operator profiles. It can be soldered into a device or supplied in a removable form.
Profile	The operator subscription data and security credentials that allow a device to authenticate to a mobile network.
SM-DP+	The Subscription Manager Data Preparation Plus server. It prepares, protects and delivers a profile package for a specific eUICC.
eIM	The eSIM IoT Remote Manager introduced by the SGP.31/32 architecture. It can initiate profile downloads and profile-state changes for an IoT fleet.
IPA	The IoT Profile Assistant. It performs the device-side work needed to exchange instructions and profile data with the eUICC and remote systems, and it can be implemented in the device or within the eUICC.

A key point is that the eIM does not create the mobile subscription. The operator subscription is represented by a profile prepared and delivered through an SM-DP+. The eIM coordinates supported profile-management operations, while the IPA and eUICC perform the relevant device-side work. An enterprise management platform can integrate these operations with mobile operator and connectivity-management workflows.

What SGP.32 changes for IoT connectivity

The GSMA, the industry body representing mobile operators worldwide, publishes the architecture and technical specifications for remote eSIM provisioning and management in IoT devices. SGP.31 defines the eSIM IoT architecture and requirements, while SGP.32 provides the associated technical specification. Both are currently at version 1.3. The specifications are dated 22 May 2026 and were published on the GSMA website on 28 May 2026^1,2.

These architectures and specifications are intended for IoT devices that may have no user interface, limited power or restricted network access. This differs from the consumer model, in which a user can scan a code and approve a profile on a phone. A device with no screen, a limited battery and nobody on site to approve a profile instead needs the fleet owner’s systems to manage the process.

SGP.32 meets these needs through the eIM and IPA roles. Together they provide standardised ways to trigger a profile download and to enable, disable or delete profiles. The technical specification also defines the interfaces and security exchanges among the eIM, IPA, eUICC and SM-DP+.

The GSMA specifications, however, do not choose the mobile operator, manage the commercial contract or guarantee end-to-end IoT service continuity. An eSIM deployment at scale must therefore identify the devices, products, versions, supported functions and organisations involved, because each can affect interoperability, operational control and long-term support.

What CSL delivers: IoT SIM and eSIM orchestration

The CSL IoTM platform combines CSL’s managed Critical Connectivity^® services with IoTM’s connectivity and eSIM orchestration capabilities. It provides a unified, vendor-agnostic management layer for global IoT connectivity, enabling customers to manage physical SIMs, eSIM profiles, mobile operators and platform integrations through a consistent operating model. Customers can procure managed IoT connectivity from CSL or bring connectivity supplied by their existing mobile operators. Depending on the deployment, CSL can also provide eIM services or integrate with a customer-selected eIM. The platform operates as a management and orchestration layer across supported mobile operator portals, connectivity management platforms, remote SIM provisioning systems and eIMs. This gives customers greater supplier choice without requiring them to manage each system through a separate workflow. Depending on the deployment, the service can include:

Managed IoT connectivity
Management of customer-provided connectivity
Management of the profiles available to rSIM
eSIM Fleet Management (eIM) Services and Integration
Connectivity and eSIM service orchestration
Connectivity platform services

It is important to recognise that remote profile provisioning and connectivity-management workflows need to be coordinated to deliver the intended working connection. For example, a profile-management action may complete while the corresponding subscription remains inactive on the operator’s connectivity management platform. An activation code may also be reused accidentally, causing a later attempt to fail. Either issue can leave the device without the intended working connection.

To overcome these issues, the CSL IoTM platform coordinates profile-management actions with the related connectivity actions^3,4,5. Its capabilities include:

Unified connectivity management platform (CMP) and remote SIM provisioning (RSP) workflows, enabling profile actions to be coordinated with subscription activation and rate-plan changes.
eSIM fleet management across mobile operators, CMPs and RSP providers, including profile download, enable, disable and delete, together with management of eIM configuration and polling parameters where supported by the relevant standard, product and integration.
Activation-code inventory management for automated and batched profile downloads.
Policy-driven localisation, using rules such as device location, time spent within a defined geography or usage thresholds to determine when a local or regional profile should be activated.
Closed-loop localisation workflows, verifying that profile changes have completed successfully, recording the actions taken and enabling recovery or rollback where required.
Integration across mobile operators, CMPs and eSIM-management providers, enabling localisation and profile-management workflows to operate across multiple supplier ecosystems rather than being tied to a single provider.

Where rSIM fits

Within CSL’s managed connectivity solution, rSIM technology provides the local resilience layer that complements the profile management and orchestration delivered through the CSL IoTM platform. It holds two distinct multi-network roaming profiles and uses SIM-resident logic to test the active connectivity path. After a configured period of sustained failure, the logic can select the alternative profile, enabling the device to attempt to reconnect using the alternative mobile profile. The SIM can later return to the primary profile under its configured policy⁶.

Because the profiles and switching policy are already present on the SIM, the local switching decision does not require the eIM or CSL IoTM platform to reach the device when the active path fails. rSIM selects between the profiles already available on the SIM rather than downloading a new profile during the outage.

Learn more about rSIM

Question	Management and orchestration	rSIM technology
When does it act?	During deployment and throughout the estate’s life.	During a connectivity incident, under the configured local policy.
What does it change?	The profile estate, subscriptions, policies and records across remote systems.	Which of the two profiles already on the SIM is selected.
What must be reachable?	The relevant remote systems and a usable path to the device.	The switching decision is made locally by the SIM-resident logic. Reconnection requires the device modem and an available alternative mobile path.
What is its principal role?	Preparing, managing and governing connectivity across the estate throughout its lifecycle.	Providing a local response when the active mobile connectivity path remains unavailable under the configured switching policy.

The CSL IoTM platform and rSIM work together throughout the connectivity lifecycle. The platform prepares and manages the available profiles across the estate, while rSIM can select the alternative profile locally if the active path remains unavailable. Once remote contact is restored, the management layer can record the event and support any required changes to the profile estate or switching policy.

Together, these capabilities strengthen connectivity resilience across the estate. As with any critical IoT deployment, the complete service should be designed and validated across the relevant dependencies, including radio coverage, power, the modem, the device, mobile-core and routing infrastructure, backhaul, remote platforms and the application. Testing both profiles and the application’s recovery behaviour helps confirm that the overall solution performs as intended for the IoT use case.

Changing eIM provider

An important capability of the SGP.32 architecture is the ability to change which eIM is authorised to manage an eUICC. This separates the choice of eUICC from the organisation or platform that manages it throughout its life.

For example, an eUICC may initially be supplied with an eIM operated by a mobile operator or eSIM provider. At a later point, the customer may choose to bring management of that eUICC under its own eIM, or under an eIM operated by another service provider. Alternatively, the original provider’s eIM could remain in place and be integrated into the customer’s chosen eSIM-management platform.

SGP.32 supports the remote addition, update and removal of eIM associations. Where an eUICC already has an associated eIM, changes to its eIM configuration are authorised by an existing associated eIM. A new eIM can therefore be added before the previous eIM is removed, allowing management responsibility to be transferred remotely without replacing the physical eUICC.

This creates an important commercial and operational choice for IoT deployments. Rather than operating a separate eIM relationship for every mobile operator or eUICC supplier, an organisation may choose to consolidate management of compatible eUICCs through a single eIM and fleet-management platform. This can simplify integrations and operations and, depending on the commercial model, reduce the cost of managing the estate.

However, support for SGP.32 should not on its own be taken to mean that an eIM can always be changed freely. The available migration route depends on the eUICC and IPA implementation, the eIM associations already established, and which organisations hold the necessary authority and credentials. Some recovery mechanisms, including resetting eIM configuration, are also optional capabilities.

A deployment and exit plan should therefore establish who controls the eIM associations and supporting credentials, whether another eIM can be added remotely, and what cooperation is required from the existing provider. These capabilities should be tested before deployment where future provider portability or consolidation of eSIM fleet management is a requirement.

What an enterprise buyer should specify and verify

The buyer does not need to reproduce the standard in a tender. The tender and deployment specification should identify the named roles, products and integrations, together with the evidence and testing needed to confirm that they operate together as intended.

Architecture and roles. Name the eUICC, IPA, SM-DP+, eIM, CMP, mobile operators and the organisation responsible for each.
Standards status. Record the SGP.31/32 versions, supported functions, integration status and evidence for the exact products being supplied. Include how many eIM associations the eUICC supports and which optional functions the IPA implements.
Profile operations. Test profile download, enable, disable and delete operations together with any corresponding subscription, activation or rate-plan changes.
Localisation controls. Set the location, dwell-time or usage rules; define approval, rollback, exception handling and audit access.
Resilience design. Identify both rSIM profiles, their mobile-core and routing dependencies, the test interval, failure threshold and return policy.
Acceptance testing. Test the estate through loss of each material dependency, including the switching window and application recovery above the connectivity layer.
Control and exit. State who owns the profiles, activation codes, eIM associations, logs and API access, and how a supplier change will be completed.

Applying these requirements gives the buyer a clear basis for assigning each role, testing the required operations and documenting the agreed route for future supplier changes.

Plan connectivity management and resilience together

For help designing an IoT connectivity solution that brings together profile management, multi-operator orchestration and local resilience, contact CSL at sales@csl-group.com.

Contact us