TheInternet of Things has created an enormous connectivity opportunity for mobileoperators, MVNOs and technology providers. Yet managing connectivity acrosslarge, distributed device fleets remains far more complicated than connectingindividual smartphones.
An IoTdevice 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 toaccess. It may cross national borders, connect only intermittently or operatewith limited power and processing capacity.
A physicalSIM tied to one connectivity provider can therefore create a long-termoperational and commercial risk. If coverage deteriorates, roaming becomesuneconomical or local regulations change, replacing the SIM may require acostly field intervention—or may not be practical at all.
The GSMA’sSGP.32 specification addresses this challenge by creating an eSIM remoteprovisioning architecture designed specifically for IoT devices. It enablesconnectivity profiles to be managed remotely across devices that may have noscreen, no keyboard and no person available to initiate a network change.
ForIoT-focused MVNOs, SGP.32 is more than a technical update. It can change howconnectivity is sold, managed and scaled. It also creates new expectationsaround automation, interoperability, device integration and lifecycle control.
Theopportunity is significant, but simply purchasing an eSIM does not make an IoTdeployment SGP.32-ready. MVNOs must connect profile management with theirnetwork relationships, OSS/BSS platforms, device architecture, commercialpolicies and operational processes.
What Is SGP.32
SGP.32 isthe GSMA’s technical specification for the remote provisioning and managementof eSIMs in network-constrained or user-interface-constrained IoT devices.
In simplerterms, it allows an authorized platform to download, enable, disable and deleteconnectivity profiles on an IoT eSIM without requiring a person to interactwith the device.
Thespecification is part of a wider framework. SGP.31 defines the IoT eSIMarchitecture and requirements, while SGP.32 describes how that architectureworks technically, including its interfaces and security functions.
The GSMApublished SGP.32version 1.3 in May 2026. The specification covers themanagement of the eUICC—the secure component that stores operator profiles—aswell as the architecture required to communicate with constrained IoT devices.
SGP.32 isintended for equipment such as smart meters, asset trackers, industrialsensors, security systems and connected machines. These devices frequentlyoperate without the user interface found on a smartphone and may need to bemanaged in large numbers from a central platform.
Thisdistinction is important because eSIM is not a single provisioning model.Consumer smartphones, traditional machine-to-machine deployments and modern IoTfleets have different operational requirements.
Why Existing eSIM Models Were Not Enough
BeforeSGP.32, IoT deployments generally had to work with one of two remote SIMprovisioning approaches: the established M2M architecture or the consumer eSIMarchitecture.
The M2Mmodel was designed for remotely managed devices and has been used in areas suchas automotive and industrial connectivity. It supports server-driven profilemanagement, but its architecture can require complex integrations betweenmultiple parties. This complexity may be justified for very large deployments,but it can create commercial and technical barriers for smaller or more diverseIoT use cases.
Theconsumer model was designed for devices such as smartphones, tablets andwearables. A user typically initiates the process by scanning a QR code,selecting a plan or approving a profile download through a device interface.
That modelworks well when there is a person, screen and reliable connection available. Itis less suitable for a sensor installed underground, a tracker attached to ashipping container or a utility meter expected to operate unattended for manyyears.
SGP.32brings ideas from the consumer eSIM ecosystem into an architecture designed forIoT management. According to the GSMA’soverview of IoT remote SIM provisioning, the approach is intendedto reduce integration complexity while enabling remote profile switching forlow-cost, power-constrained devices.
The goal isnot merely to replace one technical standard with another. It is to make remoteconnectivity management practical across a much wider range of IoT products.
How the SGP.32 Architecture Works
At thecentre of the SGP.32 model is the eSIM IoT Remote Manager, commonly abbreviatedas eIM.
The eIMprovides a remote management layer for an IoT fleet. It can initiateprofile-management operations according to instructions from the enterprise,connectivity provider or authorized service platform.
The eIMdoes not replace every other component in the eSIM ecosystem. Operator profilesare still prepared and securely delivered through an SM-DP+, the subscriptionmanagement platform already used in the consumer eSIM architecture.
Communicationbetween the eIM and the eUICC is supported by the IoT Profile Assistant, orIPA. Depending on the implementation, the IPA can reside in the device orwithin the eUICC. Its role is to help execute profile-management operations inan environment where there may be no user to guide the process.
Inpractical terms, an enterprise might decide to move a group of devices to adifferent network profile. Its connectivity management platform sends therequired instruction through the SGP.32 architecture. The devices retrieve andinstall the relevant profile, and the new profile can then be enabled accordingto the defined policy and workflow.
For thecustomer, this process should feel like centrally managed software-definedconnectivity. Underneath it, however, are several coordinated systemsresponsible for authorization, security, profile preparation, delivery, devicecommunication and operational control.
Why SGP.32 Matters for IoT MVNOs
SGP.32gives IoT MVNOs an opportunity to move beyond selling fixed connectivity tiedto a single physical SIM or operator relationship.
An MVNO caninstead offer connectivity designed around the complete lifecycle of a device.That lifecycle may include manufacturing, testing, deployment, internationalmovement, network migration, contract renewal and eventual retirement.
Remoteprofile management can reduce the risk that a customer remains permanentlydependent on the connectivity arrangement selected when the device wasmanufactured. If business requirements change, another profile may beintroduced without replacing the physical eSIM.
This can beparticularly valuable for long-lived devices. A smart meter or industrialcontroller may remain in operation much longer than the original networkcontract. SGP.32 creates a technical path for changing connectivity whilekeeping the device in place.
Thespecification can also support international deployments. Permanent roamingrestrictions, coverage differences and local commercial requirements can make asingle global connectivity agreement difficult to sustain. Remote profilemanagement gives providers more options for introducing local or regionaloperator profiles.
However,SGP.32 should not be presented as a guarantee of unrestricted global networkswitching. An MVNO still needs suitable operator agreements, availableprofiles, compliant devices, interoperable platforms and permission to performthe required actions. The specification enables remote management, but it doesnot remove the commercial and regulatory realities of telecom.
From SIM Supplier to Connectivity Orchestrator
Thetraditional IoT SIM model is often centred on a fixed connectivity product. Theprovider supplies SIMs, assigns a network arrangement and charges for datausage.
SGP.32creates the possibility of a more strategic role. An IoT MVNO can become anorchestrator that manages connectivity options throughout the life of a devicefleet.
The valueproposition can expand from “we provide a SIM” to “we help ensure your devicesremain connected across markets, networks and changing business conditions.”
Thatservice can include profile lifecycle management, network policy, deploymentautomation, usage control, billing, reporting and operational support. The MVNOcan package these capabilities into an industry-specific proposition forlogistics, utilities, healthcare, agriculture, manufacturing or mobility.
This isimportant because IoT customers rarely want connectivity for its own sake. Theywant devices to remain available, data to arrive reliably and operations tocontinue without unnecessary field intervention.
SGP.32 canmake the underlying connectivity more adaptable, but the commercial value comesfrom turning that adaptability into a dependable managed service.
The Business Benefits of SGP.32
One of theclearest benefits is the potential reduction in physical intervention.Replacing a SIM inside a remotely installed device can cost far more than theconnectivity used by that device over several years.
The costmay include technician time, travel, site access, device downtime and customerdisruption. In some cases, such as sealed equipment or devices installed acrossmultiple countries, replacement may be commercially unrealistic.
Remoteprofile management can reduce this exposure by allowing connectivity changes tobe handled centrally.
SGP.32 mayalso improve resilience. If a deployment relies entirely on one profile and onenetwork arrangement, a commercial or coverage problem can affect the entirefleet. The ability to prepare and manage alternative profiles gives enterprisesmore options when conditions change.
Anotherbenefit is greater flexibility during manufacturing and deployment. A devicemanufacturer may not know the final destination of every unit when it leavesthe factory. A suitable bootstrap profile can provide the initial connectivityrequired to deploy the operational profile later.
This cansimplify global inventory management by reducing the need to manufacture manyregion-specific hardware variants. The exact benefit depends on the devicearchitecture and commercial agreements, but the principle is powerful:connectivity decisions can be moved closer to the point of deployment.
SGP.32 canalso strengthen an MVNO’s negotiating position over time. If profile migrationis technically and operationally possible, the provider has more flexibilitywhen contracts are renewed or new markets are added.
Again, thisdoes not mean switching is effortless. Profile availability, testing,regulatory conditions and contractual commitments still matter. But the fleetis less likely to be limited permanently by a decision made at the beginning ofits lifecycle.
What MVNOs Need to Build Now
The firstrequirement is an SGP.32 strategy that connects the technical architecture witha clear customer proposition.
An MVNOshould decide what problem it intends to solve. Some providers may focus onregulatory localization. Others may prioritize network resilience, simplifiedmanufacturing or long-term carrier flexibility. The architecture and operatingmodel should reflect the selected use case.
The nextrequirement is an eIM capability. The MVNO must determine whether it willoperate an eIM, integrate with a specialist provider or make the functionalityavailable through a broader enablement platform.
Thisdecision affects control, investment, compliance, operational responsibilityand time to market. Building an eIM internally may provide greater ownership,but it also requires specialist expertise, ongoing maintenance andinteroperability testing. A partner-led model can accelerate deployment,provided responsibilities and portability are clearly defined.
Devicecompatibility must be considered early. The IoT Profile Assistant needs to besupported in the selected architecture, and the device must be able tocommunicate reliably enough to complete profile-management operations.
Devicemanufacturers, module vendors, eUICC suppliers, connectivity providers andplatform teams therefore need to coordinate before production. Waiting untildevices have already been deployed can severely limit the available options.
Bootstrapconnectivity is another critical design decision. A device needs an initialmeans of connecting so that it can communicate with the required systems andobtain an operational profile. The bootstrap arrangement must be suitable forthe expected markets, network technologies and device behaviour.
MVNOs mustalso build integration between SGP.32 profile management and their OSS/BSSenvironment. A profile change can affect network access, products, pricing,usage collection, charging and customer support. If the eIM operates inisolation, the business may struggle to maintain an accurate view of eachdevice.
Theoperational platform should know which customer owns the device, which profilesare available, which one is active, which commercial rules apply and whathappened during each management operation.
This iswhere OSS/BSS orchestration becomes essential. SGP.32 manages an important partof the connectivity lifecycle, but it does not replace the systems responsiblefor customers, products, charging, billing, orders and support.
Why Automation Is Essential
IoTeconomics are very different from consumer mobile economics. An enterprise mayoperate thousands or millions of devices, each generating relatively littlemonthly revenue.
Manualprocesses that appear manageable during a pilot can become financiallyunsustainable at scale. Profile ordering, assignment, activation, policyenforcement, billing updates and error handling must therefore be automatedwherever possible.
Automationis also necessary because devices do not behave like smartphones. Some may beoffline when a profile-management instruction is issued. Others may havelimited battery power or connect only during scheduled intervals. A remoteoperation may need to be queued, retried or completed through several stages.
Theplatform must maintain reliable state information throughout this process. Itshould distinguish between an instruction that has been requested, one that hasreached the device and one that has been completed successfully.
Operationalteams also need clear exception handling. If a profile download fails, thedevice should not be left without usable connectivity. Recovery rules, fallbackbehaviour and support processes must be designed before the fleet is deployed.
Security, Compliance and Control
Remoteprofile management affects the identity and connectivity of a device, makingsecurity fundamental to SGP.32 deployments.
The GSMAspecification defines security functions and interfaces for the architecture,but providers must still secure the systems surrounding it. Access to the eIMmust be controlled, management instructions must be authorized and operationalactions should be auditable.
Enterprisesalso need clear governance. The platform should define who can request aprofile change, which devices can be affected and what approval is required forlarge-scale operations.
Aconfiguration error affecting one smartphone is inconvenient. A configurationerror applied to an entire fleet of utility meters, medical devices orindustrial sensors can become a major operational incident.
Regulatoryrequirements add another layer of complexity. Some countries restrict permanentroaming, require local profiles or impose rules relating to data handling andlawful access. SGP.32 may help a provider implement a localization strategy,but only when suitable local operator relationships and compliant processes areavailable.
MVNOsshould therefore treat regulatory planning as part of the connectivityarchitecture rather than a task to be addressed after launch.
Interoperability Will Determine Real-WorldSuccess
Astandardized specification creates the foundation for interoperability, butsuccessful implementation still requires testing across the complete ecosystem.
The eUICC,IPA, device, eIM, SM-DP+, network profile and operational platform must worktogether correctly. Different device types and constrained network technologiescan introduce additional variables.
MVNOsshould avoid assuming that a component described as “SGP.32-compatible” willautomatically work with every other component. They need defined test casescovering profile download, activation, deactivation, recovery, loss ofconnectivity and device restart behaviour.
Testingshould also reflect real deployment conditions. A laboratory with constantpower and strong coverage may not reveal the problems experienced by abattery-powered sensor connecting intermittently over a constrained network.
Interoperabilitymust therefore be treated as an ongoing operational discipline, not a one-timecertification exercise.
How Effortel Fits Into an SGP.32-Ready IoTStrategy
SGP.32introduces a new remote profile-management layer, but MVNOs still need a wideroperational platform to commercialize and manage IoT connectivity.
The Effortel Mobile Suite providesOSS/BSS capabilities for customer management, product configuration, serviceorchestration, charging, billing, orders and external system integration.
In anSGP.32-ready operating model, these capabilities can form the business andoperational layer around the eSIM ecosystem. They allow the MVNO to connectdevices and profiles with customers, products, commercial rules and usage.
Effortel’sintegration experience can also support the connection between telecom systems,external IoT platforms and customer environments. This is essential because thevalue of SGP.32 is realized only when remote profile management becomes part ofa complete, automated connectivity service.
For MVNOsentering the IoT market, the objective should not be to add another isolatedtechnical component. It should be to build an operating model in which devicemanagement, connectivity, charging and customer service work together.
SGP.32 Is an Enabler, Not a Complete IoTStrategy
SGP.32solves an important technical problem. It creates a standardized architecturefor remotely managing eSIM profiles across constrained IoT devices.
It doesnot, by itself, provide global coverage, guarantee portability, negotiateoperator agreements or create a profitable IoT proposition.
Thoseoutcomes depend on how the MVNO combines the specification with its networkrelationships, device ecosystem, OSS/BSS capabilities, automation, commercialmodel and operational support.
Providersthat 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 cancreate more resilient and valuable IoT services.
The changeis ultimately about control. Physical SIMs place many connectivity decisions atthe beginning of a device’s life. SGP.32 makes it possible to manage more ofthose decisions remotely as commercial, regulatory and operational conditionsevolve.
For IoTMVNOs, now is the time to define that architecture. Devices designed anddeployed today may remain active for many years. The connectivity choices madeat launch will shape what can—and cannot—be changed later.
Frequently Asked Questions
What does SGP.32 mean
SGP.32 isthe GSMA technical specification for remote eSIM provisioning and profilemanagement in network-constrained or user-interface-constrained IoT devices.
What is the difference between SGP.31 andSGP.32?
SGP.31defines 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 eSIMIoT Remote Manager, or eIM, is a component in the SGP.32 architecture thatremotely manages eSIM profile operations for IoT devices. It works with the IoTProfile Assistant and other eSIM infrastructure to execute authorizedmanagement instructions.
What is an IoT Profile Assistant?
The IoTProfile Assistant, or IPA, enables communication and profile-managementoperations between the IoT device, eUICC and eIM. Depending on theimplementation, it can reside in the device or in the eUICC.
How is SGP.32 different from consumer eSIM?
ConsumereSIM commonly assumes that a person can initiate or approve profileinstallation through a smartphone interface. SGP.32 is designed for devicesthat may have no screen, keyboard or available user and must therefore bemanaged remotely.
Does SGP.32 enable automatic carrierswitching?
SGP.32provides the technical ability to manage operator profiles remotely. Actualswitching still depends on profile availability, device compatibility, platformintegration, commercial agreements and regulatory permissions.
Does SGP.32 replace an OSS/BSS platform?
No. SGP.32manages the remote eSIM profile lifecycle. An OSS/BSS platform is still neededto manage customers, products, orders, charging, billing, usage and serviceoperations.
Build an IoT Connectivity Model That CanEvolve
SGP.32gives MVNOs a stronger foundation for managing long-lived IoT deployments, butits value depends on the systems and operating model built around it.
ContactEffortelto explore how flexible OSS/BSS capabilities, service orchestration and telecomintegration can support your IoT connectivity strategy.