Most IoT resellers reach the same point about 18 months in. The carrier portal that worked fine for the first handful of accounts stops keeping up: a customer wants pooled data, another wants their own branding on the platform, a third is deploying devices in a country the carrier covers poorly. The portal has no answer for any of it. That is when the question of what kind of infrastructure to run the business on becomes urgent.
The distinction between a carrier portal and an IoT Connectivity Management Platform is not academic. It determines what the business can offer, at what margin, and under whose brand.
A carrier portal is the operational interface a mobile network operator provides to its wholesale customers. It is built to manage connectivity on that carrier’s network, on that carrier’s pricing, in the countries that carrier covers.
Carrier portals handle the essentials: SIM activation, usage monitoring, basic suspension and reporting. For a single-carrier deployment in one geography, that coverage is sufficient.
Beyond that scope, the constraints compound. Other carriers’ SIMs are invisible. There is no pricing layer: what the carrier charges is what you work with, and you cannot build your own plan structures or billing logic on top of it. Reporting reflects the carrier’s data model. When a device goes offline because the carrier has a regional outage, the portal shows you the problem but gives you no way to route around it.
There is also the branding reality. Every customer-facing interface in a carrier portal carries the carrier’s identity. You are reselling access to someone else’s platform. The customer relationship reflects that, because the customer can see it too.
An IoT Connectivity Management Platform (IoT CMP) is a centralized operational layer built for connectivity providers, resellers, and enterprises managing SIM and eSIM fleets at scale. It sits above the carrier network rather than within it, which is what makes multi-carrier management, custom billing, and white-labeled customer environments possible from a single interface.
The scope is broader than a carrier portal by design. A CMP manages SIM and eSIM lifecycle from provisioning through deactivation, across multiple carriers, with billing logic, customer account management, and reporting all in one environment. Every customer’s devices are visible from one login, regardless of which network they use. Pricing is yours to set. Invoices go out under your brand.
The multi-carrier dimension matters operationally as well as commercially. When a device on one network loses signal, a CMP with carrier-switching capabilities can redirect it to an alternative network in real time, through an automation rule, a manual action, or an API call. A carrier portal cannot do this because it has no visibility beyond its own network.
For MSPs, API access changes how connectivity fits into the stack. SIM provisioning triggers automatically when a device is deployed through an RMM workflow. Usage data flows into client reporting without manual exports. Threshold alerts fire in the monitoring tools the MSP already uses, not in a separate portal that someone has to remember to check.
The margin conversation is where carrier portals and CMPs diverge most visibly. A carrier portal reflects the carrier’s billing model. You see what you consumed and what you owe. There is no mechanism to build your own pricing on top of it, create pooled data plans for your customers, or run prepaid wallet logic for smaller accounts.
A CMP includes a billing engine. You define the plan types: prepaid bundles, PAYGO, pooled data across a customer’s device fleet, subscription models with trial periods. You set the retail pricing. The CMP calculates what your customers owe based on the plans you created, generates the invoice under your brand, and integrates with your finance system via API. The carrier receives one wholesale invoice from you. Your customers receive invoices that reflect your pricing structure.
For a reseller managing fifty accounts across multiple verticals, the difference is whether you run a connectivity business or a connectivity resale arrangement.
White labeling in the context of a carrier portal is usually limited to removing a logo from certain views, or a co-branded experience on some screens. The underlying system remains the carrier’s.
A full white label IoT platform works differently. Your logo, your domain, your colour scheme, your communication templates. Customers log into an environment that looks and functions like your product, because operationally it is. The management interface, the customer-facing eSIM store if you run one, the automated notifications, the invoices: your identity throughout.
For a reseller building a managed connectivity proposition rather than distributing SIMs, the brand layer is not cosmetic. It is what the customer relationship is built on.
A CMP manages active connections: usage, alerting, activation, suspension. An eSIM Orchestrator works one layer lower, controlling which carrier profile sits on a device and executing changes to that profile over time based on location, regulation, or policy. Vendors often use both terms loosely, which makes it worth asking specifically what a platform does at the profile layer before committing to it.
A carrier portal has no eSIM Orchestration capability. It manages profiles on that carrier’s network and cannot execute profile switches across operators. A standard CMP without eSIM Orchestrator integration manages active connections competently but does not control the profile layer: it can suspend a SIM but cannot move a device from one carrier’s profile to another without a separate provisioning workflow.
A platform that combines both functions handles the full lifecycle from profile provisioning to billing in one environment. For resellers managing device fleets that operate across multiple countries with different regulatory environments, that integration matters. A device entering a market where permanent roaming is restricted needs a local carrier profile. Without eSIM Orchestration, that means a manual step or a separate SIM product per market. With it, the profile switch happens automatically based on location and pre-configured rules.
SGP.32 is the GSMA standard for remote SIM provisioning in IoT devices. It introduces the eIM (eSIM IoT Remote Manager) as the server-side component that manages eSIM profile lifecycle across device fleets, without physical access, user interaction, or manual steps. The IPA (IoT Profile Assistant) is the device-side component that executes what the eIM instructs.
The reason SGP.32 is relevant to the CMP discussion is that it creates provisioning capabilities a carrier portal cannot support and that a CMP without eIM integration can only partially address. Zero-touch provisioning, where a device powers on in the field and receives its operational carrier profile automatically, requires eIM infrastructure. So does over-the-air profile management for deployed devices across multiple operators.
Enterprise and automotive IoT buyers are already evaluating SGP.32 readiness in vendor selection. Soracom described SGP.32 readiness as a defining criterion in enterprise IoT procurement at Mobile World Congress 2026. A reseller whose platform cannot support SGP.32 deployments will encounter that question in sales conversations before long.
The practical issue is not just whether a CMP supports SGP.32 in principle, but whether the eIM is integrated with the connectivity management interface or sits in a separate system that needs to stay in sync. Fragmented architecture at the platform level recreates the operational overhead the CMP was supposed to eliminate.
A carrier portal is appropriate when the business is starting out, the deployment is geographically contained, and the customer base is small enough that the carrier’s reporting and billing model covers what you need. There is no operational reason to run a full CMP on a portfolio of three accounts in one country.
The signals that a CMP is the right next step tend to arrive together rather than one at a time. A customer asks for a data plan structure the carrier portal cannot support. A second customer wants to see their own devices in a branded environment. A third is deploying in a country where the primary carrier has poor coverage and there is no fallback. Any one of those is manageable as a one-off. When they arrive at the same time across different accounts, the carrier portal stops being a tool and starts being a constraint.
The timing of the move matters more than most resellers anticipate. Migrating an established customer base from a carrier portal to a CMP means moving SIMs, reconfiguring accounts, and rebuilding billing logic while keeping existing customers operational. Resellers who make the switch before the carrier portal is visibly limiting do it at a pace they control. Those who wait until accounts are at risk do it under pressure.
The carrier portal shows you what you have. It does not show you what the ceiling is.
Running a connectivity business through a carrier portal means the pricing is fixed, the billing model is the carrier’s, the brand is not yours, and the platform cannot grow beyond what that carrier supports. The accounts you are not winning because your product looks like a resale arrangement, the margin you are not capturing because you cannot set your own pricing, the customers who leave because the service feels like a commodity: none of that shows up in the carrier portal’s reporting.
A CMP does not solve those problems automatically. It provides the infrastructure to address them. What you do with that infrastructure is the business.
What is SGP.32? SGP.32 is the GSMA standard for remote SIM provisioning designed specifically for IoT devices. It defines the technical architecture for managing eSIM profiles across connected device fleets without physical access, user interaction, or manual configuration. Where earlier eSIM standards were designed for smartphones or legacy M2M deployments,
In our previous blog we mentioned IP SEC VPN as great option. Lets dive into this more specific! In today’s interconnected world, the importance of secure and reliable communication between machines cannot be overstated. M2M IP SEC VPN stands at the forefront of this technological revolution, offering a robust solution
In this article we will explain what is an IoT Connectivity Management Platform (CMP), and answer the most frequently asked questions (FAQ) about cloud based IoT portals. Learn more about the features and benefits of a cloud based IoT management portal and how it can help you control IoT assets
TNF Solutions is an independent Full MVNO and eSIM Orchestrator operating across 900+ networks in 200+ countries. TNF’s IoT portal combines eIM-based SGP.32 provisioning, SIM lifecycle management, and multi-carrier orchestration in a single white label platform for IoT resellers, MSPs, device manufacturers, and system integrators.
What is the main difference between an IoT CMP and a carrier portal?
A carrier portal gives you operational access to one carrier's network: SIM activation, usage monitoring, and basic reporting within that carrier's system. An IoT CMP sits above the carrier network and manages SIMs across multiple carriers, with your own billing engine, white-labeled customer environments, and API access to your existing systems. The structural difference is that a CMP is built for the connectivity provider, not for the carrier's wholesale customers.
Can I use an IoT CMP if I only work with one carrier?
Yes. Even on a single carrier, a CMP provides capabilities the carrier portal does not: your own pricing and plan structures, white-labeled customer accounts, billing logic, and API integration with your existing tools. If you expand to multi-carrier coverage later, the platform already supports it.
What is an eSIM Orchestrator and how does it relate to a CMP?
A CMP manages active connections: usage, alerting, activation, and suspension. An eSIM Orchestrator manages the profile layer beneath that, controlling which carrier profile is active on a device and executing changes based on location, regulation, or policy. A platform that combines both functions handles the full lifecycle from profile provisioning through billing in one environment. TNF's IoT portal combines CMP and eSIM Orchestrator capabilities.
Do I need SGP.32 support in my CMP?
It depends on what your customers are deploying. If they run headless IoT devices across multiple countries, SGP.32 support enables zero-touch provisioning and automated carrier profile switching without physical access to deployed devices. Enterprise and automotive IoT buyers are already asking about SGP.32 readiness in procurement conversations. Whether your current platform supports it is worth knowing before it comes up in a sales process.
When does it make sense to move from a carrier portal to an IoT CMP?
Earlier than most resellers do it. The operational work of migrating an established customer base from a carrier portal to a CMP is significant, and doing it while accounts are at risk is a worse position than doing it while the business has room to absorb the transition. If you are building a managed connectivity business rather than a resale arrangement, the CMP is the right infrastructure from the point where that distinction starts to matter commercially.