You can have a device showing full signal bars and still not get reliable data out of it. That usually confuses teams at first. On paper, everything looks fine: coverage is in place, the SIM is active, and the device is connected to a network. But packets don’t move the way they should. Data arrives late or not at all.
That gap comes down to something most people don’t think about early on: how the network is selected.
An IoT SIM card doesn’t simply connect to the strongest signal available. It follows a set of rules. Some of them are stored on the SIM itself. Others come from the modem or from agreements between operators. The network you use is the result of all those layers interacting in the background, often without your knowledge.
In practice, that means two devices in the same location can behave differently. One stays stable. The other struggles, even though both technically have coverage.
The question then becomes, "Which network will the device ultimately select, and what are the reasons behind this choice?”
That selection process is quiet, but it shapes everything that happens after deployment: uptime, data consistency, and how much time your team spends troubleshooting things that shouldn’t be breaking in the first place.
Why Network Selection Matters in IoT Deployments
Most teams start with coverage maps. It makes sense: you look at where your devices will operate, check which countries or regions are supported, and move forward assuming connectivity is handled.
What tends to get missed is how the device actually ends up on a specific network once it’s out there.
Coverage only indicates that a network exists at a location. It doesn’t tell you whether your device will connect to the right one or stay on it when conditions change. In practice, the selection logic can push devices toward networks that are technically available but not performing well at that moment. That’s when things start to drift.
You see it in small ways at first.
- Data arrives later than expected.
- Some messages don’t come through.
- Then it compounds: telemetry becomes inconsistent, alerts are delayed, and systems that depend on real-time input start to behave unpredictably.
None of it looks like a clear failure, which makes it harder to diagnose.
The business side feels it quite quickly. Support requests increase. Teams spend time chasing issues that don’t have a single obvious cause. In some cases, devices need to be rebooted or manually reconfigured just to recover connectivity that should have been stable.
The tricky part is that the issue usually doesn’t show up during initial testing. Everything works in a controlled setup or a limited number of locations. The problems appear later, when devices are deployed at scale and exposed to different network conditions.
By then, changing how network selection works is no longer a simple fix. It’s tied into the SIM, the device behavior, and sometimes even the agreements behind the connectivity itself. That’s why it’s worth understanding early, even if it doesn’t look like the most urgent piece at the start.
Automatic vs Manual Network Selection
When a device connects, it doesn’t really “decide” in the way people expect. The device adheres to its built-in logic, which typically falls into one of two modes: automatic or manual.
Most setups never touch the second one.
Automatic Network Selection
Qlmost everything runs on automatic selection.
The modem powers up, scans for available networks, and then goes through its internal checklist. The SIM, the modem, and the operator's configuration provide some of that logic. You don’t really see that happening; it’s just part of the connection process.
What matters is that the device picks a network based on a mix of factors, not just signal strength. Sometimes that choice makes sense. Other times, it sticks to a network that technically works but isn’t performing that well.
That’s where things get a bit counterintuitive. You might have a stronger signal from another network nearby, but the device won’t switch because it’s following a different priority.
Manual Network Selection
Manual selection exists, but it’s not something you see often outside of very specific setups.
Here, the device asks the modem for a list of available networks and then attempts to connect directly to one. There are standard commands for this process, but the details depend on the hardware and firmware you’re working with.
On paper, it sounds useful. You can force a device onto a network you trust or avoid one that caused issues before. In reality, it introduces a lot of moving parts.
Not every network will accept the connection, even if it shows up in the list. When that happens, the device needs to fall back to something else, and that logic has to be handled properly. If it isn’t, the device can just sit there without reconnecting, even though networks are available.
That’s why manual selection is usually limited to edge cases. It gives you more control but also more responsibility, and at scale, that trade-off tends to work against you rather than in your favor.
What Influences Network Selection
It’s easy to assume the device just connects to the strongest signal, and that’s the end of it. In reality, there are a few layers involved, and they don’t always point in the same direction. The final choice comes from a mix of SIM settings, modem behavior, operator rules, and whatever is happening in the environment at that moment.
SIM Configuration (IMSI logic)
The SIM plays a bigger role than most people expect. It carries the IMSI, which is basically the identity the network sees when the device tries to connect. That identity determines which networks are even allowed in the first place.
With a traditional setup, there’s usually one IMSI tied to one operator, along with a list of partner networks. So the device isn’t choosing from everything available; it’s choosing from a limited pool.
If those networks aren’t performing well in a given location, the device has little room to adjust. In many cases, performance also depends on the cellular technology being used, which is why it’s worth understanding the differences. For example, in this breakdown of NB-IoT vs LTE-M.
That’s where you start to see situations where coverage exists, but the device still struggles simply because it can’t step outside that predefined list.
Modem and Firmware Behavior
Once the SIM defines what’s allowed, the modem takes over. It scans the area, detects available networks, and ranks them according to its logic. Signal strength is part of that, but not the only factor.
Firmware settings can shift priorities in ways that aren’t always obvious. Some modems prefer stability over switching. Others try to reconnect to previously used networks even if they’re no longer the best option. These decisions happen fast and quietly, but they shape how stable the connection feels over time.
Network-Side Steering
There’s also input from the network side. Operators have established agreements that influence the direction of devices. This process is often referred to as steering.
From the operator’s perspective, it helps manage costs and traffic. From the device’s perspective, it can mean being pushed toward a network that isn’t the strongest or most stable at that moment. It often works fine, but not always in the ones that matter most.
Real-World Conditions
Then there’s everything you can’t fully control. Signal strength varies by location, as well as by building materials, terrain, and even how the device is positioned.
Congestion plays a role, too. A network can look good during testing and behave very differently once more devices are active in the same area. Add antenna quality into the mix, and you get a setup where two identical devices can perform differently just because of how they’re installed.
So even when coverage looks solid on paper, performance can still vary quite a bit once devices are out in real conditions.
The Forbidden List and Its Impact on Connectivity
There’s a detail in how devices handle failed connections that doesn’t get much attention, but it can quietly cause problems later.
When a device attempts to connect to a network and is rejected, it receives a reason code from that network. In some cases, the modem takes that as a signal to avoid the same network going forward and adds it to what’s called a “forbidden list.” From that point on, the device simply skips it during future scans.
At first glance, that behavior makes sense. If a network refuses the connection, there’s no point in retrying immediately. The issue is that network conditions aren’t fixed. A network that rejected a device earlier might become available again later: different load, different conditions, or even just a temporary issue that’s no longer there.
The device, however, doesn’t always account for that. Once a network is on the forbidden list, it may stay there longer than it should. So even if that network becomes the best option again, the device won’t attempt to reconnect.
This is where things start to feel inconsistent in the field. A device might move through an area where connectivity should improve, but instead it stays on a weaker network or struggles to maintain a stable connection. From the outside, it’s not obvious why.
Over time, this can lead to data gaps or longer recovery times after disruptions. Not because there’s no coverage, but because the device has effectively narrowed its own options and isn’t revisiting them when conditions change.
How to Evaluate Network Selection in an IoT Provider
By the time you’re comparing providers, most of them will say they “cover” the regions you need. If you're in that stage, it’s worth looking at how different options compare in practice (e.g., in this guide on choosing an IoT connectivity provider for deployment). The harder question is how devices behave once they’re actually there, moving between networks, dealing with a weak signal, or recovering after a drop.
It helps to look at network selection as a practical capability, not just a technical detail. You’re trying to understand how much control you have, how much the system handles on its own, and what happens when conditions aren’t ideal.
A few questions tend to reveal more than a long feature list:
- Can devices switch between networks within the same country, or are they tied to a single operator and its partners?
- Is the selection process fully automatic, or does it require manual configuration at some point?
- What happens when a network goes down or starts behaving poorly: do devices move away from it or stay connected and degrade?
- Is there a way to block certain networks if they consistently underperform in specific locations?
- And the most important one: can you actually test all of this before rollout, or are you expected to trust the setup based on documentation alone?
Why Testing Matters Before Scaling
Connectivity often appears stable during early testing, especially when it’s tested in one or two locations. The problems usually show up when devices are deployed more widely, in places where network conditions shift throughout the day or behave differently than expected.
That’s why testing shouldn’t be treated as a formality. It’s one of the few chances to see how the SIM behaves in real conditions: how it selects networks, how quickly it recovers, and whether it stays consistent over time.
Running a small batch of devices across different locations gives you a much clearer picture than any coverage map. It also helps catch edge cases early, before they become harder to manage at scale.
How Keepgo Handles Network Selection
Keepgo SIMs are designed to work across multiple networks within each country, not just one preferred option. The selection happens automatically, with the goal of keeping devices on the most stable connection available at any given moment.
Under the hood, the connectivity relies on Telefónica’s global network. That brings a certain level of consistency, especially for deployments spanning multiple regions, because the underlying infrastructure is designed for large-scale operations rather than for isolated local coverage.
A lot of the design decisions stem from issues that tend to show up after deployment: uneven coverage, unexpected downtime, or devices behaving differently depending on where they’re installed.
Before committing to a full rollout, there’s an option to test the setup using a SIM kit. That allows you to run your own checks on provisioning, connectivity, and compatibility with your devices and platform.
Talk to an IoT expert. We’ll guide you through testing connectivity with Keepgo IoT SIM cards in real conditions before deployment.
