SGP.32 Bootstrap: True Zero Touch IoT Connectivity & the 1GLOBAL Advantage

By its nature, the telco industry is constantly shifting, evolving, and at the forefront of modern technology. However, even by its own dynamic standards, the digital communication sector is currently undergoing a profound shift in scope, a transformation primarily driven by the ferocious advance of IoT.  

In this article we’re going to take a look at what’s fueling this drive, and identifying how the GSMA’s SGP.32 spec is revolutionizing IoT scalability with its Zero Touch provisioning architecture and automated, machine-driven connectivity management. 

The Bottleneck  

For at least the last decade, there’s been an exponentially growing demand for a hyper-connected world populated by billions of autonomous sensors, smart meters, and intelligent assets – all of which were being throttled by their own architecture.  

The traditional plastic SIM, and even early iterations of the eSIM, caused logistical and technical friction that were incompatible with the economic and operational needs of massive IoT deployments. Reliance on physical prompting, complex operator-to-operator integrations, and power-hungry legacy protocols were stifling innovation, dissuading market entry and inflating TCO. 

The GSMA’s introduction of the SGP.32 technical spec marked the start of a whole new era, and a big step in what economists have described as the Fifth Industrial Revolution.  

By reframing the remote provisioning architecture specifically for autonomous and resource-constrained devices, SGP.32 delivered on the long-awaited promise of true Zero Touch provisioning.  

At the core of this revolution is the SGP.32 bootstrap mechanism, an inbuilt initial connectivity layer that decouples hardware manufacturing from data provision, and enabled the ‘single SKU’ supply chain model of automated, policy-driven deployment anywhere in the world.    

The Evolution of Standards 

To appreciate the full importance of the SGP.32 upgrade, it’s essential to have some context of the previous cellular connectivity standards. The evolution from the physical SIM to eSIM-powered SGP.32 isn't merely a technical progression but a response to market pressures that were making global IoT deployments prohibitively complex and expensive. 

For the better part of 30 years, the physical SIM card was the anchor of mobile identity. It securely stored the International Mobile Subscriber Identity (IMSI) and authentication keys (Ki), binding a device to a specific Mobile Network Operator (MNO). In the consumer market of the time, this was a marvelous convenience. A customer could walk into a shop, pay their money, and put in a SIM card that in just two or three short days would be connected to the network. 

In the nascent IoT market, this physical dependence was a fatal flaw. Industrial sensors are often sealed, embedded, or welded directly on to machinery to better withstand shocks. Any kind of maintenance or upgrade needed on-site technician visits, which when counted in the hundreds (or even thousands) of distributed devices could be ruinous to the bottom-line. Whole fleets of devices were often abandoned rather than ever updated.     

SGP.02 

The industry's first response was GSMA SGP.02, usually better known as the Machine-to-Machine (M2M) spec. Introduced to enable Remote SIM Provisioning (RSP) for hardwired SIMs, M2M used a push model centered on the Subscription Manager – Secure Routing (SM-SR). While it theoretically allowed profile swapping, SGP.02 ultimately failed to scale due to its technical rigidity and commercial friction.    

Technically, SGP.02 relied on the SM-SR to act as the SIM gatekeeper. To switch a fleet from one network to the other, the first network would have to technically integrate their SM-SR with the second to facilitate the handover. This created a complex web of dependencies, delays, usually fees from both ends, and outright lock-in if either operator was uncooperative. 

This architecture perpetuated what commercial analysts call a ‘walled garden’ model, where operators were disincentivized to make leaving their network easy. This meant that even though the M2M spec made it possible, true remote provisioning was rare, and many enterprises remained trapped in underperforming contracts.  

Furthermore, SGP.02 relied heavily on SMS messages to receive commands. The industry increasingly sought to leverage LP-WAN tech like NB-IoT and LTE-M, which are designed to squeak out infrequent, tiny data packets and go dormant between, which meant they often missed the relatively large and singular SMS deliveries. As the command trigger mechanism became unreliable, it made M2M more and more unfit for the emerging model of massive autonomous IoT.    

SGP.22  

Hearing the architecture creak and groan, industry regulators subsequently developed SGP.22, also known as the Consumer standard. SGP.22 introduced the ‘pull’ model, which gave devices the autonomy to request profiles directly from an operator’s Subscription Manager – Data Preparation (SM-DP+) server, bypassing the restrictive SM-SR. This architecture was hugely successful in the consumer market, allowing users to download profiles via QR codes or apps, and helped popularize smartphones as being easy enough for anyone to connect and get using.

However, SGP.22 was in essence designed for devices with a screen and a nearby human to operate it. The standard assumed there would always be someone around to consent to profile downloads, scan QR codes, or poke at settings menus  – all of which was basically the opposite of IoT.  

There were attempts to adapt SGP.22 for IoT, often involving hacks like custom apps spoofing user inputs. These workarounds were at best non-standard and generally insecure and unscalable. The industry was left with a split ecosystem between M2M that was SM-SR integration-dependent and too rigid and, on the other side, a Consumer that wasn’t designed for remote fleet management. This stalled the growth of IoT while a frustrated market demanded a unified solution.    

The Best of Both 

Officially released in 2023, the SGP.32 spec resolved this issue by combining the open, flexible backend of Consumer with the remote management of the M2M model, designed explicitly for network-constrained devices without needing user prompting.    

SGP.32 retains the simplified SM-DP+ build of Consumer, but replaces the inconvenient human component with a remote machine interaction. This is achieved by splitting the functions of the Local Profile Assistant (LPA) into the IoT Profile Assistant (IPA) on the device and the eSIM IoT Remote Manager (eIM) in the cloud.    

IoT Remote Manager (eIM) 

The eIM serves as the ‘strategic brain’ of the SGP.32 and the standardized provisioning tool for deployment and management of eSIM-powered IoT devices at scale. Unlike SGP.22 where the intelligence sat on the phone, or SGP.02 where the intelligence sits with the operator's SM-SR, the eIM is fully within the control of the IoT enterprise (or their expert connectivity partner, such as 1GLOBAL).   It acts as a de facto replacement for SM-SR, performing similar functions but redesigned for greater control of IoT Enterprises, enabling them to assume full control of the eSIM, instead of the MNOs. 

The eIM handles three critical functions: 

• First, it enables fleet management, allowing managers to group devices and apply bulk operations.  

• Second, it manages profile orchestration by determining which profile a device should use based on location, rates or data volume.  

• Third, it generates standardized commands sent to the device’s IPA to download, enable, disable, or delete profiles. An important element of this is that the eIM commands are operator-agnostic, allowing an enterprise to use a single eIM to manage varied profiles simultaneously.    

IoT Profile Assistant (IPA) 

The IPA acts as the tactical agent residing on the device, functioning as the equivalent of the LPA in smartphones but adapted for remote management (cameras and touchscreens for human interfacing when onsite). The IPA also has an API to the eIM to enable it to retrieve management commands remotely, from the eIM. SGP.32 includes two functions, the (confusingly-named) device-based IPAd, where the software runs on the device’s own hardware, and the IPAe, where it operates directly on the eSIM chip itself.    

The IPAe is perhaps the current best solution for the transition period between when legacy devices cannot be upgraded with iPAd immediately. The iPAe eSIM can work out-of-the-box straight away, and then improved at a later date with iPAd firmware updates. The IPA remains responsible for establishing a secure channel with the eIM, interpreting eIM commands, and download protocols with the SM-DP+.    

CoAP vs. SMS/HTTP 

One of the most significant technical advancements in SGP.32 is the shift from heavy web protocols to lightweight, IP-based standards. Previous generations’ reliance on SMS was unreliable for sleeping devices, or alternatively on HTTP, which engineers criticized for being "chatty" and draining battery life with complex connection handshakes. 

SGP.32 augments these protocols by enabling Constrained Application Protocol (CoAP) over UDP, which is designed specifically for IoT to be much lighter and more efficient, sending small data packets without the overhead of traditional web traffic.  

This additional spec ensures that provisioning even the most constrained devices like those using NB-IoT doesn't drain their battery or spike data usage, making 10-year lifecycles a reality.    

The Bootstrap Profile 

How do you get a connectivity profile if you don't have connectivity in the first place? With SGP.22 Consumer, users often rely on publicly available networks to download their initial eSIM profile. For a smart meter welded to the hull of a container ship, getting on the Wi-Fi is rarely an option. This is the role of the Bootstrap Profile.  

The bootstrap is a pre-installed, factory-loaded profile on the eSIM to provide just enough basic initial connectivity to allow the IPA to contact the eIM and download the full and proper operational profile.    

The bootstrap profile is the key to realizing the ‘Zero Touch’ promise, and the very first test that an IoT launch will face. If a fleet ships with an ineffective bootstrap profile, as supplied by a small operator with few roaming agreements, the whole deployment will fail before it begins. It can't reach the internet, can't reach the eIM, and can't provision itself.  

How Bootstrap Works 

SGP.32 spec introduces the possibility to implement how different scenarios of boostrap profiles can be operated, both for initial connectivity and as a fallback profile.  

First, they could act as a permanent fallback, so if the ‘main’ operational profile fails then the IPA automatically reverts to the bootstrap profile to re-establish barebones connectivity and request new credentials.  

Second, bootstrap profiles are typically configured with ‘whitelisted’ restricted access controls allowing traffic only to the specific IP addresses of the eIM and SM-DP+ servers, to prevent freeloading.  

Finally, to support the ‘single SKU’ manufacturing model, the bootstrap must be what the GSMA calls ‘globally capable’, holding roaming agreements that cover every potential destination market of the device.    

Regulatory Challenges 

A great opportunity for bootstrap profiles is the increasing prevalence of restrictions against permanent roaming.  

Multiple nations including Brazil, Turkey, India, China, and Canada have regulations prohibiting devices from long-term roaming on foreign SIMs, typically no longer than 90 days. 

Under SGP.02, this was a major IoT barrier. A device shipped with a UK-based M2M SIM to Brazil would work for three months and then go dark. SGP.32 solved this by using the bootstrap as a strictly temporary bridge. The device lands in Brazil, connects via a roaming bootstrap, immediately contacts the eIM, and downloads a fully Brazilian profile, thus satisfying the regulatory requirement for localization. The bootstrap profile goes dormant, ready to be used again should the device move to a new country or the local profile fails.    

Transforming Deployments 

The adoption of SGP.32 completely transformed the viability of IoT manufacturing, deployment, and lifecycle management. 

For decades, manufacturing logistics have been plagued by the complexity of regional SKUs. An OEM producing trackers for a global client would have to manage separate inventory lines for each region, such as a US model preloaded with AT&T profiles, a European model with Vodafone credentials, an Asian unit with a Singtel contract, and so on.  

This increased inventory costs, complicated forecasting, hugely reduced supply chain agility, and generally made time-to-market unacceptably slow.  

With the single SKU model, the OEM installs a generic eSIM with a global bootstrap profile into every device, making the hardware identical, regardless of target market. The dedication of the device to its final bundle of operator is delayed until deployment, with the eIM configured to handle the logic.    

True Zero Touch  

The deployment phase sees one of SGP.32’s most dramatic and cost-effective workflow improvements. Under previous specs, a human had to at least scan a QR code. Under SGP.32, the process is fully autonomous. 

The Zero Touch workflow begins when the device first boots up. The IPA reads the bootstrap profile and attaches to the best available local network via roaming. It then uses a pre-configured address to find its eIM and establishes mutual authentication using TLS/DTLS.  

Once identified, the eIM pulls a download command to the IPA. The IPA connects to the SM-DP+, downloads the operational profile, installs it, and enables it.  

Finally, the device detaches from the bootstrap network and attaches to the new fully-featured network. This entire sequence occurs completely without human intervention, in a handful of seconds, and hugely reduces deployment costs by eliminating the need for technician oversight.    

Lifecycle Management 

Post-deployment, SGP.32 gives IoT businesses managers options. Contracts can be switched, upgraded, or renegotiated. As devices report poor regional signal strength, the eIM can be triggered to download and switch profile to a different operator.  

Additionally, the system provides robust failover options, as when a profile becomes corrupted or discontinued, the bootstrap ensures the device isn’t entirely lost, allowing the eIM to push a fresh profile. 

The 1GLOBAL Advantage 

While SGP.32 provides the framework, it of course still can’t guarantee a successful deployment. The standard defines how the eIM talks to the IPA, but it doesn't provide the global cellular networks, the roaming agreements, or the sophisticated orchestration logic required to actually connect that global fleet.  

This is where 1GLOBAL differentiates itself from pure software vendors or single-market operators. 

1GLOBAL isn't merely a reseller or software provider. It’s a facilities-based telecommunications operator and a full MVNO in its own right, having built a unique core network infrastructure that aggregates agreements with over 600 MNOs globally.    

This infrastructure acts as the bedrock of 1GLOBAL’s bootstrap profiles. Unlike competitors who may rely on a single roaming partner with coverage gaps, 1GLOBAL’s bootstrap utilizes proprietary Multi-IMSI technology. This allows the bootstrap profile itself to dynamically swap its identity (IMSI) to access different roaming sponsors.  

"In each region where a device wakes up, the 1GLOBAL applet on the eSIM automatically configures proper IMSIs, allowing access to several local networks. Thus, despite the possible failure of a local provider, there is always a redundant fallback IMSI available and further back up networks accessible.”. This redundancy ensures that the initial connectivity required for SGP.32 has a near-total availability rate in 190+ countries, effectively insuring the Zero Touch workflow against network failures.    

Advanced Orchestration 

1GLOBAL offers a mature Remote SIM Provisioning platform that functions as a supercharged eIM. While standard eIMs facilitate basic profile downloads, 1GLOBAL’s eIM offers API integration with enterprise ERP and CRM systems, allowing connectivity logic to be driven by business events.  

This enables unified management of both legacy SGP.02 devices and new SGP.32 devices, streamlining the oversight of mixed fleets. Single pane of Glass (SPoG) is currently being designed for incorporation into our connectivity capability. 

Full Regulatory Compliance 

Regulatory compliance is arguably the one truly global challenge to any IoT project. 1GLOBAL is a fully regulated telecommunications operator in 10 countries and a registered provider in 30 others, with full regulatory compliance in 42 countries. This status allows 1GLOBAL to offer "Compliance as a Service".  

Security and Certification 

Security was a primary concern when SGP.32 was being designed, as the eIM has root-level control over the device's connectivity. 1GLOBAL’s platform is being prepared for certified under the GSMA’s Security Accreditation Scheme for Subscription Management (SAS-SM), a certification that would verify 1GLOBAL’s data centers, key management processes, and physical security measures all meet the rigorous standards required to handle MNO encryption keys. Furthermore, 1GLOBAL operates geo-redundant data centers, ensuring that a natural disaster or outage in one region doesn't disrupt the global management of IoT fleets.    

Does SGP.32 work? 

The adoption of SGP.32, powered by 1GLOBAL’s infrastructure, has been proven to provide compelling economic benefits that extend beyond technical efficiencies. 

For OEMs and any business with a supply chain, the shift to single SKUs significantly reduces logistics costs. Zero-touch provisioning cuts deployment costs by removing the need for specialized installations. Recurrent connectivity spend is optimized through the ability to renegotiate between operators and avoid permanent roaming penalties.  

Future-Proofing 

IoT devices now can often have lifespans exceeding a decade. Long-term locking such assets to a single contract is a strategic risk, as operators can go bankrupt, change pricing structures, or sunset whole network technologies such as with 2G/3G.  

SGP.32 acts as an insurance policy, guaranteeing that the device’s connectivity provider can be changed at any point in the future without physical access.  

Looking to tomorrow, the architecture is forward-compatible with iSIM tech, where the SIM functionality moves from a separate chip into the device’s main processor. This will soon be further reducing hardware costs and board space, enabling new form factors for ultra-compact IoT devices.    

Next steps 

The arrival of GSMA SGP.32 represents a watershed moment for IoT. By shedding the legacy constraints and the rigidities of early standards, SGP.32 delivers the architecture required to scale IoT to billions of devices. It replaces human dependence with machine intelligence, heavy protocols with lightweight IP standards, and fragmented supply chains with the streamlined single SKU model. 

However, any standard’s only as effective as the infrastructure that supports it. By combining a robust, multi-IMSI global network with a SAS-certified orchestration platform and deep regulatory expertise, 1GLOBAL solves the practical challenges of SGP.32, ensuring that the bootstrap is never a bottleneck and that zero-touch works everywhere, every time.  

Get in touch with our IoT experts today to learn more.