.png)
SGP.32 IoT eSIM: Rethinking Connectivity for Connected Products
For years, cellular connectivity created an awkward constraint for IoT product teams: a device could be deployed globally, but its SIM strategy often had to be decided long before anyone knew where the device would ultimately operate.
Changing that decision later could mean replacing physical SIMs, negotiating roaming agreements, integrating proprietary platforms, or sending technicians into the field.
SGP.32 IoT eSIM changes that model.
The GSMA specification introduces a Remote SIM Provisioning architecture designed specifically for IoT devices, including devices with limited interfaces, limited processing capability, intermittent connectivity, or no user available to scan a QR code.
The important question is therefore not simply, "What is SGP.32?"
It is:
What changes when connectivity becomes something you can manage throughout the product lifecycle instead of something permanently decided during manufacturing?
That is where SGP.32 becomes strategically important.
What Is SGP.32 IoT eSIM?
SGP.32 is the GSMA technical specification for Remote SIM Provisioning in IoT devices.
It works alongside SGP.31, which defines the architecture and requirements for provisioning eUICCs in network-constrained or user-interface-constrained IoT devices. GSMA released the first SGP.32 specification in 2023 and currently lists SGP.32 v1.3, published in May 2026, as an active version.
An eUICC, often referred to broadly as an eSIM, can securely contain mobile network operator profiles.
Instead of permanently tying a deployed device to one physical SIM and one connectivity arrangement, compatible profiles can be remotely downloaded and managed.
The principle sounds simple.
The engineering implications are much larger.
A manufacturer could potentially produce one hardware SKU, deploy that device into several markets, and provision an appropriate connectivity profile later.
A fleet operator could change connectivity arrangements without physically opening thousands of deployed devices.
A connected product company could also separate a device's manufacturing lifecycle from its connectivity procurement lifecycle.
GSMA specifically designed the IoT architecture for devices where the conventional consumer eSIM experience is unsuitable, such as equipment without screens, keyboards, cameras, or users available to initiate profile downloads.
Why IoT Needed Another eSIM Architecture
Remote SIM Provisioning already existed before SGP.32.
But the earlier models solved different problems.
Consumer eSIM architecture works well for phones and wearables. A user can choose a provider, scan a QR code, and initiate a profile download.
Traditional M2M Remote SIM Provisioning was designed for machine-to-machine applications and has been used heavily in areas such as automotive and industrial deployments.
However, GSMA notes that M2M RSP typically involves greater integration complexity, while consumer RSP depends much more heavily on user interaction.
SGP.32 attempts to occupy the space between them.
It uses concepts from the established consumer RSP ecosystem while introducing mechanisms appropriate for unattended IoT fleets.
For product companies, this creates an important shift:
Cellular connectivity can increasingly become part of software-controlled fleet operations rather than a fixed manufacturing choice.
If you are designing a cellular product expected to operate for five or ten years, connectivity architecture deserves the same lifecycle planning as firmware, cloud infrastructure, and device management.
How SGP.32 IoT eSIM Works
The architecture becomes easier to understand when you stop thinking about a SIM card and instead think about a secure connectivity profile lifecycle.
Several components work together.
The eUICC
The eUICC is the secure component that stores and manages connectivity profiles.
It can support profile operations without requiring someone to physically replace a SIM card.
The hardware implementation may vary depending on the device design and ecosystem, but the important concept is that operator credentials become securely manageable.
SM-DP+
The Subscription Manager Data Preparation Plus, usually shortened to SM-DP+, prepares and securely delivers operator profiles.
This component already exists within the consumer eSIM ecosystem, which is one reason SGP.32 can reuse established eSIM infrastructure rather than creating an entirely isolated IoT ecosystem.
eSIM IoT Remote Manager
One of the major concepts introduced for IoT is the eSIM IoT Remote Manager, or eIM.
The eIM helps remotely manage eUICCs and coordinate operations across IoT devices.
For an IoT fleet, this matters because nobody should need to interact manually with each individual device.
The management logic can instead operate across large device populations.
IoT Profile Assistant
The IoT Profile Assistant, or IPA, provides functions required for communication between the IoT device, the eUICC, and other elements involved in profile management.
GSMA's architecture allows the IPA to reside either:
- within the IoT device, known as IPAd, or
- within the eUICC, known as IPAe.
The SGP.31 architecture identifies the eUICC, SM-DP+, eIM, IPA, SM-DS, and operator as key architectural components.
That location decision can affect device architecture, software responsibility, hardware selection, and integration strategy.
A Simplified Profile Lifecycle
Imagine an industrial monitoring device manufactured in one country and shipped worldwide.
During production, the device receives an eUICC and the software needed to participate in the SGP.32 architecture.
A device destined for Germany may eventually receive a profile appropriate for its European deployment.
Another device from the same manufacturing batch could be deployed in the United States and receive a different profile.
Later, connectivity requirements may change.
Instead of sending someone to replace the SIM, a compatible profile-management process can remotely provision or manage the required profile.
This is the real product value.
You are reducing the number of connectivity decisions that must become irreversible during manufacturing.
Building a cellular IoT product and evaluating eSIM, eUICC, or remote profile management? Infolitz can help assess the device, firmware, cloud, and connectivity architecture before those decisions become expensive to change.
SGP.32 Architecture and Technology Options
SGP.32 does not mean every connected product suddenly uses exactly the same technology stack.
Your implementation still depends on the device.
A typical cellular IoT product may include:
- LTE-M, NB-IoT, 4G LTE, or 5G connectivity
- a cellular modem or cellular module
- an eUICC
- embedded firmware
- IPA functionality
- an eIM service
- SM-DP+ connectivity
- device management
- cloud APIs
- fleet-management services
- telemetry and diagnostics
The right combination depends on product constraints.
Integrated Cellular Modules
Using a module with mature eSIM and SGP.32 ecosystem support can reduce some engineering work.
The advantage is faster integration and potentially better interoperability.
The trade-off is greater dependency on module vendor capabilities and software roadmaps.
Custom Embedded Designs
High-volume products may integrate the cellular modem, application processor, eUICC, firmware, and connectivity management more tightly.
That can create greater control over cost and hardware.
It also increases engineering and validation responsibilities.
IPA in Device vs IPA in eUICC
This architecture decision deserves attention early.
Running the IPA within the device may provide more application-side flexibility but places additional responsibility on device software.
Locating functionality within the eUICC may simplify certain device responsibilities but depends heavily on compatible eUICC capabilities and the chosen ecosystem.
There is no universal answer.
The right design depends on hardware resources, security model, firmware architecture, modem capabilities, deployment environment, and lifecycle requirements.
Best Practices for SGP.32 IoT Product Design
Adopting eSIM should begin with product lifecycle questions rather than with a SIM vendor quote.
Design for Connectivity Failure
Remote provisioning still depends on connectivity.
Ask what happens when:
- cellular coverage disappears,
- a profile download is interrupted,
- the device changes networks,
- cloud connectivity is unavailable,
- a certificate expires,
- the active profile becomes unusable.
A connected product should fail predictably.
Define Bootstrap Connectivity
A new device needs some path to obtain its operational connectivity.
That initial or bootstrap strategy needs to be designed intentionally.
Do not discover the bootstrap problem when devices are already sitting in another country.
Plan Profile Recovery
Profile switching is useful only when failure states are handled properly.
Define what happens if a newly enabled profile cannot establish connectivity.
Fallback and emergency mechanisms exist within the broader architecture and should be evaluated as part of the product's recovery strategy. SGP.32 defines mechanisms for profile management, including fallback-related behavior.
Keep Device Identity Separate From Connectivity Identity
A SIM identifier should not automatically become the primary identity of your application.
Devices may change profiles.
Your platform should maintain its own durable device identity and map connectivity credentials to it.
Add Connectivity Telemetry
Your operations team should be able to see more than "device offline."
Useful diagnostics can include:
- current network
- signal strength
- active profile
- last successful connection
- provisioning state
- roaming status
- modem state
- firmware version
- failure reason
Without this visibility, sophisticated eSIM capabilities can still produce difficult support incidents.
Test the Entire Lifecycle
Do not test only initial activation.
Test manufacturing, onboarding, profile download, switching, interrupted downloads, loss of coverage, device reboot, firmware updates, profile recovery, and eventual device retirement.
GSMA maintains the SGP.33 family of test specifications specifically to validate implementations and interoperability of components within the IoT eSIM ecosystem.
Performance, Cost, and Security Considerations
SGP.32 can improve operational flexibility, but it does not make connectivity free or simple.
Connectivity Cost
Organizations still need commercial arrangements with connectivity providers.
Your cost model may include:
- mobile data
- operator profiles
- roaming
- connectivity management
- eSIM platform services
- profile downloads
- eIM services
- SM-DP+ services
- integration and support
Actual pricing varies significantly by geography, volume, data consumption, provider, and commercial model.
For most IoT businesses, the more useful calculation is total connectivity lifecycle cost per deployed device, not simply monthly data price.
A cheaper SIM that requires a technician visit during an operator transition may become much more expensive across a fleet.
Device Resources
SGP.32 specifically targets network-constrained and UI-constrained devices, but implementations still require careful resource planning.
Evaluate:
- memory
- flash
- modem capabilities
- firmware complexity
- power consumption
- communication overhead
- retry behavior
Battery-powered sensors cannot behave like permanently powered gateways.
Security
Remote provisioning introduces powerful capabilities.
That makes authentication, authorization, certificate management, secure communications, and lifecycle controls essential.
The SGP.32 specification includes security functions as part of the IoT eSIM architecture.
Profile-management permissions should also follow least-privilege principles.
A compromise of connectivity management infrastructure should not automatically provide unrestricted access to device applications or product data.
Supply Chain Risk
Connectivity is increasingly part of your product supply chain.
Before selecting an eSIM ecosystem, evaluate:
- eUICC vendor support
- cellular module compatibility
- operator availability
- SM-DP+ interoperability
- eIM support
- certification requirements
- regional coverage
- long-term platform support
Your product may stay in the field much longer than the modem or platform's normal sales lifecycle.
If your next IoT product needs global cellular deployment, now is the time to evaluate connectivity alongside hardware, firmware, cloud architecture, and fleet management rather than treating SIM selection as a procurement step.
Real-World SGP.32 IoT eSIM Use Cases
SGP.32 becomes most valuable where devices are numerous, geographically distributed, difficult to reach, or expected to remain operational for years.
Asset Tracking
A logistics company may deploy trackers across dozens of countries.
Hard-coding one connectivity strategy during manufacturing can create roaming cost and coverage problems later.
Remote profile management gives the operator more flexibility to adapt connectivity as assets move or commercial arrangements change.
Smart Metering
Electricity, gas, and water meters can remain deployed for a decade or longer.
Sending technicians to thousands or millions of locations solely to replace SIMs is difficult to justify.
A remotely manageable connectivity model better matches the device lifecycle.
Industrial IoT
Industrial controllers, environmental sensors, equipment monitors, and gateways are frequently installed where physical access is expensive.
Remote profile capabilities can reduce dependence on field intervention.
Healthcare Devices
Connected medical and healthcare equipment may need reliable cellular connectivity across multiple deployment environments.
Any architecture must still satisfy applicable regulatory and security requirements, but remote connectivity lifecycle management can reduce operational friction.
Smart Cities
Parking sensors, environmental monitors, street infrastructure, lighting controllers, and utility devices may be deployed across large geographic areas.
GSMA specifically identifies areas including smart cities, asset tracking, healthcare, smart energy, and industrial IoT as potential IoT RSP use cases.
SGP.32 vs SGP.22
SGP.22 primarily supports consumer Remote SIM Provisioning.
Think smartphones, tablets, and consumer wearables.
A person usually participates in provisioning.
They can interact with the device, choose a provider, or scan an activation QR code.
SGP.32 instead addresses IoT devices where there may be:
- no screen,
- no keyboard,
- no camera,
- no user,
- limited bandwidth,
- limited processing capability,
- thousands of devices requiring centralized management.
The architectures share some ecosystem concepts and infrastructure, but the operating model is different.
For product teams, the easiest mental model is:
SGP.22 assumes a user can help provision the device. SGP.32 assumes the fleet must largely manage provisioning remotely.
SGP.32 vs SGP.02
SGP.02 represents the earlier M2M eSIM Remote SIM Provisioning model.
It has supported significant connected-device deployments, particularly automotive and industrial applications.
SGP.32 is intended to provide an IoT-specific architecture that can take advantage of elements from the established consumer RSP ecosystem while reducing some of the complexity associated with traditional M2M RSP.
GSMA describes M2M RSP as a push-oriented model generally used for non-user-interactive environments, while consumer RSP follows a pull model. The IoT architecture builds on consumer RSP concepts while enabling remote management appropriate for constrained devices.
For new connected-product programs, SGP.32 therefore deserves serious consideration during architecture planning.
.png)
FAQs
What is SGP.32?
SGP.32 is the GSMA technical specification for Remote SIM Provisioning in IoT devices. It defines technical mechanisms, interfaces, architecture behavior, and security functions for managing eUICCs in connected devices.
What is SGP.32 in IoT?
SGP.32 enables IoT devices, including network-constrained and UI-constrained devices, to participate in remote eSIM profile provisioning and management without requiring conventional consumer interaction.
What is an eIM in SGP.32?
The eSIM IoT Remote Manager, or eIM, is an architectural component that supports remote management operations for IoT eUICCs.
It enables fleet-oriented management rather than relying on a person to configure each device individually.
What is an IPA?
IPA stands for IoT Profile Assistant.
It supports profile-related communication and operations within the IoT eSIM architecture.
The IPA can be located in the IoT device as an IPAd or within the eUICC as an IPAe.
Does SGP.32 eliminate physical SIM cards?
SGP.32 does not simply mean "no physical SIM."
The central concept is remote profile management through an eUICC.
The eUICC implementation and form factor depend on the device architecture.
Can existing IoT devices be upgraded to SGP.32?
Sometimes, but not automatically.
Compatibility depends on the existing eUICC, modem, firmware, security architecture, device resources, and vendor support.
Devices designed without compatible hardware may require hardware redesign rather than only a firmware update.
Is SGP.32 more secure than a normal SIM?
SGP.32 includes defined security functions for remote provisioning and management.
However, overall product security still depends on device firmware, cloud systems, identity management, credentials, APIs, update mechanisms, operational controls, and implementation quality.
A secure eSIM does not make an insecure IoT product secure.
Does SGP.32 allow switching mobile operators?
Its Remote SIM Provisioning architecture enables compatible operator profiles to be remotely downloaded and managed.
Actual operator switching depends on technical compatibility, profile availability, commercial contracts, regulatory constraints, and participating ecosystem providers.
Will SGP.32 reduce IoT connectivity costs?
Not necessarily at the data-plan level.
Its stronger economic value may come from avoiding physical SIM replacement, simplifying global manufacturing, increasing provider flexibility, and reducing field-service requirements.
The correct metric is usually total lifecycle connectivity cost.
Should every new cellular IoT product use SGP.32?
Not automatically.
A simple product deployed in one country, using one operator, with a short lifecycle may gain little from sophisticated Remote SIM Provisioning.
A product deployed globally for many years across thousands of devices has a much stronger case.
Architecture should follow operational requirements.
SGP.32 shifts IoT connectivity from a decision made during manufacturing to a capability that can be managed throughout the product lifecycle.
Conclusion
SGP.32 represents more than an evolution of eSIM technology. It changes how connected-product teams can think about cellular connectivity across manufacturing, deployment, operations, and long-term fleet management.
For products expected to operate across multiple countries, networks, or many years, the ability to remotely manage connectivity profiles can reduce dependence on physical SIM replacement and make future connectivity changes easier to manage.
But SGP.32 should not be treated as an isolated connectivity feature. Its value depends on how well it fits with the modem, eUICC, embedded firmware, device identity, OTA strategy, cloud platform, diagnostics, security, and fleet-management architecture.
The practical question for product teams is therefore no longer simply “Which SIM should we use?”
It is:
“How should connectivity be designed so our product can adapt throughout its operational life?”
