SGP.32 vs SGP.22: What Changes for IoT Connectivity?

Table of Contents

1. Quick Comparison: SGP.22 vs SGP.32 
2. What Is SGP.22?
3. What Is SGP.32?
4. The Biggest Differences Between SGP.22 and SGP.32
5. Why SGP.32 Matters for Large IoT Deployments
6. Real-World Use Cases for SGP.32
7. Does SGP.32 Replace SGP.22?
8. Challenges of SGP.32 Adoption
9. What Businesses Should Consider Before Moving to SGP.32
10. Final Thoughts
11. Frequently Asked Questions

eSIM technology became popular through smartphones and smartwatches, where activating a mobile plan is usually a quick process. IoT devices create a completely different situation.

A sensor mounted on industrial equipment does not have a screen. An EV charger installed in a parking lot may stay in service for years without anyone physically touching it. The same applies to kiosks, routers, smart meters, and tracking devices deployed across multiple regions.

That is why the GSMA introduced SGP.32. Unlike SGP.22, which was originally built around consumer eSIM workflows, SGP.32 focuses on remote provisioning for large-scale IoT deployments where manual interaction is often unrealistic.

For businesses operating connected infrastructure, the difference between these standards affects far more than activation alone. It changes how devices are deployed, maintained, and managed over time.

 Quick Comparison: SGP.22 vs SGP.32 

What Is SGP.22?

Most people first encountered eSIM technology through smartphones and smartwatches. Behind many of those consumer activation workflows sits SGP.22, a GSMA standard designed around digital SIM provisioning for consumer devices.

Instead of inserting a physical SIM card, users could download a carrier profile directly onto the device. In most cases, the process still involved some manual interaction, usually scanning a QR code or completing activation steps through the device itself.

That model works well in consumer electronics where the user is physically holding the phone, tablet, or smartwatch during setup.

IoT deployments create a very different situation.

A sensor attached to industrial equipment may not have a screen at all. A payment terminal deployed across hundreds of retail locations cannot realistically depend on manual provisioning every time connectivity needs to be updated or changed. The same applies to tracking devices, kiosks, smart meters, and other infrastructure that may remain installed in the field for years.

At smaller scale, this is manageable. Once deployments grow into thousands of connected devices spread across multiple carriers or regions, manual provisioning quickly becomes harder to maintain operationally.

What Is SGP.32?

SGP.32 was introduced to address a problem that became more visible as IoT deployments started growing in scale. Consumer eSIM workflows were never really designed for devices that operate remotely for years without direct human interaction.

Many IoT devices are what the industry often calls “headless.” They may not have a display, keyboard, or interface that allows somebody to manage connectivity manually. In some cases, the device may be installed on remote infrastructure where physical access is difficult or expensive from the start.

Think about an industrial sensor mounted on utility equipment, a smart meter installed in the field, or a tracking device moving between countries every day. Manually provisioning connectivity for those types of deployments becomes difficult very quickly.

That is where SGP.32 changes the approach.

Instead of relying on consumer-style activation flows, the standard focuses more heavily on remote lifecycle management for IoT environments. Connectivity providers and operators can provision, update, and manage eSIM profiles remotely across large device fleets without depending on constant physical access to the hardware itself.

This becomes especially relevant in deployments involving:

• Industrial sensors
• Smart meters
• Connected kiosks
• EV charging stations
• Fleet tracking devices
• Remote routers
• Digital signage systems

The goal is not simply digital SIM activation. SGP.32 was designed to make large-scale IoT connectivity easier to manage operationally as deployments continue expanding across regions, carriers, and device types.

The Biggest Differences Between SGP.22 and SGP.32

Both SGP.22 and SGP.32 are built around eSIM technology, but they were created for very different environments.

SGP.22 came from the consumer side of the market, where activation usually happens one device at a time. A user installs a profile, confirms the setup process, and the device connects to the network. That workflow makes sense when somebody is physically holding the device during activation.

IoT deployments rarely work that way.

A company managing thousands of connected devices across multiple countries cannot depend on QR codes or manual provisioning every time connectivity needs to be updated. The operational model is completely different once devices are deployed in the field at scale.

That shift in scale is one of the main reasons SGP.32 was introduced.

Instead of focusing on consumer activation flows, SGP.32 was designed around centralized remote management for large IoT fleets. Devices can be provisioned and updated remotely without requiring constant physical interaction or manual configuration.

The difference may sound small on paper, but operationally it changes quite a lot.

A retail chain deploying payment terminals across hundreds of stores does not want technicians manually activating devices one by one. An energy company managing remote utility infrastructure may need to update connectivity profiles across thousands of devices without sending teams into the field. Those situations become much easier to manage when provisioning is handled remotely at the fleet level rather than device by device.

Operational Comparison

Another major difference appears after deployment.

IoT infrastructure rarely stays static. Devices may need carrier changes, profile updates, fallback provisioning, or connectivity optimization years after installation. Under older provisioning approaches, those tasks could become operationally expensive very quickly, especially in large distributed deployments.

SGP.32 was built to reduce some of that long-term operational overhead.

Why SGP.32 Matters for Large IoT Deployments

The challenges start becoming more obvious once IoT deployments move beyond small pilot projects.

Managing twenty connected devices manually is usually manageable. Managing tens of thousands across multiple countries, carriers, and hardware types is a very different situation altogether.

Older provisioning workflows were never really built for that level of scale.

Take EV charging infrastructure as an example. A charging operator may deploy stations across several regions where network performance varies from one location to another. In logistics, tracking devices may cross borders constantly and connect to different mobile networks throughout the day. Industrial equipment installed in remote facilities may remain active for years without routine physical access.

At that point, connectivity management stops being just a technical setup task. It becomes part of day-to-day operations.

This is one of the main reasons SGP.32 matters for large IoT environments. The standard was designed to make remote connectivity management more practical across distributed device fleets.

That includes tasks such as:

• Remote provisioning
• Carrier profile updates
• Device onboarding
• Connectivity optimization
• Long-term lifecycle management

The flexibility becomes especially important for companies operating internationally or across multiple carrier environments where connectivity conditions may change over time.

Real-World Use Cases for SGP.32

Smart Vending Machines

Vending operators are no longer managing simple standalone machines. Many modern systems handle cashless payments, inventory reporting, remote diagnostics, and software updates through a cellular connection.

When connectivity fails, operators may lose visibility into machine activity or stop processing transactions entirely.

That becomes difficult to manage manually once deployments spread across hundreds or thousands of locations. Replacing SIM cards or reconfiguring devices onsite every time a carrier issue appears creates obvious operational overhead.

SGP.32 was designed to make that type of remote connectivity management easier at scale.

EV Charging Infrastructure

EV charging networks rarely operate under identical network conditions. A charger installed in a city parking garage may behave very differently from one deployed along highways or in rural areas.

As charging infrastructure expands, operators often end up managing devices across multiple carriers and coverage environments at the same time.

In those situations, remote provisioning becomes much more practical than relying on manual configuration or physical maintenance visits whenever connectivity changes are required.

Industrial Sensors and Smart Infrastructure

Industrial IoT devices are often installed in places people do not want to visit unnecessarily.

A sensor attached to utility infrastructure, pipeline systems, or factory equipment may stay in service for years without being physically accessed. Sending technicians onsite for routine SIM management is expensive and difficult to scale.

That is one of the reasons remote lifecycle management matters so much in industrial IoT environments.

Fleet Tracking and Logistics

Logistics deployments create their own connectivity challenges because devices move constantly.

A tracking unit monitoring cargo shipments may connect to different carriers throughout a single route, especially in cross-border operations where roaming conditions and network availability can change quickly.

At small scale, those situations are manageable manually. Large international fleets are a different story. Remote provisioning and centralized profile management become far more important once deployments start growing globally.

Smart Cities

Smart city infrastructure usually involves far more connected devices than most people realize.

Traffic systems, environmental sensors, parking infrastructure, public kiosks, and digital signage may all depend on continuous cellular connectivity across different parts of a city.

Managing those systems individually becomes increasingly difficult as deployments expand. SGP.32 helps support a more centralized approach to provisioning and long-term connectivity management across large public infrastructure environments.

Does SGP.32 Replace SGP.22?

Not really. The two standards were built for different types of deployments, which is why both will likely remain relevant for a long time.

SGP.22 still makes perfect sense in consumer electronics where users manage connectivity directly on the device itself. Smartphones, tablets, smartwatches, and other personal devices fit naturally into that model because activation usually happens during setup by the person using the device.

IoT environments operate differently.

A utility sensor mounted in the field, a payment terminal installed across hundreds of stores, or a tracking device moving between countries every day does not behave like a consumer smartphone. The operational requirements are completely different once deployments become large, distributed, and heavily automated.

That is the gap SGP.32 was designed to address.

Rather than focusing on consumer activation workflows, the standard is aimed more at long-term remote lifecycle management for connected infrastructure operating at scale.

For most organizations, the real question is not whether one standard is universally better than the other. The more important consideration is which approach fits the operational model of the deployment itself.

Challenges of SGP.32 Adoption

SGP.32 may solve several problems around large-scale IoT connectivity, but adoption across the industry is unlikely to happen overnight.

Part of the reason is simply ecosystem maturity. Not every carrier, hardware manufacturer, or connectivity platform currently supports SGP.32 in the same way. Some companies are already preparing for it, while others are still heavily tied to existing provisioning models.

There is also the operational side to consider.

Large IoT deployments usually rely on multiple systems working together behind the scenes. Provisioning platforms, orchestration tools, connectivity management systems, and hardware ecosystems often evolve over many years. Introducing a newer provisioning standard into that environment is not always a quick transition.

Compatibility can become another challenge, especially in global deployments involving multiple carriers and vendors at the same time.

A company managing connected devices across different regions may already operate within a fairly complex infrastructure stack. In practice, most organizations are more likely to integrate SGP.32 gradually rather than replace existing provisioning workflows all at once.

That is generally how connectivity standards evolve in the IoT space. Adoption tends to happen in stages as carrier support, platform compatibility, and operational confidence continue improving over time.

What Businesses Should Consider Before Moving to SGP.32

Companies evaluating SGP.32 are usually dealing with a very different type of deployment than traditional consumer eSIM environments.

The conversation is not really about removing physical SIM cards anymore. In most cases, it becomes a question of how connectivity will be managed once deployments start expanding across regions, carriers, and device types.

A smaller deployment may work perfectly well with existing provisioning workflows. The operational challenges start appearing once devices remain in the field for years, move across multiple network environments, or become difficult to access physically after installation.

That tends to change the connectivity strategy fairly quickly.

Before adopting SGP.32, companies often look at questions such as:

• How large the deployment may become over time
• Whether devices will operate without direct user interaction
• How often carrier profiles may need to change
• Whether devices will move across countries or network environments
• How difficult physical access becomes after deployment

For large distributed IoT deployments, those factors eventually become operational considerations rather than technical preferences. As device fleets grow, remote lifecycle management usually becomes much harder to ignore.

Final Thoughts

The move from SGP.22 toward SGP.32 reflects how much the IoT industry itself has changed over the last few years.

Early eSIM workflows were built largely around consumer devices where activation happened one device at a time. Modern IoT deployments operate under very different conditions. Device fleets are larger, infrastructure is more distributed, and many systems now run for years with little or no direct human interaction.

That changes the connectivity requirements quite a bit.

For companies managing connected infrastructure at scale, the discussion is no longer only about digital SIM activation. Increasingly, it becomes a question of how connectivity can be provisioned, updated, and maintained efficiently across thousands of devices over long operational lifecycles.