Skip to content

SGP.32 Remote SIM Provisioning: why it needs to be delivered as a managed service

June 12, 2024
SGP.32 Remote SIM Provisioning: why it needs to be delivered as a managed service

The SGP.32 (“IoT”) standard for Remote SIM Provisioning, unveiled by the GSM Association in May 2023, offers a more streamlined and user-friendly mechanism for enterprises to manage connectivity on their cellular devices. Building on the earlier SGP.02 (“M2M”) and SGP.22 (“Consumer”) standards, it addresses many technical limitations in supporting constrained devices and simplifies the process of switching connections between operators. However, a recent Position Paper from Transforma Insights, ‘Key considerations for Enterprises looking to adopt SGP.32’  identifies several key challenges with the technology with implications for how it will be most optimally deployed.

More (potential) control for the enterprise

SGP.32 solves some of the problems with earlier standards. In doing so it effectively adapts the SGP.22 approach to be managed remotely. Instead of a Local Profile Assistant (LPA), which the user would use directly to initiate profile changes, it incorporates an IoT Profile Assistant (IPA) sitting on the device, being controlled by an eSIM IoT remote Manager (eIM) which is hosted by a network operator or other third party. Using this IPA/eIM, the customer (or someone acting on their behalf) would be able to pull a profile from any MNO/MVNO (assuming that operator agrees).

The big change with SGP.32 compared to SGP.02, which would be the main alternative standard for enterprise IoT deployments, is that it allows the device’s profile to be changed remotely without requirement for integration between donor and recipient platforms (something which is required by SGP.02) or the agreement of the current provider. This is a fundamental change. SGP.32 allows an enterprise to switch its IoT connections (theoretically) to any connectivity provider it chooses without recourse to the operator upon whose SM-SR it resides.

Nominally this change means that every enterprise customer with SGP.32-capable devices is dramatically more footloose than they were previously, with the ability to ‘at the click of a button’ move some or all their connections from one network to another.

However, the reality is much more complicated.

The need for a managed transition to SGP.32

The first challenge is timing. Although the technology itself has been standardised, SGP.32 will not be truly available until 2025. The functional test specification (SGP.33) only just been unveiled, which is required for device certification. Furthermore there is no hardware in production that supports the IPA. We may see a small number of standards-based devices in 2024, but realistically they won’t be in volume until 2025. And we can add in lead time on then getting a product into market, meaning that it could easily be 2027 before a buyer can get an SGP.32-compliant product into market. 

Any company wanting to avail themselves of the superior functionality delivered by that technology will either need to wait or will need to find a connectivity provider that can support their connectivity requirements using an alternative approach (e.g. multi-IMSI or SGP.02) today, with support for transition to SGP.32 at the appropriate time.

There are, of course, numerous options that act as alternatives, albeit with some limitations. It is not in doubt that every connectivity provider can provide some sort of alternative. The challenge will be in finding one that can handle a managed transition to SGP.32 when the time comes. For instance, the optimum solution would involve a common management portal with the same functionality and/or a common set of APIs, so that there is effectively little difference to the experience delivered to the enterprise regardless of which approach is being used.

Commercial challenges

There are also several commercial challenges associated with the technology that will influence its optimal deployment. To switch connectivity providers, an enterprise needs an alternative network willing to accept the connection. This requires a commercial relationship between the network operator and the SIM owner. With SGP.32, the enterprise (or a representative) must establish this commercial relationship before moving the connections.

This requirement limits the technology’s appeal to customers with relationships with multiple carriers, such as car manufacturers or other large buyers. For smaller customers or those connecting devices in multiple countries, managing numerous connectivity contracts can be a significant logistical challenge. Additionally, a single customer with relatively few connections in each market has limited negotiating power compared to a mobile network operator (MNO) relying on reciprocal roaming agreements or mobile virtual network operators (MVNOs) with larger volumes of connections in any given market.

An alternative is to use a third party to manage the process as part of a managed service. Most IoT buyers will likely need to operate this way, resulting in commercial dynamics similar to those currently seen between enterprise customers and MNOs/MVNOs.

More than just the ‘push of a button’

An additional limitation is that even with commercial relationships with multiple network operators, switching between providers is not seamless. The eSIM profile is not the only thing that would need to change. Other examples include pre-established blocking or unblocking of connections, APN settings, and device security. Changes to the eSIM profile must occur simultaneously with these adjustments, making it a complex task. Switching SIM profiles on devices is not as simple as clicking a button.

For SGP.32 to work optimally, an additional abstraction and orchestration layer is needed between networks and enterprises to manage these elements beyond just the active eSIM profile. This capability aligns with the requirements for a managed transition to SGP.32 as noted earlier.

SGP.32 as a managed service

For the reasons stated above, we do not expect that most OEMs or enterprises would want to manage SGP.32 themselves. As such we expect it to be provided as a managed service, which begs the question: what is the profile of a managed SGP.32 provider? Transforma Insights has identified four key attributes that enterprises should look for in a provider:

  • Support for SGP.32. This is, of course, a given, operating the SM-DP+ and eIM infrastructure necessary for supporting SGP.32. In many cases it will be the most appropriate mechanism for supporting connectivity, particularly for multi-country deployments. We expect it to become the de facto standard for remote SIM provisioning.
  • A continuum of capabilities – Buyers of IoT connectivity need to be confident that their provider can offer all of the appropriate options, of which SGP.32 will likely be one, alongside roaming SIMs, multi-IMSI and SGP.02.
  • A roadmap for migration – Connectivity providers need a roadmap for migrating customers from an alternative onto the SGP.32 standard for any deployments in the near future, supported by common platforms and processes to make the process as seamless as possible.
  • An orchestration capability – As well as the pure eSIM management function the connectivity provider will need to offer the orchestration of all of the other elements of supporting the user’s IoT connections, including managing data flows, device middleware, security and compliance.

Conclusion: good, but not a magic wand

SGP.32 is a technology with a lot of promise. It is also another example of a technology which has grabbed the headlines and appears to be a universal panacea, providing enterprise customers with the ultimate in control over connectivity and the ability to seamlessly shuffle between operators as the mood takes them. There are some circumstances in which SGP.32 clearly presents some benefits but it is not always going to be the optimum choice. Furthermore, given the complexity outlined above we expect few enterprise customers will have the inclination to try to manage the functionality of SGP.32 themselves. Therefore the SGP.32 functionality will be provided as a managed service alongside other (potentially more appropriate) alternatives, with a roadmap for transition, and accessed via an orchestration layer which handles the other complexities of switching between operators beyond just switching the eSIM profile.

Check out the Position Paper to learn more

The article above is a short summary of some of the key messages from the report. In the full Position Paper ‘Key considerations for Enterprises looking to adopt SGP.32’, sponsored by Eseye, we explore in more depth the characteristics and capabilities of SGP.32, further expand on the reality of how it can be used, and identify the key capabilities of a provider of SGP.32 services.

Article by Matt Hatton, a founding partner at Transforma Insight

Comment on this article via X: @IoTNow_