GSMA’s SGP.32 for eSIM IoT might be the youngest standard but it was developed with unprecedented maturity, dialectically from the learnings of previous eSIM standards. Right now, anyone interested in IoT has their antennae tuned to the eSIM IoT implementation, and with that interest come a lot of questions.
There’s no better starting point to answer these questions than the creation of the specification itself. And the best person to narrate why and how the SGP.32 specification came to be is Saïd Gharout, Chair of the SGP.32 working group and VP Standardization at Kigen.
We sat down with Saïd and asked him to lift the curtain on the working group meetings. His answers are generous with clarity on what eSIM IoT is intended to do, what use cases it covers, what were the non-negotiables, and where should the industry go from here.
Retrospective and action points: Learning from previous eSIM standards
The working group didn’t emerge in a vacuum. Saïd explains that SGP.32 was born in direct dialogue with previous eSIM standards: SGP.02 for M2M and SGP.22 for consumer devices.
“The working group started in 2019 to draft eSIM specifications for IoT. It started because some companies argued we need something simpler for IoT devices, but we quickly noticed that the word IoT has different definitions for MNOs and OEMs. Aligning these perspectives took its time. So we decided to create an autonomous, dedicated working group to draft the requirements and technical specifications. The key to success in standards is to design something comprehensive without it being complex. For SGP.32, the focus was on interoperability and simplicity without compromising the main function of the eUICC: security.”
This collaborative foundation led to SGP.32 becoming the first truly neutral standard in the eSIM space. Saïd clarifies what made this different:
“The whole industry participated to draft the requirements and the use cases. In deliberations of prior eSIM standards, it was a few players that had the largest share of voice informing them. The SGP.32 working group had active participants from the whole industry.”
Problem definition: Can IoT use cases fit into two categories?
The process was methodical. Every participant contributed their most important use case and explained why previous standards weren’t working for it. A pattern emerged.
“Most of these use cases were targeting devices with constraints related to either network, energy, battery, or computing. There were also devices which are not easily physically accessible to an end user. For the sake of the simplicity requirement, we agreed to target two device categories,” Saïd explains.
The first category: network-constrained devices.
“In these cases, the existing standards could not simply be applied to LPWAN. As a result, the need for lightweight protocols came to the forefront as a requirement. A subsequent requirement was to maintain the same security level for the components and the communication between the components alike.”
The second category: user interface-constrained devices.
“In these cases, the devices have no user interface, thus making the implementation of SGP.22 impossible. The requirement that arose for this category was remote control.”
Must-have requirements: Simplicity and reused infrastructure
Simplicity emerged as a non-negotiable for everyone, MNOs and OEMs alike. Saïd emphasizes:
“The integration for IoT devices must not be complex—any additional complexity delays deployment and has direct cost implications on the device bill of materials and IoT projects alike.”
But the group was also pragmatic about what was already working. The SM-DP+, initially developed for SGP.22 and integrated into operators’ IT systems, had proven its value. Saïd tells us how the conversation went:
“The new solution shall not impact the existing SM-DP+. We agreed to minimize the impact on MNOs who already invested a lot of time to deploy an eSIM infrastructure using the SM-DP+. Any major change on SM-DP+ would simply delay the deployment of the eSIM IoT standard.“
So what did the final minutiae show as final requirements? Saïd outlines the brief: a Remote SIM Provisioning solution for IoT Devices that:
- does not increase complexity,
- reduces the deployment effort for IoT device makers,
- reuses parts of eSIM consumer –SM-DP+– that were both labor-intensive and effective.
Fleshing out the solution: Enter eIM
To fulfill the simplicity requirement and bridge both categories of network-constrained and user interface-constrained devices, the group decided to create an open component to manage complexity outside the traditional device-network boundary. The solution was the introduction of a remote management entity: the eIM (eSIM IoT Manager).
Saïd recalls that once the use case categories were outlined, the need for remote management became obvious. The more contentious discussion centered on security — the very purpose of SIM technology.
The question arose: Is it more secure to execute commands in the device or the eUICC? Moving security responsibilities to the device would increase complexity in device operations and complicate security certification processes. Saïd explains:
“The most difficult part was the trust that we could have in an IoT device. Do we consider the device very secure or less secure? We spent a lot of time discussing this point. Will the eIM send the management commands to the device, and then the device sends it to the eUICC? Or could the device change this command in case it’s compromised? How much can we consider the device secure? At the end, we concluded that the solution shall not only rely on device security. It shall be end-to-end secure between the eIM and the eUICC, as these both entities will be security evaluated.”
eIM: Security, simplicity, interoperability
The eIM addresses all three requirements that emerged in the SGP.32 working group. The eIM is a component that handles remote profile state management operations for eSIM IoT devices. It enables the remote enabling, disabling, deletion, and downloading of profiles on eUICCs, all of which are standardized by the GSMA. In essence, the job of the eIM is to make Remote SIM Provisioning for IoT secure, simple, and interoperable.
Saïd walks us through the elaboration, starting with security:
“As we defined the eIM, we then agreed that management operations will come from the eIM, then the IoT device will just play a store-and-forward role to transfer eIM commands to the eUICC securely. Once this concept was agreed, it was then easy for the experts to specify the end-to-end secure protocol between the eIM and the eUICC. All the communication between eIM and eUICC is protected. And if there is additional complexity that is outside the eUICC, then the eIM will implement it.”
On interoperability and simplicity, the working group was responding directly to market pain points. Saïd contrasts the approaches with the previous standards:
“In M2M, vendor lock-in was really criticized for being expensive. And even for some decisions, you need to involve the operator and all of this. The MNO is also in charge of changing the fallback profile. In SGP.32, the eIM assumes that role. The command is initiated by the eSIM owner or user (enterprise), and it is profile-centric. The eIM is eUICC-centric, which means it’s not up to any MNO to decide what the fallback profile will be. What they can do is just say, I accept to be the fallback.“
​​The specification goes further, documenting every interaction to prevent proprietary capture and ensuring simplicity at the same time.
“In SGP.32, we really specified the eIM operations, meaning that the process of when you add a new eIM, when you remove an eIM, when you update an eIM from the eUICC, are all fully outlined in the specification, which means that it’s not under vendor lock. The complexity between the SM-DP+ and the IoT device today is absorbed by the eIM.”
The working group also discussed communication protocols through the lens of a simple implementation. IoT devices already support various protocols, and adding new ones risks increased complexity. Saïd describes the approach:
“The eUICC integrates with the underlying transmission protocol of the device, and the device integrates with the eIM to receive the package. Whatever the transport protocol you use, the data structure is always the same when it arrives at the eUICC or the eIM. So the addition was the supported protocol, which carries the communication between the eIM and the device. This way, it’s up to the IoT device makers to support what they want and outsource the rest to the eIM.”
Sign up to our eSIM IoT email course
Get a firm grasp on SGP.32 and how to approach – in 5-minute reads, straight in your inbox!
Bringing SGP.32 to life: Interoperability in practice
The industry has proven security concepts, and the focus on simplicity is evident across the standard. But how does the industry ensure interoperability in a space as historically inflexible as telecom? We asked Saïd directly.
“I think what we need to do is what we call interoperability events, where the vendors can come around the table, then everybody can test with other players. And the good point is that eSIM IoT is an open standard, which means your company could develop only the eIM, and you could develop only the eUICC or the IoT device, and you could interact with everybody. Usually, GSMA has defined and organized this in the past, but I think now we have something to do for this within the IoT ecosystem.”
Bee Hayes-Thakore, VP of Marketing at Kigen and long-time colleague of Saïd, reflects on the years of deliberative work:
“I’ve had a very privileged opportunity to see how Saïd has taken this work across many years. It’s about being comprehensive without being complex. And I think that’s a very delicate and very intensive, deliberative effort. It’s also incredibly collaborative.”
Saïd himself sees even more potential ahead: “I think we can do so much with the eSIM IoT specification. I see a lot of potential for the eIM.”
SGP.32 and the responsibility of the industry
SGP.32 stands on three pillars: security, simplicity, and interoperability. The standard itself, through rigorous specification and testing requirements, ensures the first two. Security is built into the architecture through end-to-end protection between eIM and eUICC. Simplicity is achieved by absorbing complexity into the eIM while keeping device integration straightforward. But interoperability, perhaps the most transformative promise of SGP.32, is up to the entire IoT ecosystem.
Evidenced by Saïd’s words, SGP.32 provides the most thorough and market-grounded standardized foundation to date: open documentation, vendor-neutral architecture, and clearly defined interfaces. Now, Saïd concludes, it’s up to device makers, eUICC manufacturers, eIM providers, and connectivity providers to come together, test across platforms, and validate that the promise of an open, flexible IoT connectivity market becomes reality.
The standard is comprehensive. The testing framework is thorough. The next chapter belongs to the industry as a whole; to prove that interoperability can be a living practice in IoT and deliver on the insurance and flexibility that caught the market’s attention.
