The connectivity problem hiding in smart bins and heart monitors

Dominic Norton from Spitfire Network Services highlights the connectivity problem hiding in smart bins and heart monitors

A drone surveying farmland. A cardiac monitor in a care home. A van full of groceries is crossing rural postcodes. A public bin that messages the council when it’s full. These use cases span sectors and serve completely different purposes, but they all rely on the same unseen foundation: uninterrupted, intelligent connectivity.

As the Internet of Things (IoT) becomes more embedded across industries, connectivity is often treated as a given. But assumptions about network coverage, data routing, and SIM behaviour can cause problems at scale. When you’re operating hundreds or thousands of endpoints across variable geographies, the gaps start to show.

And that’s where architecture matters.

Behind every successful IoT deployment is a stack of connectivity decisions that influence everything from service continuity to cybersecurity posture. And despite the attention given to endpoint design and data analytics, the connective tissue – the network layer – still doesn’t receive the strategic consideration it deserves.

Not all multi-network SIMs are the same

Multi-network SIMs are widely used to address coverage challenges, especially where a single provider can’t offer reliable service across all locations. But the term itself is misleading. Many organisations think they’re getting a SIM that automatically connects to the best available signal, but in practice, it doesn’t always play out like that.

Unsteered multi-network SIMs, in particular, come with trade-offs. These SIMs don’t favour one network over another, which sounds ideal in theory. But in reality, network selection is governed by the 3GPP standards that at first prioritise availability, not signal quality or throughput. That means a device may connect to a network that’s “available” but not optimal – or, worse, stay connected to a deteriorating service while better options are ignored.

Roaming agreements (or the lack thereof) add another layer of complexity, with SIMs at risk of being disconnected or barred from networks without notice. Add unpredictable latency, and opaque failover logic, and it’s clear that “multi-network” does not inherently mean “reliable.”

Dual IMSI SIMs can offer more control and predictability

A more sophisticated approach is available in the form of Dual IMSI SIMs. These SIMs contain two profiles: a primary home IMSI and a secondary fallback using an adequate but less optimal multi-network solution similar to that of competitor single-IMSI SIMs. Unlike unsteered SIMs, Dual IMSI technology provides a framework for more consistent, policy-driven behaviour.

The primary IMSI can be optimised for cost and latency, ensuring that devices default to the most suitable network in typical conditions. If the signal drops or becomes unavailable, the secondary IMSI activates. Some Dual IMSI offerings complicate matters by using a different IP address for each IMSI. However, at least one service provider provides a single fixed IP address across both IMSIs, so potential users just need to be careful to ensure that product offerings match their specific needs.

Critically, the Dual IMSI single IP address solution enables consistent IP allocation and predefined routing rules across both profiles. That means less configuration work, fewer surprises, and smoother handovers in the field.

Public routing creates unnecessary exposure

Connectivity isn’t just about staying online: it’s about where your data travels once it leaves the device.

Many commercial SIM solutions route traffic over the public internet, which introduces unnecessary exposure. T his is how devices become discoverable and data becomes intercepted.

For sectors handling sensitive or regulated information – such as healthcare, finance, legal, and logistics – that exposure carries significant risk. But even outside regulated industries, poor visibility into how and where data is travelling can impact everything from performance to compliance.

Routing traffic through private, controlled infrastructure significantly reduces the attack surface. Whether it’s MPLS integration, direct cloud interconnects, or secure tunnelling via fixed lines, private routing ensures that device traffic stays invisible to external threats and remains manageable from a central point of control.

Managing at scale means managing centrally

As the IoT estates grow, operational simplicity becomes just as important as technical resilience. If your team is manually switching APNs, troubleshooting rogue SIM behaviour, or juggling different dashboards for different networks, something’s gone wrong in the design phase.

No wonder, then, that there is increasing demand for private network environments that support unified provisioning, monitoring, and policy enforcement across all devices – regardless of location or access network. Especially where endpoint fleets span geographies, use cases, or business units.

In all cases, consistency matters. If a bin sensor in Bristol and a camera in Carlisle behave differently depending on which SIM profile is active, that inconsistency can quickly become a support burden. The ability to keep IP ranges consistent across IMSIs, automate failover logic, and monitor performance centrally is what makes the IoT viable at scale.

More than a SIM

The early days of the IoT focused on the devices themselves: what they could measure, detect, or report. But now that these devices are everywhere, we need to think of connectivity as a design decision, more than just an implicit or obvious feature.

Whether you’re managing autonomous vehicles, wearable tech, or smart street infrastructure, the real value of the
IoT lies in continuity, control, and confidentiality. And that depends not just on what’s at the edge, but on everything that sits between device and destination.

Ultimately, your IoT deployment is only as intelligent as the infrastructure that supports it.

Please Note: This is a Commercial Profile

This work is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.