A connectivity platform can look excellent in a sales demonstration and still become a costly constraint once 20,000 devices are active across several countries. To review IoT connectivity platforms properly, assess the operating model behind the portal, SIMs, contracts and support desk – not simply the coverage map and headline data rate.
For a connected product, mobile connectivity is not a line item to buy once. It affects device margin, customer experience, field support, security exposure, billing accuracy and the speed at which you can enter a new market. A platform that suits a UK proof of concept may be the wrong choice for a European rollout, a fleet operating on private land, or unattended equipment expected to remain deployed for ten years.
Start with the commercial reality of the service
Most platform comparisons begin with features. The better starting point is the business case. Establish how many devices you expect to activate, where they will operate, what they will transmit, and which events create expensive failure. A battery-powered water meter sending a small daily payload has different requirements from an AI camera, EV charger or autonomous vehicle transmitting diagnostics, video and safety-critical telemetry.
Ask what the first 12, 24 and 60 months actually look like. Consider activation volumes, inactive devices, seasonal peaks, roaming countries, expected device replacements and data growth. Then test the proposed tariff against those conditions. A low entry price can be outweighed by minimum commitments, pooled-data rules, permanent roaming restrictions, out-of-bundle charges, suspension fees or a contract structure that makes it difficult to move provider.
The central commercial question is straightforward: who carries the risk when real-world usage differs from the spreadsheet? Some providers offer predictable pooled plans and good cost controls. Others deliver compelling unit pricing but leave the customer exposed to usage spikes or roaming exceptions. Neither approach is automatically wrong, but it must match the product’s revenue model and risk appetite.
Review IoT connectivity platforms beyond the portal
A polished portal is useful, but it is not the platform. The real test is whether your team can control devices and resolve exceptions without opening support tickets for routine tasks. Review the full lifecycle: ordering, stock management, activation, provisioning, policy assignment, diagnostics, suspension, reactivation, replacement and retirement.
A strong platform should give authorised operational staff clear, auditable control over these actions. It should also expose the information needed to understand a failure. That means current network, registration status, last known activity, data sessions, SMS events where relevant, location indicators where permitted, and meaningful error states. If a device is offline, “not connected” is not a diagnosis.
APIs matter equally. Early-stage teams often accept manual portal work because the fleet is small. At scale, manual processes create delayed activations, inconsistent records and avoidable customer support costs. Check whether the API supports the activities your systems will need, whether it is properly documented, how authentication works, what rate limits apply and how changes are versioned. A usable API is not the same thing as an API that happens to exist.
The platform should also fit your identity and workflow model. Operations may need access to troubleshoot devices without being able to change commercial settings. Finance may need consumption and billing data without access to SIM controls. Product teams may need usage events in their own dashboards. Poor role design creates both security and operational problems.
Coverage is a test plan, not a map
Coverage maps are planning tools, not assurances of service. They seldom answer the questions that matter at the edge of the network: whether an underground meter chamber can register, whether a lorry route has continuity, whether a rural agricultural installation can transmit during poor weather, or whether a device can recover after a long period out of coverage.
Build a test plan around the actual installation environment. Test representative devices, antennas, power conditions and firmware. Include difficult locations, border areas, vehicle movement, low-signal indoor spaces and the countries in which you genuinely expect to operate. Record not only whether a device connects, but connection time, retry behaviour, power draw, latency where relevant and recovery after a network change.
Technology choice changes the assessment. LTE-M and NB-IoT can be appropriate for long-life, low-power deployments, but availability, roaming support and module behaviour vary by market. Standard LTE or 5G may be necessary for richer data, moving assets or lower-latency applications, but may introduce higher power and cost demands. Satellite may provide resilience for remote assets, while private LTE or private 5G can give an organisation far more control on a defined site. There is no universal winner.
Inspect the network and roaming model
“Global connectivity” is a marketing phrase until the provider explains exactly how it is delivered. Establish whether the offer uses a single international IMSI, multiple IMSIs, eSIM profiles, local breakout, steering arrangements or a mixture. Each design has implications for coverage, latency, resilience, regulation and troubleshooting.
Permanent roaming deserves close attention. Some countries restrict long-term use of foreign SIM profiles, while operator policies can change. A deployment may work at launch and face migration pressure later. If a market is strategic, ask for a clear local-connectivity path rather than relying on a verbal assurance that it will be handled when the time comes.
Resilience should be examined at more than one level. Multi-network access can help, but it does not remove every common point of failure. Ask how network selection works, whether steering can be overridden, what happens when a preferred network is unavailable, and whether there are restrictions on networks or radio technologies. For critical services, understand the provider’s incident process and escalation route before signing.
Security, controls and data routing need scrutiny
An IoT SIM is part of the attack surface. The platform should support controls appropriate to the use case, such as private addressing, controlled access point names, IP allowlists, usage limits, alerting, and restrictions on services that a device should never use. The appropriate design depends on the application. A payment terminal, remote camera and environmental sensor should not inherit the same policy by default.
Data routing is often underestimated. Where does traffic break out? Can it be routed to your cloud environment or security gateway? What are the latency and regulatory implications? How are credentials managed, and how are logs retained? These questions become particularly material for public sector, defence, critical infrastructure and organisations processing sensitive operational data.
Do not treat connectivity security as separate from device management. SIM controls, eSIM profile management, firmware updates, certificates and device identity need a coherent operating model. If responsibilities are split across several suppliers, make the hand-offs explicit. Otherwise, every incident becomes a debate about whose system is at fault.
Put support through a realistic failure scenario
Platform support is easiest to judge before a contract is signed. Present a scenario: 500 devices in one country stop passing data after a network change; a high-usage alert appears overnight; devices activate but cannot reach the application server; a customer needs an urgent replacement in a new market. Ask who owns the case, what evidence they will provide, how escalation works and what service levels apply.
The answers reveal whether you are buying access to a connectivity estate or a partner capable of helping operate one. For a low-value, low-risk sensor estate, standard support may be entirely sensible. For connected mobility, charging infrastructure, security systems or a revenue-generating service, the cost of slow diagnosis can be far greater than the monthly connectivity charge.
Also assess reporting quality. Finance needs bills that can be reconciled. Operations needs usable exception reports. Product teams need data that can inform device behaviour and customer communications. If reporting requires repeated spreadsheet manipulation, the platform is transferring work and risk to your team.
Make the decision with a weighted scorecard
A disciplined comparison should score each candidate against the requirements that drive your programme, rather than treating every feature as equal. Weight coverage and technology fit highly where field performance is decisive. Weight API capability and operational controls where you expect rapid scale. Weight local-market options, security architecture and support where the service is regulated or mission-critical.
The scorecard should include commercial terms, lifecycle operations, network model, tested coverage, integration, security, service management and exit arrangements. Record evidence, not just supplier claims. A proof of concept, API review, contract mark-up and reference discussion will tell you more than a feature checklist.
Exit arrangements are worth addressing early. Confirm SIM ownership, number portability where relevant, device compatibility, eSIM migration options, data export and termination charges. Changing connectivity provider across a large installed base is rarely painless. The aim is not to plan for failure; it is to avoid becoming commercially or technically captive by accident.
A good platform decision gives your product team room to build, your operations team the tools to act, and your finance team a cost model they can trust. Select the provider that performs under your likely operating conditions, then retain enough technical and contractual control to respond when those conditions change.
