A single pane of glass (SPOG) for IoT connectivity management is one interface, with one set of workflows, that lets a team see and control every SIM, eSIM, carrier and invoice in a fleet. It is not a prettier dashboard. The test is simple: if you can activate, suspend, re-plan or switch a device on any carrier without logging in to that carrier’s portal, you have one. If you can only look, you do not.
This guide explains what a real single pane includes, what goes wrong without one, how eSIM and SGP.32 change the picture, how to judge cost and security claims, and what to ask a platform vendor to prove. For the wider category of connectivity management platforms and how vendors compare, see our guide to leading IoT connectivity management platforms.
Last verified 2 November 2026.
What a single pane of glass means in IoT
Cellular IoT fleets rarely sit with one operator. A fleet that began with one carrier in one country picks up a second carrier for a new market, an eSIM supplier for a new device line, and a satellite or LPWAN option for remote sites. Each brings its own portal, its own API, its own billing format and its own idea of what “suspended” means.
A single pane of glass sits above those relationships. It does four jobs:
- Aggregate: pull inventory, usage and status from every carrier into one record per SIM or device.
- Normalize: translate each carrier’s states, units and currencies into one model, so “active” and “megabytes used” mean the same thing everywhere.
- Act: run the same lifecycle operations (activate, suspend, change plan, swap profile) through one interface or API, whichever carrier sits underneath.
- Record: keep an audit trail of who changed what, when and under which rule.
Aggregation is the easy half. Showing data from several sources on one screen is a reporting project. Normalizing it and acting on it across carriers is what makes a platform worth buying.
What breaks when connectivity is managed carrier by carrier
The cost of fragmentation shows up in five places. None needs a statistic to recognize; a team running several carriers will know them.
Time lost to portal-hopping
Checking fleet status means logging in to each portal, exporting a file and merging the files by hand. Every new carrier adds another login, another export format and another set of training notes.
Billing nobody can reconcile
Invoices arrive in different currencies, cycles and layouts. Overages are found when the bill lands, and SIMs left active in decommissioned devices keep charging until someone notices. Finance spends days a month on matching instead of analysis. Our IoT connectivity cost guide covers where connectivity spend goes.
Security gaps between portals
Every portal has its own role model, its own audit-log format and its own way to set IP allow-lists or private network rules. Consistent policy is hard to enforce when the controls differ by carrier, and a single missed setting leaves one slice of the fleet exposed.
Slow incident response
When a device goes quiet, the cause could be the carrier, the SIM configuration or the device. Without one view, support staff open several systems to find out, and often hand the question between vendors. A single queue with the SIM history beside it shortens that loop.
Slower expansion
Entering a new country usually means a new carrier agreement, a new portal and new internal procedures. Growth becomes a procurement and training project instead of a configuration change. Our guide to single-carrier IoT risks covers the opposite problem: why relying on one network is also fragile.
The five layers of a real single pane of glass
When you evaluate a platform, check it against these layers. A product that covers only the first is a dashboard.
| Layer | What it does | What to check |
|---|---|---|
| Inventory and identity | One record per SIM or eSIM profile, with the ICCID or EID tied to the device and the carrier | Can it show a physical SIM, an older M2M eSIM and a newer eSIM in one list? How fresh is the data from each carrier? |
| Policy engine | Rules for cost limits, usage thresholds, coverage failover and profile switching | Can rules act automatically, and can a human approve the high-impact ones? |
| Lifecycle automation | Activation, suspension, reactivation, plan changes and bulk operations through one interface or API | Run a bulk action across two carriers and check the result on the carrier side. |
| Observability | Connection history, signal, usage anomalies and alerts by SMS, email or webhook | How soon after a carrier event does it show here? Can an alert trigger an action? |
| Security and audit | Role-based access, multi-factor sign-in, audit trail, private network controls | Can you export the audit log? Can you scope a user to one region or customer? |
Two further capabilities usually sit alongside the layers. Billing consolidation brings every carrier invoice into one format with cost per SIM. Integration connects the platform to your CRM, ERP, ticketing or order system through an API so provisioning follows business events instead of spreadsheets. Both belong on your checklist; neither replaces the five layers.
Reporting layer or control plane
The most common mistake in buying is accepting a reporting layer as a single pane of glass. The two behave differently when something goes wrong.
| Situation | Reporting layer only | Control plane |
|---|---|---|
| A SIM is burning data | You see it and then log in to the carrier | You suspend it, or a rule suspends it, from the same screen |
| A plan no longer fits | You export usage and rebuild the plan in the carrier portal | You change the plan through one workflow across carriers |
| A device needs a new network | You raise a ticket with the carrier | You switch the profile remotely if the SIM supports it |
| An invoice looks wrong | You compare PDFs by hand | You see line-level cost per SIM next to usage records |
| Audit asks who changed a plan | You search several portals and emails | You pull one audit log |
Read vendor demos with this table open. Ask to see the right-hand column performed live, on a test fleet that includes more than one carrier.
Where eSIM and SGP.32 fit
eSIM changes what “switch carrier” costs. With a physical SIM, a carrier change means a new card and often a site visit. With a remotely managed eSIM, it can be a profile change sent over the air. For IoT, the GSMA’s SGP.32 eSIM IoT technical specification defines how that works for devices with no screen or user.
Earlier remote provisioning standards fit IoT poorly. The M2M specification (SGP.02) relied on a server-driven model tied to a subscription manager, which carried operator dependencies. The consumer specification (SGP.22) assumes a person scans a QR code or taps an app, which a smart meter cannot do. SGP.32 keeps the consumer ecosystem’s download infrastructure and replaces the person with a server-side eSIM IoT Remote Manager (eIM). On the device, an IoT Profile Assistant (IPA) carries out the instructions the eIM sends.
| SGP.02 (M2M) | SGP.22 (consumer) | SGP.32 (IoT) | |
|---|---|---|---|
| Who triggers a change | Server-driven, via a subscription manager | The user, by QR code or app | The eIM, through the IPA on the device |
| Works without a screen | Yes, operator-dependent | No | Yes, by design |
| Device owner control | Limited | Per user | Through the eIM the owner chooses |
The practical point for a single pane of glass: SGP.32 makes carrier switching technically possible, but it does not decide when to switch, who is allowed to, what it costs or how you prove it happened. Those are control-plane jobs. Doing them yourself means running something close to a virtual operator, with carrier contracts, multi-currency billing and interoperability testing. Most enterprises are better served by a platform that does it. For the standards in detail, read our SGP.22 vs SGP.32 guide, and for the orchestration layer, eSIM orchestration for global IoT.
Your fleet probably has all three generations at once: physical SIMs from early deployments, older M2M eSIMs and new SGP.32-capable modules. The platform has to show them in one inventory and support moving between them in phases rather than a single cutover. Our IoT SIM cards guide explains the form factors.
Cost control: what to ask for, and what not to believe
Vendors often promise large percentage savings. Treat those as claims to test, not facts; the saving depends on your plans, your usage pattern and how wasteful your current setup is. What a single pane of glass reliably gives you is the visibility to find waste yourself:
- Idle but billed SIMs. Lines in devices that were retired, returned or never installed.
- Plan mismatch. SIMs on plans far larger or smaller than their real use, which means overages or paid-for allowance nobody uses.
- Pooled usage. Where carriers allow pooling, unused allowance on one SIM covers overage on another.
- Early warning. Alerts when a SIM or pool approaches a limit, instead of a surprise on the invoice.
- Line-level allocation. Cost by customer, business unit or region, so the right budget owner sees it.
Before you buy, export three months of invoices and usage from your current carriers and work out your own baseline: cost per active SIM, number of idle SIMs, overage spend. Ask the vendor to rerun that data through their platform. That tells you far more than any percentage on a slide. The IoT connectivity cost guide and the IoT connectivity comparison help you set the baseline.
Local rules, mixed networks and longer device lives
Three pressures make unified control harder to avoid than it was a few years ago.
Local connectivity requirements. Some countries restrict or discourage permanent roaming, so a device that stays in one market for years may need a local profile rather than a foreign one. Rules differ by country and change, so confirm with the regulator or a local advisor before deployment. A platform that can hold the right profile per market and keep records of which was used and why makes that manageable.
Changing networks. Operators are retiring older 2G and 3G networks in some markets while rolling out newer ones in others, so a device built to last many years may meet several radio generations. Choosing the right technology matters: see NB-IoT vs LTE-M vs 5G RedCap. Satellite options are becoming part of the mix for remote sites too, which adds yet another network to manage.
Long device lives. A meter or industrial sensor may stay in the field for a decade or more, longer than most carrier contracts. The ability to move networks without touching the hardware is what protects that investment. For trend context, read our IoT connectivity trends and global IoT connectivity in 2026.
Risks of centralizing, and how to limit them
Putting everything in one place creates its own risks. Plan for them before signing.
| Risk | Why it happens | What limits it |
|---|---|---|
| Platform lock-in | You trade several carrier dependencies for one platform dependency | Exportable data, documented APIs, contract terms for exit and transition help |
| Concentrated privilege | One system can enable, disable or delete profiles for the whole fleet | Multi-factor sign-in, role-based access scoped by region or customer, approval steps for high-impact actions, audit trail |
| Over-automation | A badly written rule fires across thousands of devices at once | Staged rollout on a small group first, rate limits, a human approval gate on fleet-wide actions |
| Mixed-fleet gaps | Older SIMs support fewer operations than newer eSIMs | Written list of what each SIM type can and cannot do through the platform |
Device-side security still matters. Connectivity control does not protect a device with weak credentials. For baselines, see NIST’s IR 8259 on foundational cybersecurity activities for IoT device manufacturers and ETSI’s EN 303 645 standard for consumer IoT security.
How to evaluate a platform: tests to run
Ask for proof, not slides. These checks separate a real single pane of glass from a reporting layer.
| Test | What a pass looks like |
|---|---|
| Run a bulk activation across two carriers | One action, results visible on both carriers, failures listed per SIM |
| Suspend a SIM by rule | A threshold triggers suspension and the audit log shows the rule, the time and the result |
| Load a month of invoices from two carriers | Cost per SIM in one currency and format, with idle SIMs flagged |
| Trace one alert to an action | An alert reaches an inbox or webhook and can start a lifecycle action |
| Restrict a user to one region | The user sees and acts only on that region’s devices |
| Export your data | Inventory, usage and audit history leave in a documented format |
| Switch an eSIM profile | Done remotely on a test device, with the before and after state recorded |
Also ask how often each carrier’s data refreshes, which carriers connect through live integrations and which through file uploads, and what happens to your data and SIM inventory if you leave. The platform comparison lists criteria you can reuse in a request for proposal.
Where Spenza fits
Spenza is an operator-neutral connectivity platform. Its TelecomHub page describes access to 180+ carriers through one REST API and one dashboard, with the option to use Spenza’s network or bring your own. It shows an API call for setting automatic routing on a SIM, eSIM provisioning, and machine-learning monitoring of carriers with alerts. The ControlHub page covers custom plans, usage tracking by plan, device, reseller and customer, alerts before a line runs out of allowance, and activating, suspending or changing the plan of one line or a whole fleet from the dashboard or the API.
Run the evaluation tests above against Spenza as you would any other vendor, including the carriers and SIM types in your own fleet.
Conclusion
A single pane of glass is worth having when it gives you control, not just a view. It normalizes data from every carrier, runs lifecycle operations once across all of them, consolidates billing, and leaves an audit trail. eSIM and SGP.32 make switching networks technically simple, and a control layer decides when, by whom and under what rules. The risks of centralizing (lock-in, concentrated privilege, runaway automation) are real but manageable with exportable data, strict access control and staged rules.
Start with your own baseline: the number of carriers and portals, the idle SIMs, the invoice hours, the incident delays. Then run the tests above on a mixed test fleet before you commit. For where to go next, compare vendors in our connectivity management platform guide.
Frequently asked questions
What is a single pane of glass for IoT connectivity management?
It is one interface and one set of workflows for every SIM, eSIM, carrier and invoice in an IoT fleet. It normalizes data from each carrier, shows device status in one place, and lets teams act (activate, suspend, change plans, switch profiles) without opening each carrier portal. A view that only displays data does not meet that bar.
Is a single pane of glass just a reporting dashboard?
No. Reporting shows you a problem; control fixes it. If you still have to log in to a carrier portal to suspend a SIM, change a plan or dispute an invoice line, you have a dashboard, not a single pane of glass. Ask a vendor to run an action from the interface and show the carrier-side result.
Can we keep our existing carrier contracts?
Often yes, but it depends on the platform and on each carrier’s interface. Ask whether the platform can connect to your current carriers on your existing commercial terms, and what it needs from each one (API access, billing data feeds, SIM inventory). Spenza lists bring-your-own-network among its options; confirm the details for your carriers.
How does eSIM and SGP.32 change multi-carrier management?
SGP.32 lets a server-side eSIM IoT Remote Manager (eIM) download, enable, disable and delete operator profiles on devices without a person at the device, which makes carrier changes a remote operation instead of a SIM swap. It does not manage your contracts, billing or policy. You still need a layer that decides when to switch and records who did it.
What should a single pane of glass cost-control feature include?
At minimum: invoice data from every carrier in one format, cost per SIM or per device, detection of SIMs that are billed but idle, usage alerts before a pool or plan limit is hit, and an audit log of plan changes. Whether it also lowers your bill depends on your current plans, so measure your own baseline first.
What are the risks of putting all connectivity in one platform?
You can swap carrier lock-in for platform lock-in, concentrate privileged actions in one system, and let a badly set rule act on the whole fleet at once. Reduce these with exportable data and open APIs, role-based access and multi-factor sign-in, approval steps on high-impact actions, and staged rollouts of any new rule.
Does a single pane of glass support both physical SIMs and eSIMs?
It should. Fleets usually contain physical SIMs, older M2M eSIMs and newer SGP.32-capable modules at once. A good platform shows all of them in one inventory and lets you move from physical SIM to eSIM in phases. Ask for a demonstration with a mixed test fleet, not a slide.
