Connectivity decisions rarely feel important at the time they’re made. A pilot of fifty devices works fine on a single network with a standard SIM and no particular visibility tooling, because at that scale, almost anything works fine. The decisions that matter only become visible once a deployment scales past the point where manual attention can paper over the gaps. By then, most of them are expensive to unwind.
These are the nine that come up most often, and what tends to catch teams out about each one.
1. Choosing single-network coverage because it looked sufficient in testing
A single carrier relationship is simpler to set up and often cheaper on paper. It also means a device’s connectivity is entirely dependent on one network’s coverage, capacity, and reliability in every location it operates. This rarely shows up as a problem during testing, which usually happens in one location with strong coverage. It shows up once devices are deployed across regions with genuinely different coverage profiles, at which point switching to a multi-network architecture means re-provisioning an entire fleet rather than making a configuration change.
2. Treating security as something added after the connectivity works
It’s a natural sequence: get the device connecting reliably first, then think about security. The problem is that retrofitting security onto a live fleet is considerably harder than designing it in from the start. Device authentication, traffic isolation, and endpoint filtering are connectivity-layer decisions, not application-layer ones, and adding them after devices are already deployed in the field means touching infrastructure that’s already running rather than configuring it before launch.
3. Mismatching low-power technology to the actual use case
NB-IoT and LTE-M exist because standard cellular connectivity assumes a device with reasonably generous power and data availability, which describes plenty of IoT devices and excludes plenty of others. A battery-powered sensor expected to run for years on a single charge needs a connectivity technology designed around infrequent, small data transmissions, not a general-purpose cellular connection optimised for throughput. Getting this wrong doesn’t usually break the deployment immediately. It shows up months later as batteries drain faster than the business case assumed.
4. Underestimating what physical SIM logistics cost at scale
A physical SIM is simple for ten devices. For ten thousand devices manufactured across multiple facilities and shipped to multiple markets, physical SIM logistics become a genuine operational cost: procurement, insertion, replacement when something changes, and a supply chain dependency that has nothing to do with the device’s actual function. eSIM, built on eUICC architecture, removes most of this by allowing connectivity profiles to be provisioned and updated remotely. Teams that don’t consider this early often find themselves managing a physical logistics problem that a different SIM technology decision, made at the start, would have avoided entirely.
5. Not planning for network sunsets
Legacy 2G and 3G networks are being decommissioned by carriers on their own timelines, not the deployment’s. A device architecture built around a specific network generation, without a path to newer standards, inherits a fixed expiry date that has nothing to do with the device’s actual remaining useful life. This is a particularly expensive mistake for long-lifecycle deployments, where the device is expected to keep working for years after the network it was designed around has stopped being supported.
6. Discovering problems through customer complaints instead of monitoring
Without real-time visibility into SIM and device connectivity status, the first sign of a problem is usually a support ticket or a customer noticing something isn’t working. At small scale, that’s manageable. Across a large fleet, it means every connectivity issue is discovered reactively, after it’s already affected someone, rather than proactively, before it becomes visible externally. A connectivity management platform with real-time monitoring turns this around, but only if it’s built into the architecture from early on rather than added once the support queue is already full of connectivity complaints.
7. Locking into an architecture that makes switching providers expensive
Every connectivity decision that ties a fleet tightly to one provider’s specific implementation, rather than to open standards, makes switching more expensive later. This isn’t an argument against committing to a provider. It’s an argument for understanding, upfront, how much of the architecture is portable if the relationship needs to change, and how much would need to be rebuilt from scratch. eUICC-based eSIM, for instance, is inherently more portable than a proprietary provisioning approach, because it’s built on an open standard rather than a single vendor’s implementation.
8. Assuming test-environment data usage will match field conditions
A device tested on a strong, stable connection uses data differently from the same device operating with intermittent connectivity, retries, and roaming. Firmware updates, reporting frequency, and network handoffs all affect actual data consumption in ways that rarely show up in a controlled test environment. Teams that size their data plans based on test-environment usage often find field usage runs meaningfully higher, sometimes enough to affect the underlying commercial model of the deployment.
9. Choosing a connectivity provider on price alone
Coverage and cost are the two numbers that are easiest to compare between providers, which is exactly why price-led decisions are so common and so often regretted. The questions that actually predict long-term satisfaction are less visible upfront: does the provider operate its own network core, or is there another layer behind them? Is there a platform for visibility and control, or does every change require a support request? Is security built into the connectivity architecture, or does it need to be added separately? A slightly higher headline price attached to direct network ownership and platform-level control is frequently cheaper, in practice, than the lowest quote from a reseller several layers removed from the actual infrastructure.
What these nine have in common
None of these are complicated technical problems. They’re planning decisions that looked reasonable at a small scale and stopped being reasonable once the deployment grew. The common thread is designing connectivity around what a device needs today, rather than what it will need across its full deployment lifetime, across the markets it will eventually operate in, and at the scale it will eventually reach.
FAQs
Why does single-network coverage cause problems later if it works during testing? Testing usually happens in a location with strong coverage on one network. Once devices deploy across regions with different coverage profiles, single-network architecture exposes gaps that multi-network access would have avoided, and switching afterward means re-provisioning the whole fleet.
Is eSIM worth the added complexity compared to physical SIM? For deployments with long device lifecycles or multi-market manufacturing, eSIM’s ability to provision and update connectivity remotely typically outweighs the setup complexity, especially compared to the ongoing cost of physical SIM logistics at scale.
How much does data usage really differ between testing and field deployment? It varies by use case, but roaming, retries, firmware updates, and reporting frequency all affect real-world data consumption in ways a controlled test environment doesn’t capture, so field usage commonly runs higher than test-based estimates.
What’s the biggest risk of choosing a connectivity provider on price alone? Missing the underlying questions that predict long-term reliability and flexibility: whether the provider operates its own network core, whether there’s platform-level visibility and control, and whether security is built into the architecture rather than added separately.
