Half your SIMs finished the month at 4% of their allowance. A handful hit the ceiling on the 19th and stopped reporting. You paid for both outcomes. The wasted data was billed and the overage was billed on top, and the devices that went quiet were the ones doing the most work.
This is what per-SIM data plans produce at fleet size. The fix is not a bigger plan per device. It is a different unit of allocation.
Data pooling combines the data allowance of every SIM in a fleet into one shared allocation. A device drawing 400MB a month and a device drawing 2MB a month both take what they need from the same pool. No individual SIM has a cap it hits on its own, and the headroom left by low-use devices covers the high-use ones.
The pool is sized on average usage per SIM multiplied by the number of active SIMs, set at subscription and adjusted as the fleet grows. Usage is monitored against the pool with threshold alerts, rather than against thousands of individual limits.
Pooling sounds like a consumer family plan, and marketing copy from connectivity providers leans on that comparison because it is quick to explain. The mechanics look similar. The operating conditions do not.
A family plan has five lines, one country, one carrier, one bill payer who notices immediately when something runs out. Each user has a screen, and a human behind the screen who tops up when prompted. That is the entire model.
An IoT fleet has none of those things.
Overage charges arrive on an invoice, so they get attention. Stranded data does not appear anywhere. It is allowance that was purchased, allocated to a SIM, and expired unused because it sat on the wrong device.
In a fleet with mixed device types, stranded data is routinely the larger of the two numbers. The way to see it is to pull the usage distribution across the fleet for a full month and compare the median SIM against the top decile. If the median device uses a fraction of its allowance while the top decile breaches, you are paying twice for one problem, and both halves of the bill are avoidable.
The cost argument is the obvious one. The operational argument is the one that holds even when usage across a fleet is uniform.
One allowance to manage instead of thousands. Forecasting happens against a single pool with a single trend line, not a distribution of per-SIM limits.
New devices inherit the pool. A device shipped into a new market draws from the same allocation on day one. No per-device provisioning decision, no per-country plan to choose.
Alerts become meaningful. A threshold on a single shared pool is a signal worth acting on. Thousands of per-SIM alerts are noise that teams learn to ignore, and ignored alerts are how fleets end up finding problems from customer tickets.
Usage anomalies surface. A device drawing 30 times its normal volume is visible against a pool baseline. The same device hidden inside its own generous per-SIM allowance is not.
Three limits are worth stating before anyone builds a business case on this.
A pool sized on optimistic usage estimates affects every SIM when it runs out, not one. Shared allocation shares the downside as well as the headroom, so the sizing conversation deserves real numbers from a real month of data.
Pooling improves how data is allocated. It does nothing for coverage. A device with no viable network in a market has a connectivity problem, and no allowance structure fixes that.
Pooling is also not a security measure. Shared data allocation says nothing about where traffic goes once it leaves the radio.
Keeping device traffic off the public internet is a routing decision handled by private networking, and controlling what each device reaches is a separate policy decision again.
The IXT Global Data Pool combines the allocation across every SIM in the fleet, across countries and across the 600+ mobile networks One SIM reaches. High-use devices draw from the headroom of low-use devices, and the pool is monitored in the IXT CMP with threshold alerts and live per-SIM usage rather than a 24 to 48 hour reported delay.
Pascal Technologies runs a 5GB shared pool across their vessel fleet for over-the-air software updates and performance monitoring, with vessels moving between countries and no per-vessel overage to reconcile at the end of the month.
For fleets with uneven usage, pooling removes both overage charges and stranded allowance. For a fleet where every device draws an identical, predictable volume, the saving is smaller and the management argument does the work instead.
Every SIM drawing on it is affected until the pool is topped up. This is the trade-off for sharing the headroom, and it makes accurate sizing at setup the decision that matters most.
With a global IoT SIM, yes. The pool is not bounded by market, so a device in Poland and a device in Norway draw from the same allocation.
Average measured usage per SIM multiplied by the number of active SIMs, using a full month of real data rather than a datasheet figure. Devices behave differently in the field than they do on a bench.
Yes, at subscription level. The devices need no change.
Pull one month of per-SIM usage and sort it. Find the median, the top decile and the total allowance purchased. The gap between what you bought and what you used is the size of the problem, and it is a number you already have.
This guidance is based on real IoT and OT deployments in regulated industries including energy, utilities, and industrial environments.
IXT designs and operates secure connectivity architectures where:
The patterns described here reflect how these environments are secured in practice, not theoretical models.
This article was written by the IXT Connectivity and Security team.
IXT operates a full MVNO core network and delivers secure IoT connectivity across 190+ countries and 600+ mobile networks. The team works directly with industrial, utilities, and infrastructure operators to design and secure large-scale IoT and OT deployments.
Their focus is on network-level Zero Trust architecture, SIM-based identity, and secure device communication without relying on VPNs or endpoint agents.