SGP.32 eSIM in IoT: What This Means for Cellular IoT Deployments

Quick answer

The cellular IoT market is still trying to understand what to make of the GSMA SGP.32 standard.

SGP.32 was designed specifically to overcome some of the hurdles of previous eSIM iterations, especially for headless IoT devices that do not have screens or user interfaces.

While it has significant promise for remote provisioning and large-scale IoT deployments, SGP.32 has found limited real-world traction so far. For many IoT deployments in Africa, local IMSIs or multi-IMSI roaming solutions may still be the safer and more practical option for 2026/27.

SIMcontrol supports SGP.22 eSIM functionality on most local networks, as well as multi-IMSI IoT roaming options.

What is SGP.32?

SGP.32 is the GSMA’s dedicated architecture for IoT eSIMs.

It introduces two critical components:

• eSIM IoT Manager (eIM)
• IoT Profile Assistant (IPA)

The eIM acts as a remote configuration tool that tells the device which profile to download.

The IPA, which resides on the device or a local proxy, handles secure communication with the carrier’s servers.

This architecture is intended to remove the need for the complex, expensive integrations between carrier platforms required by the older M2M eSIM standard, SGP.02.

By utilising the same SM-DP+ infrastructure used by consumer devices, SGP.32 can make it easier for operators to support IoT devices and reduce the vendor lock-in that local mobile networks currently have.

SGP.32 vs SGP.22

The primary difference between SGP.32 and SGP.22 lies in the user interface and provisioning model.

SGP.22: Consumer eSIM

SGP.22 is the established consumer eSIM standard used in smartphones and tablets.

It relies on a “pull” model where a human user interacts with the device, usually by scanning a QR code, to trigger a profile download.

This works well for phones, tablets and wearables where a user can physically interact with the device.

SGP.32: IoT eSIM

SGP.32 is designed for “headless” IoT devices that do not have screens or user interfaces.

While it borrows the efficient “pull” architecture from the consumer eSIM world, it replaces the human element with an automated management layer.

This allows for remote, bulk provisioning of thousands of IoT devices without manual intervention.

Why SGP.32 matters for IoT

For large IoT deployments, manually provisioning or switching SIM profiles can be impractical.

SGP.32 aims to make it easier to manage eSIM profiles across fleets of connected devices, especially where devices are:

• deployed in remote locations
• difficult to physically access
• produced in bulk
• used across multiple countries
• dependent on long-term connectivity
• designed without screens or user interfaces

In theory, this makes SGP.32 attractive for industrial IoT, smart meters, asset tracking, telematics and other large-scale M2M deployments.

SGP.32 limitations and considerations

Despite its benefits, SGP.32 is not a “magic bullet” just yet.

There are several limitations and considerations businesses need to understand before choosing it for an IoT deployment.

1) Hardware compatibility

SGP.32 requires specific eUICC hardware and compatible cellular modules.

Not all existing legacy hardware can be upgraded to SGP.32 through software.

This means businesses with older IoT devices may need to replace hardware or wait for compatible modules before SGP.32 becomes a realistic option.

2) Platform migration

Enterprises currently using the older SGP.02 M2M standard face a significant migration path.

SGP.02 and SGP.32 are not natively interoperable, which means businesses need to plan carefully before moving between architectures.

This can affect device fleets, platform integrations, operational workflows and commercial models.

3) Infrastructure maturity

Not all Mobile Network Operators have fully updated their back-end systems to support SGP.32 handshakes.

Many networks are also not eager to offer SGP.32, as it can reduce the device and network lock-in they currently have.

This means availability will vary by operator, country and commercial appetite.

4) Initial complexity

Setting up the eIM infrastructure requires a technical transition for enterprises used to traditional SIM management.

It introduces new security credentials, provisioning workflows and management layers.

For some businesses, this can create additional complexity before the long-term benefits are realised.

5) Power and data overhead

The use of modern security protocols and the “pull” mechanism may lead to slightly higher data usage and power consumption compared to traditional simple SIMs.

This is especially important for battery-constrained sensors and low-power IoT devices.

For NB-IoT, LTE-M and battery-operated use-cases, power and data overhead must be considered carefully.

6) Cost

SGP.32 introduces another cost layer through eIM and IPA platforms.

In some deployments, the commercial benefit may not yet justify the added platform cost.

This is especially true where local SIMs, SGP.22 eSIM or multi-IMSI roaming options can already solve the business requirement more simply.

Is SGP.32 eSIM viable for IoT deployments in Africa?

SGP.32 is currently in the early commercialisation phase.

It is moving from the specification phase into early adoption, with the first certified eIM platforms and compatible modules becoming available in the market.

While the specifications are finalised, the ecosystem of certified modules and eIM platforms is still maturing through 2025 and 2026.

However, the key question is whether SGP.32 is viable right now for IoT deployments in Africa.

In Africa, the ecosystem is still maturing.

While compatible hardware is becoming available, many local MNOs have not yet fully deployed the necessary SM-DP+ and eIM support.

For deployments happening in 2026/27, local IMSIs or multi-IMSI solutions may still be the safest option.

What should businesses use today?

For businesses deploying cellular IoT devices now, the right choice depends on the use-case, country footprint, hardware, commercial model and network requirements.

Practical options include:

• local physical SIMs
• local eSIM profiles using SGP.22 where supported
• multi-IMSI IoT roaming SIMs
• Managed Private APN SIMs
• hybrid local and roaming approaches for cross-border fleets

SGP.32 may become more important over time, especially as hardware and operator ecosystems mature.

But for many current African IoT deployments, proven local or multi-IMSI options may be more practical in the short term.

Decision checklist: should you consider SGP.32?

Consider SGP.32 if:

• you are planning a large-scale IoT rollout
• your hardware supports SGP.32-compatible eUICC
• your devices are headless and difficult to physically access
• your deployment needs remote profile management
• your target operators support the required infrastructure
• you have the technical capability to manage eIM and IPA workflows
• the commercial benefit outweighs the added platform cost

Consider other options if:

• you need to deploy immediately
• your target country ecosystem is not ready
• your devices use legacy hardware
• you only need local connectivity
• multi-IMSI roaming already solves the requirement
• the added cost and complexity are not justified

Common mistakes

• Assuming all eSIM standards work the same way
• Confusing SGP.22 consumer eSIM with SGP.32 IoT eSIM
• Assuming legacy IoT devices can be upgraded to SGP.32 through software
• Underestimating operator readiness in African markets
• Ignoring the cost of eIM and IPA platforms
• Choosing SGP.32 before confirming hardware, network and commercial support
• Treating SGP.32 as a replacement for all IoT SIM options

FAQ

What is SGP.32?

SGP.32 is the GSMA’s eSIM architecture designed specifically for IoT devices. It enables remote provisioning for headless IoT devices without requiring a user to scan a QR code or interact with a screen.

How is SGP.32 different from SGP.22?

SGP.22 is used mainly for consumer devices like smartphones and tablets, where a person triggers the profile download. SGP.32 is designed for IoT devices and replaces the human interaction with an automated management layer.

Is SGP.32 the same as SGP.02?

No. SGP.02 is the older M2M eSIM standard. SGP.32 is a newer architecture designed to simplify IoT eSIM provisioning and reduce the complex integrations required by SGP.02.

Is SGP.32 ready for IoT deployments in Africa?

The ecosystem is still maturing. While compatible hardware and platforms are emerging, many local mobile network operators still need to fully support the required back-end infrastructure.

Can existing IoT devices be upgraded to SGP.32?

Not always. SGP.32 requires compatible eUICC hardware and cellular modules. Many legacy devices cannot be upgraded through software alone.

What are the alternatives to SGP.32 today?

Alternatives include local SIMs, SGP.22 eSIM profiles where supported, multi-IMSI IoT roaming SIMs and Managed Private APN SIMs, depending on the use-case.

Does SIMcontrol support SGP.32?

SIMcontrol supports SGP.22 eSIM functionality on most local networks, as well as multi-IMSI IoT roaming options. SGP.32 remains an emerging option as the broader ecosystem matures.

‍

Related reading

• /learn/iot-sim-card-south-africa/
• /learn/which-network-is-best-for-iot-south-africa/
• /learn/iot-connectivity-in-africa/
• /learn/private-apn-south-africa/
• /learn/one-api-for-multi-network-sim-management/
• /learn/understanding-esim-technology-for-business/
• /learn/choosing-the-best-sim-type-for-iot/
• /learn/global-iot-connectivity-explained/

‍