Why these standards matter

Remote SIM provisioning sounds simple enough: instead of physically replacing a SIM card, you manage network profiles over the air.

That flexibility is one of the reasons eSIM has become so important in IoT. It reduces manual work, makes international deployment easier and helps connected devices stay adaptable as conditions change.

But that kind of flexibility only works when there is a common structure behind it. Standards provide that structure. They make it easier for devices, networks and service providers to work together in a secure and predictable way. They also support interoperability, which becomes increasingly important as deployments grow across countries, operators and product generations.

So while these standards sit quietly in the background, they play an important role in making IoT connectivity more scalable and more practical.

“The story behind these standards is simple: they are part of how IoT is becoming more mature, more flexible and more workable in everyday practice.”

First, what is remote SIM provisioning?

Remote SIM provisioning, often shortened to RSP, is the ability to activate, download or switch mobile network profiles over the air instead of replacing a SIM manually.

That may sound like a small detail, but in connected products it changes a great deal.

Physical SIM swaps do not scale well.

They cost time, create operational friction and become increasingly impractical once devices are deployed across multiple sites or countries. For embedded devices that are difficult to access, they can become a real obstacle to growth.

That is why RSP matters. RSP turns eSIM from a hardware feature into something operationally meaningful.

SGP.02: the earlier M2M model

SGP.02 belongs to an earlier generation of eSIM standards. It was developed for more traditional machine-to-machine environments, where deployments were often more fixed, more controlled and built around longer planning cycles.

In that context, it made sense. Many connected environments were relatively closed, devices were more static, and operator relationships were handled in a more structured and predictable way.

That also explains why SGP.02 still has relevance today. Existing deployments can continue to work well with it, especially where the architecture is already stable and the requirements are known.

But it also reflects an earlier view of connectivity: one that was not designed around the full diversity of modern IoT.

As the market moved toward more global, more flexible and more distributed deployments, the limitations of that older model became easier to see.

SGP.22: the consumer model

SGP.22 is associated with the consumer side of eSIM. It was developed for devices such as smartphones, tablets and other user-facing electronics, where usability and end-user interaction play a larger role.

That is an important distinction.

Consumer eSIM logic is not automatically the same as IoT eSIM logic.

A smartphone is visible, interactive and directly handled by a person. Many IoT devices are the opposite. They may be embedded, headless, battery-powered, hard to reach and deployed in large numbers.

That difference matters because it changes what “good” provisioning looks like. In consumer electronics, convenience for the end user is central. In IoT, the priorities are often scale, automation, low power use, long lifecycles and operational control.

So while SGP.22 is a valid and important standard, it was not created with every IoT scenario in mind.

SGP.32: designed for the realities of IoT

SGP.32 is the newest of the three standards and represents a more direct response to the needs of modern IoT.

What makes it different is not simply that it is newer.

It is that it was designed with connected products in mind — especially the kinds of devices that define today’s IoT landscape: embedded devices, headless devices, battery-powered devices and large fleets that need to be managed efficiently over time.

That makes SGP.32 feel less like an update and more like a shift in perspective.

Rather than treating IoT as a variation of older M2M or consumer logic, SGP.32 recognises that IoT has its own requirements. It needs provisioning that works at scale. It needs architectures that support long product lifecycles. And it needs a model that fits devices which may never be physically touched again after installation.

Why SGP.32 feels more practical

One of the reasons SGP.32 matters is that it makes eSIM easier to imagine in real operational terms.

It supports the kind of flexibility many organisations are actually looking for:

• remote profile updates across large fleets
• simpler international deployment models
• fewer manual interventions in the field
• better adaptability when regulations, operators or commercial conditions change
• stronger alignment with long-term lifecycle management

That makes a real difference. It means eSIM becomes less about theoretical flexibility and more about practical control.

In that sense, SGP.32 reflects a more mature stage of the market. It supports the idea that connected products should not only be possible to launch, but also possible to manage well over time.

A more modular architecture

Another reason SGP.32 stands out is the structure behind it.

It introduces a more modular architecture, with components that help separate responsibilities around provisioning, orchestration and device-side interaction. Acronyms such as eIM, SM-DP+, IPA and eSO belong to that structure.

For many readers, the exact abbreviations are less important than what they represent.

Together, they point to a more complete operating model: one that is designed not only to send profiles to devices, but also to support automation, policy-based management and fleet-wide coordination at a much broader scale.

That is one of the reasons SGP.32 feels more future-oriented. It reflects the reality that IoT is no longer only about connecting a single device, but about managing growing ecosystems of connected products.

Does every organisation need SGP.32 right now?

Not necessarily.

This is not a story in which older standards suddenly become irrelevant. Existing SGP.02 or SGP.22 deployments can continue to serve their purpose, and in many cases there is no immediate need to replace them.

The better way to think about it is fit.

If an existing system is stable, well understood and aligned with operational needs, there may be no reason to change it quickly. But for new projects — especially those with long lifecycles, international ambitions or large-scale rollout plans — SGP.32 is increasingly the more relevant standard to understand.

So the question is not simply which standard is newest. It is which standard best fits the kind of connected product being built.

What this means in practice

For manufacturers, service providers and enterprises, these standards influence much more than technical design.

They affect how products are manufactured, how provisioning is organised, how operators are selected, how compliance is approached and how much flexibility remains later in the lifecycle. They also shape how practical it is to scale across regions without adding too much operational complexity.

That is an important point. eSIM success does not come from embedding a chip alone. It depends on how the wider system is designed around it.

A standard does not solve everything by itself. But the right standard can make the rest of the system far easier to manage.

A simpler way to remember the difference

If the terminology feels overly technical, the easiest summary is this:

• SGP.02 belongs to the earlier M2M era
• SGP.22 belongs to the consumer eSIM world
• SGP.32 is the newer standard designed more directly for IoT

That does not mean one is universally best in every situation. It simply means each one comes from a different context.

And as IoT becomes more global, more diverse and more operationally demanding, the standards that support it are evolving in the same direction.

Final thought

Standards like SGP.02, SGP.22 and SGP.32 are easy to overlook because they sit beneath the surface. Most users never see them. Most connected devices do not advertise them in any visible way.

And yet they matter.

They help determine whether eSIM remains complicated or becomes manageable. Whether international rollouts stay fragmented or become easier to scale. And whether connected products can adapt over time as networks, regulations and business requirements continue to evolve.

So while the acronyms may sound technical, the bigger story is quite simple: these standards are part of how IoT is becoming more mature, more flexible and more workable in everyday practice.