SGP.32 will not be the eSIM story that gets consumers excited at an airport gate. No discount code, no pretty app screen, no “scan this QR before landing” moment. Its importance sits somewhere less glamorous but far more expensive: the lifetime of connected devices after they leave the factory.

For years, IoT teams have lived with an awkward contradiction. The product was global, but the SIM strategy was local. A tracker shipped into Europe needed one arrangement. A meter deployed in Asia needed another. A vehicle entering the US needed different mobile network partners, commercial terms, and sometimes different hardware planning. When things changed, someone paid: operations, procurement, support, or the customer beside a device that had gone dark.

SGP.32, the GSMA’s eSIM IoT technical specification, is designed for that reality. It covers remote provisioning and management of eUICCs in IoT devices that may be network-constrained, user-interface-constrained, or simply too numerous to manage like phones. GSMA lists SGP.32 v1.3 as active in 2026, alongside the related SGP.31 architecture and SGP.33 test specifications. IoT does not need another proprietary promise. It needs a common operating language.

Why the old eSIM models were not enough

Before SGP.32, the industry had two imperfect choices. SGP.02, the older M2M model, was useful for automotive and industrial deployments, but it was shaped by an era when operators kept tighter control over provisioning. It worked, but it could be heavy, integration-intensive and awkward for low-power devices.

READ MORE: SGP.32 Explained: IoT eSIM Fleet Operations in 2026

Then came SGP.22, the consumer eSIM model. Brilliant for smartphones. Less brilliant for a sensor bolted to a container, a rural payment terminal, or a smart meter with no screen. Consumer eSIM assumes a “pull” experience: the device, or the user, initiates profile download. IoT often needs the opposite. The fleet owner wants to push, switch, recover and localize connectivity across thousands or millions of units.

What changes in practice

The two pieces to understand are eIM and IPA. The eIM, or eSIM IoT Manager, coordinates profile lifecycle operations from the backend. The IPA, or IoT Profile Assistant, performs the device-side work of talking securely to the eUICC and executing profile actions. In simple terms: eIM is the control tower; IPA is the on-device operator carrying out the instruction.

This creates a cleaner model for remote profile download, activation, switching and recovery. A manufacturer can ship one hardware SKU with bootstrap connectivity. A logistics company can move from one connectivity partner to another without physical SIM swaps. A utility can keep a fallback profile ready. A car maker can change mobile network partners as it enters new markets, without redesigning the vehicle.

The commercial race has started

The market is no longer waiting politely. Juniper Research expects eSIM devices to grow 30% in 2026, from 1.2 billion in 2025, which explains the sudden urgency. Soracom announced commercial availability of its Connectivity Hypervisor and SGP.32-compatible IoT eSIMs with an orchestration model built around eUICC, eIM and SM-DP+ components. emnify has positioned SGP.32 as the basis for factory-ready bootstrap provisioning, provider independence and fallback resilience. KORE and Kigen announced SGP.32-compliant connectivity solutions for 2026, aiming at gateways, battery-powered sensors, roaming, multi-network resilience and local connectivity.

READ MORE: eSIM Standards Explained: How SGP.32 Changes Travel Connectivity

Automotive is another signal. G+D, Rivian and AT&T said Rivian’s upcoming R2 would use GSMA SGP.32-enabled eSIM and 5G connectivity, allowing mobile network partners to be added or changed over the vehicle lifecycle. Eseye is also positioning SGP.32 as part of a broader orchestration framework that can support SGP.02, SGP.22 and SGP.32 environments.

Soracom talks like a cloud-native IoT platform. emnify leans into programmable connectivity and cloud core control. KORE and Kigen bring enterprise IoT scale and secure eSIM infrastructure. G+D shows how automotive-grade hardware and eIM infrastructure fit into vehicles. Eseye emphasizes hybrid orchestration and multi-standard continuity.

What buyers should ask

The lazy question is, “Do you support SGP.32?” The better question is, “How much of SGP.32 can I use?”

A buyer should ask whether profiles can be downloaded remotely, not merely preloaded. They should check which operators are integrated, whether third-party profiles are supported, and how fallback behaves when the primary profile fails. They should ask about eIM portability, testing, certification, firmware requirements, NB-IoT or LTE-M constraints, data routing, API access and visibility across mixed fleets.

READ MORE: SGP.32 Goes Commercial: Soracom’s IoT eSIM Play

SGP.32 is also not always necessary. A small domestic deployment using one reliable operator may be better served by a simpler SIM or managed roaming agreement. A device with a full user interface may still fit consumer eSIM logic. Very small, ultra-low-cost devices may eventually look toward iSIM. The point is not to use the newest standard everywhere. It is to stop using the wrong one where lifecycle flexibility matters.

Conclusion

SGP.32 is not “just another eSIM standard.” It is the point where IoT connectivity starts looking less like procurement of plastic and more like infrastructure software. That is why the interesting competition is not only between operators. It is between orchestration models.

The winners will not be the companies shouting “global coverage” the loudest. Everyone says that now. The winners will be the providers that can prove profile portability, operator neutrality, fallback logic, secure provisioning, clear APIs and realistic migration support. Soracom, emnify, KORE/Kigen, G+D, Eseye and others are circling the same real opportunity from different angles. Some will win through cloud-native control. Some through secure hardware. Some through operator relationships. Some through enterprise-grade service management.

For IoT buyers, the message is practical: do not buy SGP.32 as a badge. Buy it as an escape route from future rigidity. The standard gives enterprises a better way to design connected products that can survive market expansion, roaming changes, regulatory pressure and network failures. But it is not magic. Poor implementation will still create poor connectivity.

The real promise of SGP.32 is not that devices can switch profiles. It is that companies can make connectivity decisions later, smarter and with less drama. In IoT, that is not a technical luxury. It is the business model.