What Is SGP.32? A Practical Guide to the New IoT eSIM Standard

For years, one of the biggest IoT limitations wasn’t coverage; it was identity. 

Once a device was shipped, changing a cellular identity usually meant swapping SIM cards, replacing hardware, or relying on provisioning methods never designed for modern IoT deployments. Connectivity was something you decided at the time of manufacturing and lived with for the life of the device. That model doesn’t work well anymore.

As connected products become more global, autonomous, and distributed, enterprises need more flexibility in how devices connect, authenticate, and adapt over time. That’s where SGP.32 comes in.

Whether you’re designing connected products today or preparing for large-scale global deployments, understanding SGP.32 is becoming increasingly important. This guide breaks down what SGP.32 is, how it differs from previous eSIM standards, how it works, and why enterprises are paying attention.

What SGP.32 Is

SGP.32 is the GSMA’s remote SIM provisioning (RSP) standard built specifically for IoT devices. It enables connected devices to securely download, activate, switch, and manage mobile operator profiles over the air, without replacing a SIM card or physically accessing the device. Unlike consumer eSIM standards designed for smartphones, SGP.32 was created for the realities of IoT: devices that may have no screen, no user interaction, limited power, and deployments spanning thousands of locations.

At the center of SGP.32 is the eUICC, a secure SIM component that can store multiple operator profiles. This enables enterprises to update connectivity as requirements change, whether that means expanding into new regions, switching operators, improving coverage, or adapting to new business needs.

The result is a more flexible approach to managing cellular connectivity. Instead of treating connectivity as a fixed decision made before deployment, SGP.32 gives organizations greater control over how devices stay connected throughout their lifecycle.

Why IoT Needed a New Approach

Before SGP.32, IoT devices had two imperfect paths to remote provisioning. Older M2M standards (SGP.02) relied on SMS-triggered push updates: workable, but heavy on backend complexity and a poor fit for low-power, intermittently connected devices. The alternative was borrowing the consumer eSIM model built for phones (SGP.22), which assumes a screen and a user to complete activation. Most IoT devices have neither.

SGP.32 closes that gap with a provisioning model built around how IoT devices actually operate: headless, resource-constrained, and deployed at a scale where “someone taps a button” isn’t realistic. We flagged this shift back in 2023, when the spec was brand new and IoT modules hadn’t caught up yet; it’s taken a few years, but the gap it was meant to close is now closing.

How Does SGP.32 Differ From SGP.02 and SGP.22

The clearest way to see the difference is to compare what each standard assumes about the device on the other end:

The practical difference is who’s in control. With SGP.32, profile changes are triggered by policy, not by a person standing next to the device. That’s what makes it possible to move an entire fleet, tens of thousands of devices, onto a new operator profile with a single command and no site visits.

How the eIM Works

SGP.32’s architecture rests on three components:

IPA (IoT Profile Assistant) is the on-device counterpart to the consumer LPA. It lives either inside the eUICC itself (IPAe, embedded IPA) or on the device’s cellular module (IPAd, device-based IPA), and is the local agent that executes profile commands on the SIM.

eIM (eSIM IoT Remote Manager) is the cloud-based orchestrator, the new entity SGP.32 introduces. It talks to the IPA to trigger enabling, disabling, deleting, or downloading a profile, and it’s what makes fleet-wide, policy-driven profile management possible.

SM-DP+ (Subscription Manager Data Preparation Plus) is the same profile-delivery backend used in consumer eSIM. It stores, encrypts, and delivers the actual operator profile once the eIM requests it and the IPA is ready to receive it.

Put together: the eIM decides what should happen, the IPA carries it out on the device, and the SM-DP+ supplies the profile. For the engineering-level view, including how this holds up in real-world testing, see our 2025 update on SGP.32’s market adoption.

Benefits

SGP.32’s real value isn’t the standard itself; it’s what it lets enterprises do differently. Owning a device’s connectivity identity after it ships, instead of fixing it at manufacturing, changes the economics and the risk profile of a deployment:

• One global SKU. Ship a single hardware SKU everywhere and assign country- or carrier-specific profiles remotely, rather than building region-specific variants. (See our breakdown of SIM form factors and technologies if you’re still choosing one.)
• No truck rolls. Profile changes, carrier switches, and credential rotation happen over the air, across an entire fleet at once.
• Built-in resilience. A dormant secondary profile can remain unused on the eUICC and automatically activate if the primary network goes down, without service interruption.
• Optimized for constrained devices. SGP.32 is designed around lightweight profile templates that offload processing to the cloud-based eIM, a real constraint for battery-powered or low-memory devices.
• A foundation for real Zero Trust. Owning the identity on the eUICC, rather than renting it from a single carrier, is what makes hardware-rooted Zero Trust device authentication possible in the first place. (We’ve covered why SIM-rooted identity beats certificate-based Zero Trust and why owning that identity is the real shift of SGP.32.)

Real-World Use Cases

SGP.32 is gaining the most traction where devices are geographically dispersed and expensive to physically access:

• Connected vehicles and telematics, where a single vehicle platform is sold globally and needs to activate the right operator profile at the point of sale or first use.
• Security systems and body cameras, where chain-of-custody and uptime requirements make remote credential management a security feature, not just an operational convenience.
• Industrial IoT and asset tracking, where devices sit in the field for years and a carrier renegotiation shouldn’t mean a hardware recall.
• Fixed wireless access, where operators need to provision large volumes of customer premises equipment without site visits.
• Smart metering and utilities, where devices are effectively unreachable once installed.

These are the same pressures we cover in the hidden costs of IoT connectivity: multi-carrier fragmentation, engineering time lost to manual provisioning, and downtime that gets more expensive as fleets scale. SGP.32 doesn’t solve all of that on its own, but it removes one of the root causes: the inability to change a device’s connectivity identity after it ships.

Why SGP.32 Matters Now

The timing of SGP.32 isn’t accidental. It’s arriving just as enterprise connectivity is undergoing one of its biggest shifts in decades.

Connected devices are becoming more intelligent, more autonomous, and more distributed. Whether it’s connected vehicles, industrial automation, healthcare devices, or Physical AI, organizations need connectivity that can adapt.

At the same time, the industry is moving away from static, carrier-centric deployments and toward software-defined connectivity, where identity, security, and network policies can be managed dynamically rather than locked in at manufacturing. SGP.32 provides an important building block for that future.

The standard itself has also matured. With version 1.2 establishing the certifiable baseline and ecosystem support continuing to grow, SGP.32 has moved beyond an industry roadmap into real-world pilots and commercial deployments.

Equally as importantly, business priorities are changing. Enterprises are looking to reduce carrier lock-in, simplify global deployments, strengthen Zero Trust security, and improve resilience across increasingly complex connectivity environments. Managing device identity remotely is no longer simply an operational convenience; it’s becoming a strategic capability.

That doesn’t mean every piece of the ecosystem is fully mature. Certification paths, module availability, and vendor support continue to evolve. But the direction is clear. As connected devices become more autonomous and global deployments become more complex, the ability to securely manage connectivity throughout the device lifecycle will increasingly separate resilient IoT deployments from those constrained by yesterday’s infrastructure.

Getting Started with SGP.32

SGP.32 isn’t simply another eSIM specification. It’s a step toward more flexible, resilient, and software-defined connectivity.

At Monogoto, we’re helping enterprises put those capabilities into practice: from evaluating SGP.32 to deploying global IoT connectivity with built-in security, automation, and lifecycle management, all on our global IoT SIM platform. Whether you’re exploring remote SIM provisioning or preparing your next connected product, our SGP.32 Ready Kit gives you a practical place to start.

Join Kaleido Intelligence and Monogoto on September 16 at 10:30 AM ET for a practical discussion on where SGP.32 is headed, what enterprises should expect from the new standard, and why owning your connectivity identity, not just your SIM, is becoming a strategic advantage.
Register today>>