The Internet of Things has created an enormous connectivity opportunity for mobile operators, MVNOs and technology providers. Yet managing connectivity across large, distributed device fleets remains far more complicated than connecting individual smartphones.
An IoT device may operate for a decade or more. It may be installed inside a vehicle, meter, industrial machine or tracking unit that is difficult and expensive to access. It may cross national borders, connect only intermittently or operate with limited power and processing capacity.
A physical SIM tied to one connectivity provider can therefore create a long-term operational and commercial risk. If coverage deteriorates, roaming becomes uneconomical or local regulations change, replacing the SIM may require a costly field intervention—or may not be practical at all.
The GSMA’s SGP.32 specification addresses this challenge by creating an eSIM remote provisioning architecture designed specifically for IoT devices. It enables connectivity profiles to be managed remotely across devices that may have no screen, no keyboard and no person available to initiate a network change.
For IoT-focused MVNOs, SGP.32 is more than a technical update. It can change how connectivity is sold, managed and scaled. It also creates new expectations around automation, interoperability, device integration and lifecycle control.
The opportunity is significant, but simply purchasing an eSIM does not make an IoT deployment SGP.32-ready. MVNOs must connect profile management with their network relationships, OSS/BSS platforms, device architecture, commercial policies and operational processes.
What Is SGP.32?
SGP.32 is the GSMA’s technical specification for the remote provisioning and management of eSIMs in network-constrained or user-interface-constrained IoT devices.
In simpler terms, it allows an authorized platform to download, enable, disable and delete connectivity profiles on an IoT eSIM without requiring a person to interact with the device.
The specification is part of a wider framework. SGP.31 defines the IoT eSIM architecture and requirements, while SGP.32 describes how that architecture works technically, including its interfaces and security functions.
The GSMA published SGP.32 version 1.3 in May 2026. The specification covers the management of the eUICC—the secure component that stores operator profiles—as well as the architecture required to communicate with constrained IoT devices.
SGP.32 is intended for equipment such as smart meters, asset trackers, industrial sensors, security systems and connected machines. These devices frequently operate without the user interface found on a smartphone and may need to be managed in large numbers from a central platform.
This distinction is important because eSIM is not a single provisioning model. Consumer smartphones, traditional machine-to-machine deployments and modern IoT fleets have different operational requirements.
Why Existing eSIM Models Were Not Enough
Before SGP.32, IoT deployments generally had to work with one of two remote SIM provisioning approaches: the established M2M architecture or the consumer eSIM architecture.
The M2M model was designed for remotely managed devices and has been used in areas such as automotive and industrial connectivity. It supports server-driven profile management, but its architecture can require complex integrations between multiple parties. This complexity may be justified for very large deployments, but it can create commercial and technical barriers for smaller or more diverse IoT use cases.
The consumer model was designed for devices such as smartphones, tablets and wearables. A user typically initiates the process by scanning a QR code, selecting a plan or approving a profile download through a device interface.
That model works well when there is a person, screen and reliable connection available. It is less suitable for a sensor installed underground, a tracker attached to a shipping container or a utility meter expected to operate unattended for many years.
SGP.32 brings ideas from the consumer eSIM ecosystem into an architecture designed for IoT management. According to the GSMA’s overview of IoT remote SIM provisioning, the approach is intended to reduce integration complexity while enabling remote profile switching for low-cost, power-constrained devices.
The goal is not merely to replace one technical standard with another. It is to make remote connectivity management practical across a much wider range of IoT products.
How the SGP.32 Architecture Works
At the centre of the SGP.32 model is the eSIM IoT Remote Manager, commonly abbreviated as eIM.
The eIM provides a remote management layer for an IoT fleet. It can initiate profile-management operations according to instructions from the enterprise, connectivity provider or authorized service platform.
The eIM does not replace every other component in the eSIM ecosystem. Operator profiles are still prepared and securely delivered through an SM-DP+, the subscription management platform already used in the consumer eSIM architecture.
Communication between the eIM and the eUICC is supported by the IoT Profile Assistant, or IPA. Depending on the implementation, the IPA can reside in the device or within the eUICC. Its role is to help execute profile-management operations in an environment where there may be no user to guide the process.
In practical terms, an enterprise might decide to move a group of devices to a different network profile. Its connectivity management platform sends the required instruction through the SGP.32 architecture. The devices retrieve and install the relevant profile, and the new profile can then be enabled according to the defined policy and workflow.
For the customer, this process should feel like centrally managed software-defined connectivity. Underneath it, however, are several coordinated systems responsible for authorization, security, profile preparation, delivery, device communication and operational control.
Why SGP.32 Matters for IoT MVNOs
SGP.32 gives IoT MVNOs an opportunity to move beyond selling fixed connectivity tied to a single physical SIM or operator relationship.
An MVNO can instead offer connectivity designed around the complete lifecycle of a device. That lifecycle may include manufacturing, testing, deployment, international movement, network migration, contract renewal and eventual retirement.
Remote profile management can reduce the risk that a customer remains permanently dependent on the connectivity arrangement selected when the device was manufactured. If business requirements change, another profile may be introduced without replacing the physical eSIM.
This can be particularly valuable for long-lived devices. A smart meter or industrial controller may remain in operation much longer than the original network contract. SGP.32 creates a technical path for changing connectivity while keeping the device in place.
The specification can also support international deployments. Permanent roaming restrictions, coverage differences and local commercial requirements can make a single global connectivity agreement difficult to sustain. Remote profile management gives providers more options for introducing local or regional operator profiles.
However, SGP.32 should not be presented as a guarantee of unrestricted global network switching. An MVNO still needs suitable operator agreements, available profiles, compliant devices, interoperable platforms and permission to perform the required actions. The specification enables remote management, but it does not remove the commercial and regulatory realities of telecom.
From SIM Supplier to Connectivity Orchestrator
The traditional IoT SIM model is often centred on a fixed connectivity product. The provider supplies SIMs, assigns a network arrangement and charges for data usage.
SGP.32 creates the possibility of a more strategic role. An IoT MVNO can become an orchestrator that manages connectivity options throughout the life of a device fleet.
The value proposition can expand from “we provide a SIM” to “we help ensure your devices remain connected across markets, networks and changing business conditions.”
That service can include profile lifecycle management, network policy, deployment automation, usage control, billing, reporting and operational support. The MVNO can package these capabilities into an industry-specific proposition for logistics, utilities, healthcare, agriculture, manufacturing or mobility.
This is important because IoT customers rarely want connectivity for its own sake. They want devices to remain available, data to arrive reliably and operations to continue without unnecessary field intervention.
SGP.32 can make the underlying connectivity more adaptable, but the commercial value comes from turning that adaptability into a dependable managed service.
The Business Benefits of SGP.32
One of the clearest benefits is the potential reduction in physical intervention. Replacing a SIM inside a remotely installed device can cost far more than the connectivity used by that device over several years.
The cost may include technician time, travel, site access, device downtime and customer disruption. In some cases, such as sealed equipment or devices installed across multiple countries, replacement may be commercially unrealistic.
Remote profile management can reduce this exposure by allowing connectivity changes to be handled centrally.
SGP.32 may also improve resilience. If a deployment relies entirely on one profile and one network arrangement, a commercial or coverage problem can affect the entire fleet. The ability to prepare and manage alternative profiles gives enterprises more options when conditions change.
Another benefit is greater flexibility during manufacturing and deployment. A device manufacturer may not know the final destination of every unit when it leaves the factory. A suitable bootstrap profile can provide the initial connectivity required to deploy the operational profile later.
This can simplify global inventory management by reducing the need to manufacture many region-specific hardware variants. The exact benefit depends on the device architecture and commercial agreements, but the principle is powerful: connectivity decisions can be moved closer to the point of deployment.
SGP.32 can also strengthen an MVNO’s negotiating position over time. If profile migration is technically and operationally possible, the provider has more flexibility when contracts are renewed or new markets are added.
Again, this does not mean switching is effortless. Profile availability, testing, regulatory conditions and contractual commitments still matter. But the fleet is less likely to be limited permanently by a decision made at the beginning of its lifecycle.
What MVNOs Need to Build Now
The first requirement is an SGP.32 strategy that connects the technical architecture with a clear customer proposition.
An MVNO should decide what problem it intends to solve. Some providers may focus on regulatory localization. Others may prioritize network resilience, simplified manufacturing or long-term carrier flexibility. The architecture and operating model should reflect the selected use case.
The next requirement is an eIM capability. The MVNO must determine whether it will operate an eIM, integrate with a specialist provider or make the functionality available through a broader enablement platform.
This decision affects control, investment, compliance, operational responsibility and time to market. Building an eIM internally may provide greater ownership, but it also requires specialist expertise, ongoing maintenance and interoperability testing. A partner-led model can accelerate deployment, provided responsibilities and portability are clearly defined.
Device compatibility must be considered early. The IoT Profile Assistant needs to be supported in the selected architecture, and the device must be able to communicate reliably enough to complete profile-management operations.
Device manufacturers, module vendors, eUICC suppliers, connectivity providers and platform teams therefore need to coordinate before production. Waiting until devices have already been deployed can severely limit the available options.
Bootstrap connectivity is another critical design decision. A device needs an initial means of connecting so that it can communicate with the required systems and obtain an operational profile. The bootstrap arrangement must be suitable for the expected markets, network technologies and device behaviour.
MVNOs must also build integration between SGP.32 profile management and their OSS/BSS environment. A profile change can affect network access, products, pricing, usage collection, charging and customer support. If the eIM operates in isolation, the business may struggle to maintain an accurate view of each device.
The operational platform should know which customer owns the device, which profiles are available, which one is active, which commercial rules apply and what happened during each management operation.
This is where OSS/BSS orchestration becomes essential. SGP.32 manages an important part of the connectivity lifecycle, but it does not replace the systems responsible for customers, products, charging, billing, orders and support.
Why Automation Is Essential
IoT economics are very different from consumer mobile economics. An enterprise may operate thousands or millions of devices, each generating relatively little monthly revenue.
Manual processes that appear manageable during a pilot can become financially unsustainable at scale. Profile ordering, assignment, activation, policy enforcement, billing updates and error handling must therefore be automated wherever possible.
Automation is also necessary because devices do not behave like smartphones. Some may be offline when a profile-management instruction is issued. Others may have limited battery power or connect only during scheduled intervals. A remote operation may need to be queued, retried or completed through several stages.
The platform must maintain reliable state information throughout this process. It should distinguish between an instruction that has been requested, one that has reached the device and one that has been completed successfully.
Operational teams also need clear exception handling. If a profile download fails, the device should not be left without usable connectivity. Recovery rules, fallback behaviour and support processes must be designed before the fleet is deployed.
Security, Compliance and Control
Remote profile management affects the identity and connectivity of a device, making security fundamental to SGP.32 deployments.
The GSMA specification defines security functions and interfaces for the architecture, but providers must still secure the systems surrounding it. Access to the eIM must be controlled, management instructions must be authorized and operational actions should be auditable.
Enterprises also need clear governance. The platform should define who can request a profile change, which devices can be affected and what approval is required for large-scale operations.
A configuration error affecting one smartphone is inconvenient. A configuration error applied to an entire fleet of utility meters, medical devices or industrial sensors can become a major operational incident.
Regulatory requirements add another layer of complexity. Some countries restrict permanent roaming, require local profiles or impose rules relating to data handling and lawful access. SGP.32 may help a provider implement a localization strategy, but only when suitable local operator relationships and compliant processes are available.
MVNOs should therefore treat regulatory planning as part of the connectivity architecture rather than a task to be addressed after launch.
Interoperability Will Determine Real-World Success
A standardized specification creates the foundation for interoperability, but successful implementation still requires testing across the complete ecosystem.
The eUICC, IPA, device, eIM, SM-DP+, network profile and operational platform must work together correctly. Different device types and constrained network technologies can introduce additional variables.
MVNOs should avoid assuming that a component described as “SGP.32-compatible” will automatically work with every other component. They need defined test cases covering profile download, activation, deactivation, recovery, loss of connectivity and device restart behaviour.
Testing should also reflect real deployment conditions. A laboratory with constant power and strong coverage may not reveal the problems experienced by a battery-powered sensor connecting intermittently over a constrained network.
Interoperability must therefore be treated as an ongoing operational discipline, not a one-time certification exercise.
How Effortel Fits Into an SGP.32-Ready IoT Strategy
SGP.32 introduces a new remote profile-management layer, but MVNOs still need a wider operational platform to commercialize and manage IoT connectivity.
The Effortel Mobile Suite provides OSS/BSS capabilities for customer management, product configuration, service orchestration, charging, billing, orders and external system integration.
In an SGP.32-ready operating model, these capabilities can form the business and operational layer around the eSIM ecosystem. They allow the MVNO to connect devices and profiles with customers, products, commercial rules and usage.
Effortel’s integration experience can also support the connection between telecom systems, external IoT platforms and customer environments. This is essential because the value of SGP.32 is realized only when remote profile management becomes part of a complete, automated connectivity service.
For MVNOs entering the IoT market, the objective should not be to add another isolated technical component. It should be to build an operating model in which device management, connectivity, charging and customer service work together.
SGP.32 Is an Enabler, Not a Complete IoT Strategy
SGP.32 solves an important technical problem. It creates a standardized architecture for remotely managing eSIM profiles across constrained IoT devices.
It does not, by itself, provide global coverage, guarantee portability, negotiate operator agreements or create a profitable IoT proposition.
Those outcomes depend on how the MVNO combines the specification with its network relationships, device ecosystem, OSS/BSS capabilities, automation, commercial model and operational support.
Providers that approach SGP.32 as only a SIM upgrade may miss its wider significance. Those that treat it as the foundation of a flexible connectivity lifecycle can create more resilient and valuable IoT services.
The change is ultimately about control. Physical SIMs place many connectivity decisions at the beginning of a device’s life. SGP.32 makes it possible to manage more of those decisions remotely as commercial, regulatory and operational conditions evolve.
For IoT MVNOs, now is the time to define that architecture. Devices designed and deployed today may remain active for many years. The connectivity choices made at launch will shape what can—and cannot—be changed later.
Frequently Asked Questions
What does SGP.32 mean?
SGP.32 is the GSMA technical specification for remote eSIM provisioning and profile management in network-constrained or user-interface-constrained IoT devices.
What is the difference between SGP.31 and SGP.32?
SGP.31 defines the architecture and requirements for IoT eSIM remote provisioning. SGP.32 provides the technical specification describing how that architecture, its interfaces and its security functions are implemented.
What is an eIM?
The eSIM IoT Remote Manager, or eIM, is a component in the SGP.32 architecture that remotely manages eSIM profile operations for IoT devices. It works with the IoT Profile Assistant and other eSIM infrastructure to execute authorized management instructions.
What is an IoT Profile Assistant?
The IoT Profile Assistant, or IPA, enables communication and profile-management operations between the IoT device, eUICC and eIM. Depending on the implementation, it can reside in the device or in the eUICC.
How is SGP.32 different from consumer eSIM?
Consumer eSIM commonly assumes that a person can initiate or approve profile installation through a smartphone interface. SGP.32 is designed for devices that may have no screen, keyboard or available user and must therefore be managed remotely.
Does SGP.32 enable automatic carrier switching?
SGP.32 provides the technical ability to manage operator profiles remotely. Actual switching still depends on profile availability, device compatibility, platform integration, commercial agreements and regulatory permissions.
Does SGP.32 replace an OSS/BSS platform?
No. SGP.32 manages the remote eSIM profile lifecycle. An OSS/BSS platform is still needed to manage customers, products, orders, charging, billing, usage and service operations.
Build an IoT Connectivity Model That Can Evolve
SGP.32 gives MVNOs a stronger foundation for managing long-lived IoT deployments, but its value depends on the systems and operating model built around it.
Contact Effortel to explore how flexible OSS/BSS capabilities, service orchestration and telecom integration can support your IoT connectivity strategy.