Is Your IoT Product Ready for the SGP.32 eSIM Specification?

Technology tends to move from hardware to software, as physical components give way to virtual features. That trend certainly holds in IoT connectivity. For example, see the growth of eSIM, a market that’s expected to nearly quadruple in size, reaching over $16 billion, by 2027. 

This embedded subscriber identity module (hence “eSIM”) replaces the manual swapping of hardware SIM cards with remote provisioning. In other words, it replaces hardware with software—but so far, the benefits of this shift have fallen more heavily on consumer mobile devices than IoT deployments.    

This difference comes from the technical specifications that govern mobile communication. Specifically, until recently, the standardization authority GSMA offered different technical specifications for remote provisioning in consumer devices and massive IoT deployments:  

• For consumer devices, this is SGP .22 - Remote SIM Provisioning Architecture for Consumer Devices.

• For IoT systems, it’s SGP .02 - Remote Provisioning Architecture for Embedded UICC Technical Specification 

With the 2023 release of SGP .32 - eSIM IoT Technical Specification, however, the differences between remote provisioning for IoT devices and consumer devices are starting to align a lot more closely. Simply put, SGP .32 allows massive IoT systems to access cellular networks more like eSIM-enabled consumer devices. It’s a simpler process, so IoT product designers are watching the rollout of SGP .32 closely.    

But does that mean every IoT product line should incorporate SGP .32 standards immediately? Not necessarily. Here’s why. 

How SGP .32 Is Meant to Change Cellular IoT Connectivity 

Before we get to our recommendations for IoT producers, we should explain the significance of GSMA’s SGP .32 eSIM standard. 

The key capability described by this standard concerns how IoT devices access the profiles that tell cellular networks they are, indeed, authorized for access. (This process is called provisioning.)

With a physical SIM, the profile is hard-wired onto the SIM card. With eSIM, you can store multiple profiles on a single chip, and you can access new profiles remotely—without having to swap out hardware, in other words. That provides access to a broader range of cellular networks, an essential feature for global IoT deployments.   

Remote eSIM Provisioning for IoT Systems (Before SGP .32)

Under the old GSMA remote SIM provisioning (RSP) standard for IoT systems, remote access to user profiles required SMS (text messaging) capabilities. The device required bootstrap profiles to send SMS requests to networks, which would then deliver appropriate access credentials. 

This sometimes clunky process is known as the push model of provisioning because network systems have to actively send profiles out to devices. It’s a complicated backend setup for a cellular IoT system,  

Remote eSIM Provisioning 

The consumer RSP specification, on the other hand, follows a pull model of SIM provisioning. The eSIM uses a type of application called a local profile assistant (LPA) to access network profile packages from the networks.  

With SGP .32, LPA use—the simpler “pull” model of provisioning—becomes standard for massive IoT deployments. At least, that’s the plan—but, unfortunately, the hardware ecosystem isn’t quite mature enough for immediate deployment of SGP .32.  

The Role of IoT Modules in Remote Provisioning    

To connect to any cellular network, an IoT device needs an IoT module. This hardware includes a few features that control connectivity: 

• The chipset that controls the electromagnetic radio waves that communicate with cellular towers. 
• Computing hardware like a processor and memory storage units.
• Antennas to send and receive radio waves (or at least an antenna port). 
• eSIM chips, integrated SIM circuitry, and/or SIM card slots. 

In other words, the module is where the cellular connection takes place. The hardware, firmware, and software standards built into the module control remote provisioning. As we publish, the current generation of IoT modules doesn’t incorporate the SGP .32 specifications. 

If you’re building IoT products, you’re probably buying your IoT modules from producers. Until those producers start shipping modules that use the SGP .32 specifications, there’s not much you can do. It will probably take about 5 years for these new capabilities to become widely available in IoT modules. While you can plan for the arrival of SGP .32, a product you release today probably won’t be able to take advantage of the new specification. Here’s what that means for IoT product designers. 

Getting Ready for the Rollout of the SGP .32 RSP Specification

If you need to ship your IoT product soon, you’re probably stuck with eSIM remote provisioning via the SGP .02 specification, complete with an SMS bootstrap. If you’re not in a hurry, you could keep your eye on the module market and see when this hardware starts incorporating SGP .32. 

With either approach, however, the best way to prepare for SGP .32 is the same: Partner with a cellular connectivity provider that can handle technical upgrades for you. An IoT connectivity provider links your devices to a network or networks, freeing you from vendor-lock with a single mobile network operator (MNO). 

That offers a single entryway into global connectivity. It creates redundancy to prevent downtime for your devices. And, with the right partner, it future-proofs your IoT system, as the connectivity experts can incorporate new technologies as they arise. 

Look for a connectivity partner that works with module manufacturers; they’ll be the first to incorporate new features like LPA provisioning with eSIM, according to the SGP .32 specification. 

In general, if a connectivity-as-a-service provider has a strong track record of technical versatility—offering not just 4G or 5G networks, but private LTE/5G, satellite, and low-power network choices, too—they’re likely to handle the heavy lifting on new GSMA specifications for you. That will get you ready for SGP .32 and whatever comes next, too.