Your eSIM can switch operators. But what will your team have to rebuild?
Mikk Lemberg
An IoT device stops sending data. Support opens the connectivity management platform and looks for the last session.
Is the subscription active? Which network did it use? Has it reached a data limit? Did an automation rule suspend it? Can support restart the service, or does someone need to open a ticket with the operator?
Elsewhere in the company, an API activates connectivity when a device leaves the factory. Usage alerts feed the on-call process. Finance allocates connectivity costs to customers or business units. Account managers check whether a deployment is online. An audit log records every change made by a user or automation.
These routines are easy to overlook because they were not built at once. They accumulated as the fleet grew.
Then the company starts planning for SGP.32. The proposition sounds simple: if the current operator is no longer the right choice, enable another profile remotely. No SIM swap, site visit, or hardware redesign.
The profile switch may indeed be that simple. What comes after it often is not.
The new operator may report usage through a different portal. Existing alerts may stop because their data source has changed. API calls written for the old connectivity service may no longer work. Finance may receive a second invoice in a different format. Support may lose the session history it normally uses to diagnose a problem.
Before you plan the profile switch, ask a second question:
Which parts of connectivity management will continue working, and which will we have to set up again?
That question tells you more about the practical value of an SGP.32 service than the number of profiles in its catalogue, and it's one of the six questions we recommend asking any SGP.32 provider before committing.
A profile switch is not an operations handover
SGP.32 standardizes remote profile management for unattended IoT devices.
An eIM can send a profile operation to the IoT Profile Assistant, or IPA, associated with a device. The enterprise can download, enable, disable, or delete operator profiles without replacing the SIM or visiting the device.
This solves a difficult problem. A product expected to remain in the field for ten years no longer has to use the same operator profile for its entire life.
But the profile is only what lets the device authenticate and connect. It does not contain everything the company uses to manage that connection:
- subscription status and remote controls;
- data and SMS usage;
- session and network-event records;
- usage limits, alerts, and automation rules;
- rate plans, cost allocation, and invoices;
- API integrations and webhooks;
- users, permissions, and audit history;
- the diagnostic information used by support.
Those functions usually come from operator systems connected to a connectivity management platform, or CMP. When you enable another profile, its operator does not automatically inherit your old alerts, understand your billing rules, or start sending session data to the API your product already calls.
The device can reconnect successfully while the work around it breaks.
SGP.32 handles the profile change operation. It does not perform an operations handover from one connectivity service to another.
What has your company built around its current connectivity service?
At the beginning of a deployment, the CMP can look like a dashboard for checking a few SIMs. A few years later, it is connected to work across the company.
Support uses status and session records to tell the difference between a device fault and a network problem. Engineering uses APIs to activate, suspend, and inspect subscriptions. Operations groups connectivity by customer, product, country, or deployment, then applies limits and automation rules. Finance uses usage records and rate plans to understand cost. Security teams control access and review the audit history.
The CMP may also hold the mapping between EIDs, ICCIDs, device serial numbers, customers, and deployment locations. Even when another system is the master record for the physical device, the CMP often becomes the system of record for its connectivity: whether the subscription is active, what it consumed, what it cost, and what changed.
This is why changing CMPs involves more than learning a new dashboard. Someone has to decide what happens to:
- the integration that activates a subscription during manufacturing;
- the webhook that reports unusual usage;
- the groups and permissions used by regional support teams;
- the limits applied to different products or customers;
- the reports finance expects at the end of the month;
- the historical sessions used to investigate recurring faults;
- the identifiers that connect a SIM record to a device in another system.
You may choose to rebuild some of these. You may run the old and new systems side by side. You may accept that some history or automation will not carry over. The important part is knowing that this work exists before the profile changes, not discovering it after devices are already using the new operator.
Three different promises hide behind “multi-carrier”
Most SGP.32 services promise multi-carrier choice, orchestration, or a single pane of glass. The phrase alone does not tell you what your teams will have to rebuild.
1. The new profile comes with a new CMP
The device begins on Operator A. Usage, alerts, controls, and invoices appear in Operator A's platform. When the device moves to Operator B's profile, those functions move to Operator B's platform.
The profile switch is remote, but the company now has another portal, API, data model, invoice, and support process. Historical sessions remain in one system while current sessions appear in another. Engineering either rebuilds its integration or maintains both. Support first has to identify which operator a device uses before it knows where to investigate.
The enterprise can change profiles. Each change can still create another connectivity-management setup.
2. One interface switches profiles, but the operator systems remain separate
An orchestration service may let the enterprise download and enable profiles from several operators in one interface. The operational data and actions behind those profiles can still live in the individual operator platforms.
This is genuine profile flexibility. It does not mean that usage, sessions, alerts, and billing have been integrated into the same management service.
3. The operators are already part of one managed connectivity service
The third model starts before anyone needs to switch a profile. The provider has already negotiated with multiple operators and integrated their connectivity services into one CMP.
When the customer moves between profiles included in that service, the operator changes underneath. The customer keeps the same workspace, API entry point, billing process, and support relationship. The device remains part of the same managed fleet.
That does not happen because SGP.32 transports the old setup. It happens because the provider has already done the commercial and technical integration work for each operator.
1oT already uses this model with SGP.02
1oT has used the third model with M2M eSIM since 2019. Customers use connectivity from multiple telecom partners through 1oT eSIM and manage those subscriptions in 1oT Terminal.
Today, 1oT has pre-integrated connectivity from 14 telecom partners. Customers do not receive 14 separate portals to manage. The available subscription status, usage, sessions, controls, and commercial information are brought into 1oT Terminal.
1oT Terminal supports both SGP.02 and SGP.32. A company with devices from both eSIM generations can manage their connectivity in the same platform rather than create one set of routines for the existing fleet and another for new SGP.32 devices.
There is an important limit to this promise. Operators do not all expose identical data or controls. One may provide detailed session records quickly; another may update usage less often or support fewer remote actions. A common CMP can normalize shared functions and make the remaining differences visible. It cannot create information that the underlying operator does not provide.
Nor can an entirely new operator be made part of the service by simply uploading its profile. Its commercial agreement and technical data sources still have to be integrated.
What matters is whether the profiles you intend to use are already connected to the records, controls, and routines your company needs after the switch. Counting CMP boxes on an architecture diagram will not tell you that.
Don't forget to plan what happens after the profile changes
SGP.32 removes much of the physical work from changing connectivity. It does not automatically remove the organizational and software work.
Before choosing a service, picture an ordinary incident after the new profile is active. A customer reports that a device is offline. Where does support look for its last session? Can the existing API inspect or restart the subscription? Will the same usage limit protect it from an unexpected bill? Where will finance see the cost? Does its earlier connectivity history still make sense beside the new records?
These questions reveal whether you are planning one change or two. In the first, the profile changes while the systems around the fleet keep working. In the second, the profile changes and several teams have to rebuild the way they monitor, control, support, and account for connectivity.
.avif)
.avif)
.avif)
