Adopting SGP.32 What Enterprises Need to Know

Background: eSIM and Remote SIM Provisioning

In recent years there have been some dramatics strides made in embedded SIM (eSIM) and Remote SIM Provisioning (RSP) across both hardware and software, which have culminated in the arrival of the SGP.32 ‘IoT’ standard. This section explores the evolution and its implications.

Until 2016, cellular connected devices were authenticated onto a network using a removable plastic SIM card. This wasn’t particularly appropriate for many IoT use cases, which required a more ruggedised form factor. The Machine Form Factor (MFF, now MFF2) or ‘eSIM’ was launched, comprising a chip to be soldered onto the circuit board of the device. This further evolved with the advent of iSIM in 2018, which saw the SIM application moved onto another
processor as a virtual element.

As a result of this change in the physical form factor, it was necessary to develop the capability to change the SIM profile through a mechanism other than physically swapping out SIM cards. That mechanism is Remote SIM Provisioning (RSP), i.e. remote over-the-air switching of profiles on the SIM card without needing to access it physically.

The switch to Remote SIM Provisioning has brought several major advantages for cellular based IoT connectivity. The first is supply chain efficiency. By removing the need to change SIM cards in order to localise networks, enterprises no longer need to worry about which territory the devices will end up in. The device ships to the territory and then localises onto an appropriate network when it arrives. It also simplified regulatory and commercial compliance. Some countries and operators have rules limiting the use of ‘permanent roaming‘, which can be much more easily resolved with RSP which allows the SIM to be switched to a profile that complies with local rules. The ability to switch between operators also gives buyers more options for optimising commercial relationships, providing potentially cheaper tariffs based on local connectivity, and better ability to negotiate with providers once devices are operational. Finally, it provides greater reliability and resilience, with the ability to switch networks where coverage is limited or in the event of network switch-off.

As well as the advantages, there are also a few potential drawbacks. There is a small, but not insignificant, risk that failure of IMSI switching leaves the end device without any connectivity. This was a big challenge ten years ago when our analysts were first talking about RSP, but the technology has matured to the point where it is only a very marginal risk and will happen only very rarely. Furthermore, the act of switching eSIM profiles using RSP will represent an additional drain on battery compared to sticking with a single pre-programmed IMSI or even a multi-IMSI approach. This is highly relevant for the increasing number of battery-operated IoT devices, although should be offset against the fact that profile switching might allow access to networks with stronger signals and permit access to features such as PSM and eDRX.

Overall, RSP is a very valuable tool for ensuring the compliant and seamless support for connectivity in, particularly, multi-country deployments. The benefits of having RSP capability typically significantly outweigh the costs although the appropriate choice is likely to depend on the specifics of the IoT deployment.

Key features of an SGP.32 solution

Over the past decade the mechanisms for handling Remote SIM Provisioning (RSP) have evolved quite dramatically, most notably with the introduction of a series of standards, of which SGP.32 ‘IoT’ is the latest. In this section we examine the reasons for the development of SGP.32 and the key benefits that it brings.

SGP.32 is the third of a set of standards developed by the GSM Association as architectures for eSIM Remote SIM Provisioning. Each of the three establish slightly different mechanisms for the user or owner of a device to change the SIM profile while the device is deployed in the field. The SGP.02 (or “M2M“) standard was introduced in 2014. This was followed in 2016 by SGP.22 (“Consumer”) where the end user can ‘pull’ a new profile from a chosen provider down to the device. The standard for a third variant, SGP.32 (or “IoT”) was introduced in 2023, although is currently not ratified by the GSMA, something which will not happen until late 2024 or early 2025.

The SGP.02 M2M format is a ‘push’ model whereby changes of eSIM profiles are taken from the SM-DP (Subscription Manager – Data Preparation), the profile store, and pushed to the SIM by the SM-SR (Subscription Manager – Secure Routing) element that controls the provision of the profile onto the SIM. To have full control over the SIM, the customer needs to run the SM-SR itself, although typically it is envisaged as being run by a third party such a Mobile Network Operator (MNO) and/or Subscription Management provider (typically a SIM vendor such as G+D, Kigen or Thales). The challenge with SGP.02 is that it requires cooperation between the subscription management infrastructure of the donor and the recipient networks in order to handle the handover.

In contrast, the Consumer SGP.22 form uses a ‘pull’ approach with the profile pulled directly from the SM-DP by the user, with the role of the SM-SR split between the SM-DP (or in this approach the ‘SM-DP+’) and the device itself, in the form of a Local Profile Assistant (LPA). In this scenario the ownership of the device is enough to manage the process. This approach, however, requires the device to have a more sophisticated UI and a camera (to photograph QR codes), as well as manual intervention to activate the process. This is fine for smartphones, but most IoT devices do not have any of those characteristics.

The big change with SGP.32 compared to SGP.02 is that it allows the device’s profile to be changed without requirement for integration between donor and recipient platforms.

Technical specifications of a third variant, SGP.32 (“IoT”), were finalised by the GSMA Working Group 7 in May 2023, although that is not the end of the process, for instance with testing and compliance specifications (SGP.33) only having been issued by the GSMA in May 2024. The full standard will likely be completed in late 2024 or early 2025. Device vendors expect production of SGP.32 compliant devices in 2025.

The IoT variant is really an adaptation of the Consumer SM-DP+ approach, but with four main relevant additional features:

• Remote UI – The role of the LPA is now partially on the device as the IoT Profile Assistant (IPA) and partially hosted by the network operator or third party, in the for of the eSIM IoT remote Manager (eIM) allowing for the remote control of the IP without need for manual intervention.
• Support for lightweight protocols such as CoAP-based Lightweight M2M (LwM2M)profile downloads and other operations – SGP.32 does not require support for TCP/IP, which is heavier than the UDP used in CoAP, and LwM2M that runs over it. This helps to overcome constraints on latency and bandwidth which are common with newer IoT connectivity technologies, particularly NB-IoT.
• No requirement for SMS – NB-IoT devices often don’t support SMS, which was required for SGP.22.
• A small footprint – Because much of the functionality of the LPA has been moved into the eIM it reduces the memory and processing requirements on the device itself.

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 is that it allows the device’s profile to be changed 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 a customer 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, as discussed in the next section.

A much-needed reality check

The other downside is that the negotiating power of that single customer for relatively small numbers of connections in each market will be limited compared to an MNO relying on reciprocal roaming agreements, or MVNOs with much larger volumes of devices within any given market. The alternative is to have a third party to act on their behalf, as part of a managed service. We expect that most IoT buyers would need the process to operate in this way, which means the commercial dynamics will be quite similar to those currently seen between enterprise customers and MNOs/MVNOs today.

It’s not just as simple as switching eSIM profile

A further major constraint is that even where a user might have commercial relationships with multiple network operators it’s not simply a case of switching between providers seamlessly. The way in which connections are supported will vary depending on the network used and many settings will not be specified by the standard and will therefore not automatically carry over from one network to another, for instance for blocking or unblocking connections. There will also be a requirement for back-end integration and other process changes, for instance to change APN settings, set the polling frequency for new eSIM profiles, or manage device security. Any changes to the eSIM profile will need to occur contemporaneously with a switch of those other elements of the deployment. This is a non-trivial task. It will not be as simple as the end customer having the ability to switch SIM profiles on its devices at the click of a button.

What is required for SGP.32 to work optimally is a further abstraction and orchestration layer between the networks and the enterprise, handling all those other elements beyond the consideration of which eSIM profile is active on the device. That capability corresponds closely to the kind of capabilities required to handle the managed transition to SGP.32 as noted in the previous section.

How much can you actually save?

The cost of cellular-based IoT connectivity has been gradually declining over the last decade, to the point where we at Transforma Insights talk about ‘$1 IoT’, i.e. that there will be large numbers of connections generating $1 per year in connectivity revenue. With such highly competitive connectivity pricing, there is diminishing return from being able to shave a few cents off the cost of connectivity by switching between connectivity providers. That is particularly the case when put into the context of the inherent costs of making those profile changes, both explicit as the RSP fee that might be charged directly by whoever provides the service, and less directly in terms of back-end integration overhead, or at the most extreme the risk of losing some connections, however small that risk might be.

Mostly an insurance policy

At this point we should consider whether existing deployments of other forms of remote SIM provisioning show us anything about how it may be used. SGP.22 has proved a great success in reality, specifically in the handset market, although not really in any volume for IoT. SGP.02 has been very useful in certain limited circumstances, i.e. as an insurance policy or as a mechanism for initial profile allocations. Car makers, for instance, have demanded it (or pre-standard versions of it) for their very large deployments, for both reasons. What has not really materialised is many major IoT users shifting between carriers for commercial reasons.

Both of those use cases also apply to SGP.32, with support for initial profile allocation and to act as an insurance policy. Because of the additional logistics overhead of managing back-end changes and negotiating country-by-country connectivity deals, it’s not clear that SGP.32 is much differentiated from SGP.02 in enterprise customers wanting to use it to switch more frequently, for instance for commercial reasons. Of course they have the capacity to do it, but they also have the capacity to do it in SGP.02 as well, but the greater freedom of SGP.32 probably won’t result in significantly greater frequency of switching.

What is required for SGP.32 to work optimally is a further abstraction and orchestration layer between the networks and the enterprise.

Hear from Matt Hatton, Founding Partner at Transforma Insights and find out everything you need to know about SGP.32. Listen now.

SGP.32 as part of a portfolio of managed connectivity

Many enterprises have identified SGP.32 as a potentially highly useful technology. They are asking Transforma Insights about it, and they are also asking MNOs/MVNOs. Quite a large number of companies clearly see it as some sort of magic wand for solving their connectivity needs and a big change from the existing processes

Some enterprises clearly have identified that SGP.32 will provide them with a completely seamless carrier-agnostic connectivity opportunity, whereas the reality is that either an alternative option may prove better, or SGP.32 requires more complexity to realise than many would have expected.

As such we strongly suggest that SGP.32 will be provided as a managed service by a connectivity provider able to provide the transition, orchestration, and MNO management functions that we note in the previous section.

Can’t I, as an enterprise, do this myself?

In comparison with SGP.02, SGP.32 certainly hands more control to enterprises for managing their IoT connectivity. However, it’s unlikely to be the radical shift that some might envisage. They will need to either operate their own SM-DP+ and eIM or engage with a third party to do it for them. That creates an alternative dependency away from the carrier relationship, but a dependency nonetheless.

Much of the motivation behind the development of SGP.32 is to put more control into the hands of enterprise users to manage SIM profiles in the way that consumers individually do in SGP.22. The question is whether most enterprises will want to, or be able to, perform all of the functions. The truth is that most companies will not want to operate an SM-DP+ and eSIM functionality themselves, particularly in terms of managing all the back-end integration, settings, and processes. Neither will they want to handle negotiating commercial contracts with multiple connectivity providers. In almost all cases—exceptions would be very large enterprise customers, such as automotive—most would not want to.

So, by definition, for the vast majority of IoT adopters, SGP.32 will need to be provided as a managed service.

SGP.32 will be a managed service

We don’t expect that most OEMs or enterprises would actually want to run the infrastructure required for SGP.32 themselves. They would want it provided by a third party, either an EUM or some other connectivity provider as a managed service. In the former case, there is a scenario where the OEM or enterprise might choose to effectively operate as their own ‘managed eIM provider,’ handling switching between carriers, and as a necessary part of that, also the negotiation of contracts with those MNOs/MVNOs. In so doing, the OEMs/enterprises are effectively setting themselves up as MVNOs, which is not a role that most have shown interest in doing until now. OEMs and enterprises will benefit from the increased flexibility of SGP.32, but the vast majority will favour doing so via a third party which handles the heavy lifting of negotiating contracts and managing connectivity. And, notably, will likely be in a better position to negotiate favourable rates.

It is apparent that the functionality of SGP.32 will need to be provided within a protected environment handling orchestration of the whole SIM lifecycle management.

What does a managed SGP.32 provider look like?

As noted in the previous section, SGP.32 needs to be provided as a managed service, which begs the question: What is the profile of a managed SGP.32 provider? In this section, we consider the key elements enterprises should look for in a connectivity provider to support them in using SGP.32.

Support for SGP.32

This is, of course, a given, operating the SM-DP+ and eIM infrastructure necessary for supporting SGP.32. A cellular-based IoT connectivity provider will need to have SGP.32 as part of a portfolio of offerings. 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

In many cases, SGP.32 alone may not be the most appropriate option for an IoT deployment. Buyers of IoT connectivity need to be confident that their provider will be able to provide a seamless transition from one technology capability to another (e.g., SGP.02 to SGP.32) and support their deployments as required. These include the likes of single country IMSI, roaming SIMs, multi-IMSI, and SGP.02. The key is not the specifics of the technology, but having as wide a range of options as possible to choose from that supports each step of their IoT journey.

An orchestration capability

Making use of SGP.32 is not as simple as just switching the eSIM profile on the SIM. As well as the pure eSIM management function, the connectivity provider will need to offer the orchestration of all the other elements of supporting the user’s IoT connections, including managing data flows, device middleware, security, and compliance

A roadmap for migration

Given that SGP.32 is not truly available for deployments today or for the next year at least, connectivity providers need, in addition to other options for support, a roadmap for migrating customers from an alternative onto the SGP.32 standard. While this might involve the use of pre-standard SGP.32 variants, we don’t generally recommend them, for reasons noted above. Therefore, for a standards-based approach, it will typically involve supporting via SGP.02 and migrating from there. Or it may involve using other alternatives such as roaming SIMs or multi-IMSI.

Conclusion: find a partner

Transforma Insights recommends that, rather than selecting a specific technology (in this case SGP.32) and trying to do it yourself imagining that it’s a magic wand, instead work with established connectivity providers with a wide range of options which might be appropriate.

Conclusions and recommendations

SGP.32 is a technology with a lot of promise. It is also another example of a technology that has grabbed the headlines and appears to be a universal panacea, providing enterprise customers with the ultimate control over connectivity and the ability to seamlessly shuffle between operators as the mood takes them. The truth is that using this technology is rather more complex than billed and less of a radical departure from existing alternatives than might be supposed based on some of the claims that we see.

There are some circumstances in which SGP.32 clearly presents benefits, most obviously where low-power connectivity is being deployed and/or where constrained messaging protocols are used. There, the availability of SGP.32 allows for remote SIM provisioning where otherwise it would not have been possible. In other circumstances, there are strong opportunities too, for instance consumer device OEMs managing fleets of devices and supporting enterprise IoT as a managed service. However, we should always sound a note of caution that in many cases, SGP.32 will not offer any particularly noticeable benefits versus the other standards or permutations of multi-IMSI, roaming, and other approaches.

Transforma Insights makes the following conclusions and recommendations relating to enterprises and how they deploy IoT:

1. For some use cases, SGP.32 represents the only RSP option and will therefore be very valuable and widely used. SGP.32 opens up opportunities for using remote SIM provisioning for highly constrained devices that don’t have SMS capabilities and/or make use of constrained protocols such as CoAP.
2. MNOs and MVNOs will almost universally support SGP.32, eventually. Many enterprises and OEMs will opt to integrate IPAs into their devices, so support by connectivity providers is not optional. Every connectivity provider should have the functionality available and be able to take enterprises on a journey to SGP.32.
3. The SGP.32 capability will be available from 2025. Any nominally SGP.32 solution today is not based on fully interoperable standards.
4. The pre-standard versions will only be of limited appeal. MNOs will demand standards, as will many enterprise customers. There are learnings that can come from implementing pre-standard versions, but mass adoption depends on standards.
5. SGP.32 will generally have to be offered as a managed service as part of a portfolio of offerings. Very few enterprise customers will have the inclination to try to manage the functionality of SGP.32 themselves. Therefore, the SGP.32 functionality will be accessed via an orchestration layer provided by connectivity providers. It will most obviously be offered as part of a range of options that also includes roaming, multi-IMSI, and SGP.02.
6. A roadmap to SGP.32 is required for implementations today. Because the technology itself is not available for deployment until 2025, potential users will want to make use of an alternative (such as SGP.02) until such time as SGP.32 is available and will need to rely on a connectivity provider to provide a seamless migration.
7. In all cases, whether SGP.32 or otherwise, we maintain the view that remote SIM provisioning is focused predominantly on initial localisation and as an insurance policy. For many deployments, late provisioning of SIM profiles is a necessity for logistical reasons. In most others, it exists as a way to ensure connectivity in the event that the lead carrier’s connectivity is not available or where the carrier can no longer provide the service, or there is an irretrievable breakdown in the commercial relationship between the customer and the carrier.
8. Don’t put the cart before the horse. You want a device connected in as interoperable and future-proofed a way as possible. It’s not about selecting a specific technology. For some companies, developing an internal SGP.32 capability may be the correct answer, but it won’t be for most. The optimum approach is typically to select a provider that can offer it as part of a broader portfolio of offerings.

There are some circumstances in which SGP.32 clearly presents some benefits, most obviously where low power connectivity is being deployed."