Most cellular connectivity decisions are made once and then lived with for a decade. An industrial SIM soldered onto a board this year may still be transmitting in 2043, long after the person who signed the contract has moved on. That is the real risk in this category: not that you pick a bad vendor, but that you pick a vendor whose limits only become visible in year three, in a country you had not planned for, on a device you cannot physically reach. IoT Analytics, in its spring 2026 market update, reported that the number of cellular IoT connections reached 4.7 billion in 2025, representing 13.3% growth over 2024. A market that large has room for hundreds of vendors, and the differences between them are not visible on their websites.
This guide sets out the criteria that actually separate one IoT connectivity provider from another, how to verify each one before you sign, and how the decision changes depending on what you are deploying and where. It is written from the vantage point of a company that sits on the receiving end of these evaluations every month and sees which questions buyers ask, which ones they forget, and which omissions cost them later.
What “Global IoT Connectivity” Actually Means (and What It Does Not)
Global IoT connectivity is a commercial arrangement, not a technical one. No vendor owns radio networks everywhere. What a global IoT connectivity provider actually does is aggregate access to many mobile network operators, wrap that access in a management platform, a single contract and a single invoice, and take responsibility for the parts that break. The phrase “500+ networks in 180+ countries,” which is how Trafalgar Wireless describes its own reach, is shorthand for a set of wholesale agreements, not for a network the vendor built.
That distinction matters because three very different things get sold under the same heading.
Permanent roaming. A SIM issued by one operator that stays attached to foreign networks indefinitely. It is the oldest and still the most common way to deliver one SKU worldwide, and it works in most markets.
Localized or in-country connectivity. Traffic that breaks out inside the country the device sits in, either through a local profile on the SIM or through a mobile core with in-country points of presence. Latency is lower and the connection is less exposed to roaming regulation, but the footprint of genuinely localized markets is narrower than a coverage map implies.
Carrier-agnostic connectivity. A contractual position, not a feature. It means you can change which operator serves a device without changing the hardware, the platform or the vendor. A roaming agreement is not carrier-agnosticism. If the SIM can only ever present one identity chosen by the supplier, you are not carrier-agnostic, however many networks that identity can roam onto.
When you compare IoT connectivity providers, insist that each one tells you which of these three they are selling in each region you care about. Most will sell you a blend, and the blend is where the surprises live.
The Nine Criteria That Separate IoT Connectivity Providers
Every vendor in this market will claim wide coverage, a good platform and responsive support. The criteria below are the ones where answers between IoT connectivity providers actually diverge, and each is written so you can ask it as a direct question.
| Criterion | The question to ask | What a weak answer looks like |
|---|---|---|
| Coverage and network depth | Which named operators serve my top ten countries, and how many per country? | A country count with no operator names |
| Roaming legality and permanence | Where is permanent roaming restricted for my devices, and what is the local alternative? | “We cover everywhere” |
| Provisioning model | Multi-network, multi-IMSI, eUICC, or a hybrid, and who controls the profiles? | A product name with no mechanism |
| Radio technology support | Is 5G non-standalone or standalone, and where are LTE-M and NB-IoT actually live? | “We support 5G and LPWAN” |
| Management platform | Can I see the real back end, and is there an open API for every portal action? | A slide deck screenshot |
| Security architecture | Private APN, IPSec VPN, IMEI lock, static IP, and off-public-internet routing? | “Enterprise-grade security” |
| Commercial model | Pooled or per-device, overage treatment, and what is billed separately? | A per-megabyte rate with no context |
| Contract and exit rights | Minimum term, notice period, and can I move profiles off the platform? | 36 or 60 month lock-in with no exit clause |
| Support model | Who specifically answers when a device stops reporting at 2am? | A ticket queue and an SLA number |
Each of these deserves a paragraph of its own, because the follow-up question is usually where the answer changes.
Coverage and network depth. Country counts are marketing, and every IoT connectivity provider publishes one. Operator depth per country is engineering. One operator in a country means a national outage is your outage. Ask for the named operator list per market, and ask whether the SIM can attach to more than one of them.
Roaming legality and permanence. Brazil, Turkey and Russia restrict permanent roaming; the United States and Canada do not. Your provider should be able to name the restricted markets on your list without checking, and tell you what they deploy there instead.
Provisioning model. This is the single most consequential technical choice and gets its own section below.
Radio technology support. Availability is conditional on the local carrier, always. No IoT connectivity provider can change that. A provider that says LTE-M and NB-IoT are supported globally is telling you something that is not true anywhere.
Management platform. The platform is where you will spend your operational life. Treat the demo as the product evaluation, not as a sales call.
Security architecture. Ask whether devices can be isolated from the public internet entirely, and whether you control IP addressing and access policy or the vendor does.
Commercial model. Pooled data and per-device data behave completely differently at scale. Overage terms matter more than headline rates.
Contract and exit rights. IoT connectivity providers differ more here than anywhere else. A one-month minimum and a 60-month subscription are both defensible, but only one of them lets you correct a mistake in year two.
Support model. Ask who the named person is. If the answer is a queue, that is the answer.
Coverage and Roaming: How to Verify a Provider’s Map
A coverage map is a claim about where a SIM can theoretically attach. It is not a claim about where the IoT connectivity provider can support you, bill you, or fix a problem for you. Those are three different footprints, and they rarely overlap perfectly.
Verify the map in four steps.
Ask for the operator list, not the country list. For each of your top markets, request the named host operators and the technologies enabled on each. A provider that aggregates access can produce this. One that resells someone else’s aggregation often cannot.
Test before you commit. Pre-activation or free-data testing, where a small allowance per device lets you confirm attachment in the field before billing starts, turns a coverage claim into evidence. Trafalgar Wireless offers this as a Pre-Activation Service specifically so buyers can test connectivity before the meter runs.
Check the failover behavior, not just the network list. For fleet tracking across cars, trucks and ships, what matters is how quickly the modem re-selects when the primary network degrades, and whether the SIM is steered or non-steered. Ask for the re-selection logic in writing.
Confirm the commercial and support footprint separately. Ask which countries the provider can invoice in, in which currency, and which time zones its support covers. Buyers who assume a coverage map answers this question are the ones who discover the gap during an incident.
For cross-border fleets specifically, the roaming agreement behind the SIM is the thing under evaluation, not the SIM. Ask whether the agreements are the provider’s own or borrowed, how long they run, and what happens to your devices if one lapses. Trafalgar Wireless publishes a plain-language comparison of how multi-network and multi-IMSI SIMs behave that is a useful primer before you run this conversation with any IoT connectivity provider.
Multi-IMSI, Multi-Network and eUICC: Which One You Actually Need
These three terms get used interchangeably by vendors and they should not be. Here are self-contained definitions.
Multi-network SIM. One network identity that is permitted to roam onto multiple operators. The modem continuously reports available networks and signal strength, and the SIM attaches to the strongest available one. It is what most IoT connectivity providers mean when they say global SIM. Trafalgar Wireless sells this as one SIM across many networks, managed under a single price and currency. Strength: simplicity and breadth. Limit: you are roaming, with roaming economics and roaming regulation.
Multi-IMSI SIM. Two or more network identities stored on the same SIM or eSIM, with an embedded applet that detects location and selects the best profile and regional plan. The device behaves like a local subscriber rather than a visitor. Not every IoT connectivity provider offers it, so ask directly rather than assuming. This is what Trafalgar Wireless delivers as local profiles on one SIM, and it is the standard answer for markets where permanent roaming is restricted. Strength: local rates and local compliance, with switching in minutes. Limit: the supplier decides which IMSIs are loaded at manufacture.
eUICC. The hardware. A SIM whose operating system permits complete operator profiles to be downloaded and changed over the air after the device is in the field. The eSIM is the profile that sits on it, and the two words are not synonyms even though the industry treats them as such. An IoT connectivity provider that supports eUICC can change which operator serves a device without anyone touching the hardware. Remote SIM provisioning through profile changes over the air is what lets you replace an operator relationship without a truck roll. Strength: genuine carrier flexibility over a device lifetime. Limit: higher integration cost and a slower switch, because a whole profile has to download rather than an identity being selected on-card.
SGP.32. The GSMA remote SIM provisioning specification written specifically for IoT. Earlier specifications assumed either a machine-to-machine architecture managed by the operator (SGP.02) or a consumer device with a user interface and a person to tap “accept” (SGP.22). SGP.32 introduces the eSIM IoT remote Manager and the IoT Profile Assistant so that constrained, headless devices can have profiles managed remotely without a user present. Counterpoint Research describes SGP.32 as the GSMA-backed standard expected to accelerate eSIM adoption in cellular IoT.
For most global deployments the honest answer is that you need a hybrid: a multi-IMSI bootstrap profile on an eUICC platform, so the device connects the moment it powers on anywhere, and a localized operating profile is pushed remotely once it lands. That is the pattern behind In-Factory Profile Provisioning, where eSIMs ship to the factory carrying a universal bootstrap profile and the operating profile follows over the air. One global SKU leaves the line; the local optimization happens later.
Ask any candidate IoT connectivity provider three things about this: which SGP specification their platform implements today, how many carrier profiles ship pre-loaded, and whether profiles can be added after deployment without physical access to the device. The third question is the one that decides whether you are locked in.
Network Technology Fit: 5G, LTE-M, NB-IoT and the LPWAN Family
Vendors advertise the full technology stack. What matters is which radio your device supports, which the local carrier has actually switched on, and what the module market is realistically shipping.
5G. In cellular IoT this almost always means 5G non-standalone, which uses a 4G core with 5G radio. Standalone 5G, with the network slicing and ultra-low-latency features the marketing describes, is far less widely deployed. This distinction is worth pinning down in writing, because our own product reviewers have had to correct it repeatedly in draft material where “5G support” was allowed to imply standalone 5G.
LTE-M. Licensed-spectrum low-power wide-area, with enough bandwidth for firmware updates and voice, and with mobility and handover between cells. The right default for anything that moves and needs occasional larger payloads.
NB-IoT. Licensed-spectrum, very low power, very small payloads, excellent building penetration, limited mobility. Good for static meters and sensors, poor for anything crossing cells at speed. Coverage is uneven country to country, and roaming support for NB-IoT is thinner than for LTE-M.
LoRaWAN. Unlicensed spectrum, long range, tiny payloads, and no cellular contract. It is not a substitute for a cellular IoT connectivity provider; it is a different network you would run or buy alongside one, usually with a cellular backhaul.
Reality-check the plan against what is shipping. Counterpoint Research, reporting on what is actually shipping in volume, found that in 2025 Cat-1 bis emerged as the dominant technology for mass market with one out of every two modules shipped based on Cat-1 bis. If half the market is choosing a modest 4G category rather than 5G or NB-IoT, a plan that assumes universal LPWAN availability is planning against the market.
For a smart city deployment, the practical answer is usually a mix rather than a single technology: NB-IoT or LoRaWAN for static, battery-powered sensing such as parking, waste and metering; LTE-M for anything mobile such as street-level asset tracking or municipal fleets; and 4G or 5G for cameras and edge gateways that carry video. The connectivity partner’s job is to sell you all of them on one contract and one platform rather than three.
Platform and Management: What to Demand From the Connectivity Management Platform
Once a few hundred connections become a few thousand, spreadsheet tracking fails and the platform becomes the product. A credible connectivity management platform gives you real-time status per connection, activation and suspension, data limits and alerts, per-SIM diagnostics, usage analytics and granular billing, plus reseller sub-accounts if you sell on. Ask every IoT connectivity provider on your shortlist to demonstrate all of it live. Trafalgar Wireless delivers this through a single management dashboard with an open API and a carrier-agnostic design, which matters because a platform tied to one carrier’s stack cannot manage the others.
There is a simple test that separates the platforms, and it came out of an observation our founder made on an internal review call in January 2026: every vendor in this category has a management platform, but almost none of them will show you the real back end. Marketing screenshots and animated product tours are universal. Recordings or live walkthroughs of the actual interface, with real SIM records in it, are close to nonexistent.
So make the walkthrough a condition of the shortlist. Ask the IoT connectivity provider to screen-share the live platform, on a real account, and to perform four actions while you watch: suspend a SIM, set a data cap and an alert, pull a diagnostic on a device that is failing to attach, and export a usage report. Then ask which of those four are available through the API. Portal-only functions become manual work forever.
Two related questions come up constantly in evaluations.
Connectivity as a service versus traditional M2M. Legacy machine-to-machine contracts were negotiated per country, per operator, with long terms, manual provisioning and separate invoices. Connectivity delivered as a service replaces that with self-service provisioning, API-driven lifecycle management, usage-based billing and one commercial relationship covering many networks. The technology underneath can be identical; what changes is who does the operational work and how you are billed for it.
Edge versus cloud processing. This is a bandwidth and latency trade-off that lands directly on your connectivity bill. Processing at the edge, on the device or a local gateway, means you transmit events and summaries instead of raw streams, which cuts data volume sharply and keeps the device useful when the link drops. Cloud processing means simpler devices, easier model updates and much higher sustained data usage. Decide this before you size the data plan, because a video-bearing device that sends everything to the cloud and one that sends clips on trigger are different products commercially.
Commercial Terms: Pricing Models, Contract Length and Exit Rights
Published price lists are rare in this market and most IoT connectivity providers quote rather than publish, because a fair number depends on volume, geography, technology and data profile. That does not mean you cannot compare offers. It means you have to compare structures.
Pooled or dynamic plans. Data is shared across the estate and unused volume is reallocated between devices, so a few heavy devices are covered by many light ones. This suits mixed fleets and avoids per-device overage entirely when the pool is sized correctly. Trafalgar Wireless offers pooled Dynamic IoT Data Plans with no overage charges.
Pay as you use. A per-megabyte rate plus a fixed monthly SIM fee, with usage alerts. This suits low and unpredictable consumption and small pilots, and it makes the cost of a misbehaving device visible immediately.
Tiered or slab pricing. Rates step down at volume thresholds. Ask where the slab boundaries sit relative to your forecast, because a forecast that lands just under a boundary is an expensive place to be.
Beyond the rate, four terms decide the real cost, and they are the four every IoT connectivity provider should answer without hesitating. Ask whether portal access, API access, activation and suspension are billed separately or included; whether the provider throttles after a threshold; what the minimum contract term and notice period are; and what happens to your eSIM profiles if you leave. Trafalgar Wireless includes portal, API, activation and suspension in the service, does not throttle, and works on one-month minimum contracts, which is a deliberately different posture from the 36 and 60 month subscription tiers common among the large platform vendors.
Exit rights are the term buyers skip and regret. If the provider controls the eUICC profile keys, “carrier-agnostic” is a description of the hardware, not of your position. Get the exit mechanics in writing before the pilot, not after.
How to Run the Evaluation So You Get a Real Quote
This is where most evaluations go wrong, and it is the part almost no buyer’s guide covers, because it requires seeing the requests from the vendor’s side.
Two patterns repeat in the requests that reach an IoT connectivity provider’s inbox, and Trafalgar Wireless sees both every month. In one, a buyer sends a few lines: a count of SIMs, a mention of a private APN and a VPN, an average data figure, and then “can you provide the service, and what will the cost be?” Our founder’s assessment of one such request in May 2026 was blunt: it is not much information, really. A provider can quote from it, but only defensively, which means the quote will be conservative and generic.
In the other pattern, the buyer supplies name and company, the coverage model they want, monthly data per device, SMS volumes, whether they need platform access, and the size of the initial batch versus the eventual rollout. Our founder described a request in that shape, in February 2026, as pretty much perfect. It is the same amount of typing. It produces a completely different quote, from every IoT connectivity provider you send it to.
The most credible requests go one step further and specify the physical form factor and the provisioning standard up front. In April 2026 an overseas vehicle-rental operator opened with the SIM form factor and eUICC support written into the first email, alongside an initial batch and a multi-year volume several times larger. That degree of specificity told us immediately that the buyer already had a provider and was replacing one, which is exactly the kind of buyer who negotiates well.
There is a second reason to be specific. Our founder observed in April 2026 that buyers in this market typically approach three or four providers at once and lead with price, leaving very little room for discovery. If price is the first and only question, you will be sold on price, and the provider never gets to tell you the thing that would have changed your design. A precise brief buys you the discovery conversation back.
Send every shortlisted IoT connectivity provider the same brief, containing: device count now and projected over three years; the countries, ranked; monthly data and SMS per device and the peak profile; the radio technologies the module supports; the SIM form factor, including whether MFF2 is soldered; whether you need eUICC and which SGP specification; security requirements such as private APN, VPN or static IP; platform and API requirements; and your target go-live date. Ask for the quote and the operator list per country in the same reply.
How the Major Providers Compare on These Criteria
The names that come up most often in this category fall into five archetypes. Placing a vendor in an archetype tells you which of the nine criteria will be their strength and which question to press hardest.
| Archetype | Names commonly shortlisted | Typical strength | Press them on |
|---|---|---|---|
| Mobile network operators | Verizon, and the other national carriers | Network depth and latency at home; direct accountability on their own network | Multi-country depth, roaming permanence, IoT-specialist support |
| Large independent IoT connectivity providers | KORE, Wireless Logic, Aeris, Eseye | Breadth of agreements, enterprise processes, eUICC maturity | Contract length, exit rights, who your named contact is |
| Platform-led and developer-led providers | Soracom, emnify, Hologram, Onomondo | API depth, self-service, transparent tooling | Operator depth per country, restricted-roaming markets, support model at scale |
| Low-cost and prepaid-package providers | 1NCE | Predictable unit economics for low-data devices | Data ceilings, throughput, what happens when a device exceeds the package |
| Connectivity management platforms | Cisco IoT Control Center, Comarch IoT Connect, Simetric, floLIVE | Cross-carrier orchestration and lifecycle tooling | Whether they sell you the connectivity or only manage it, and subscription term |
Two honest caveats. First, every scale figure these vendors publish is a vendor claim; treat carrier counts, connection counts and certification lists as things to confirm in writing during procurement rather than as benchmarks. Ask any vendor, including this one, to confirm their current certifications and operator agreements in writing. Second, archetype is not destiny. A platform-led provider can have excellent coverage in your specific markets, and a carrier can be the right answer for a single-country deployment.
Trafalgar Wireless sits in the independent IoT connectivity provider group and positions deliberately toward operational simplicity for IoT solution providers and growth businesses rather than toward the largest enterprise programs. It offers multi-network, multi-IMSI, native single-network and eSIM data plans on one contract, with a named account manager who is also the service manager. The reasoning behind using an aggregating IoT connectivity provider at all, rather than going direct to a carrier, is set out in why buyers use an aggregator: operators optimize for consumers and large enterprises, which leaves smaller and faster-moving deployments with generalist support and thinner multi-country options.
How to Choose by Deployment Profile
The right answer changes completely with the deployment. Four profiles cover most cases.
Single-country fixed devices. Meters, vending, retail point of sale, building sensors. Prioritize latency, native network quality and price over global breadth. A native single-network plan on a direct carrier connection often beats a global roaming SIM here, and it is worth saying plainly that more coverage is not automatically better: one long-standing video telematics customer of Trafalgar Wireless runs deliberately on a single-network IoT SIM, because the deployment does not need anything else.
Cross-border fleets. Trucks, cars, ships, trailers, video telematics. Prioritize multi-network failover depth, roaming permanence across the route, and re-selection behavior. Multi-IMSI earns its place the moment the route touches a restricted-roaming market. Redundancy across at least two networks per country is the specification to write down.
Embedded OEM devices. Products manufactured once and sold into unknown markets, where the IoT connectivity provider you pick has to still make sense in a country you have not chosen yet. Prioritize eUICC, SGP.32 alignment, In-Factory Profile Provisioning and MFF2 durability. One global SKU with a bootstrap profile is the whole point; if the provisioning model forces regional SKUs, your manufacturing cost and lead times absorb the difference for the life of the product.
Industrial and private-network deployments. Energy, oil and gas, manufacturing, utilities, medical devices. Prioritize security architecture, static addressing and environmental durability. A private APN isolates devices inside the carrier’s infrastructure so they are invisible to internet scanning, which is a stronger position than a VPN that still routes over the public internet, and it deploys faster and cheaper than standing up a private 5G network. Ask the IoT connectivity provider to document the whole chain in writing. Look for private APN and VPN options combined with IMEI locking and, where the traffic is mission-critical, direct connections that avoid the public internet entirely. Industrial-grade SIMs rated from minus 40C to 105C, engineered for well over a decade in the field, are the matching hardware choice.
Frequently Asked Questions
How do I compare eSIM and eUICC suppliers for IoT deployments?
Compare on four things: which SGP specification the platform implements today, including whether SGP.32 is live or on a roadmap; how many carrier profiles ship pre-loaded on the eSIM; whether new profiles can be added after deployment without physical access to the device; and how long a profile switch takes end to end. Then ask who holds the profile management keys, because that answer determines whether you can move to another IoT connectivity provider later.
How do I evaluate an eSIM platform for power and firmware-update requirements?
Ask for the module’s measured idle current with the profile active, not the datasheet figure, and ask what the current draw looks like during a profile download. Then ask whether over-the-air profile updates and firmware updates can be scheduled inside your device’s wake window, and what happens if the device sleeps mid-transfer. For battery devices on multi-year lifespans, a provisioning event that forces an unplanned wake cycle is a real cost.
What is connectivity as a service versus traditional M2M connectivity?
Traditional M2M connectivity was bought per operator and per country on long contracts, with manual provisioning and separate invoices per market, and without a single IoT connectivity provider standing behind the whole estate. Connectivity delivered as a service puts many networks behind one contract, one platform and one invoice, with self-service or API-driven activation, suspension and policy control, and usage-based billing. The radio access can be identical; the difference is the operating model and who carries the administrative work.
Should IoT data be processed at the edge or in the cloud?
Treat it as a bandwidth and latency trade-off tied directly to the connectivity plan. Edge processing sends events, summaries and exceptions rather than raw data, which cuts monthly data volume, reduces latency for local decisions and keeps the device functional through an outage. Cloud processing simplifies the device and centralizes model updates but raises sustained data use and makes the device dependent on the link. Size the data plan with your IoT connectivity provider after this decision, not before.
What is multi-IMSI versus global roaming for vehicle telematics?
Global roaming means one network identity permitted to attach to foreign operators, with the vehicle treated as a visitor everywhere it goes. Multi-IMSI means several identities on the same SIM, switched over the air, so the vehicle presents as a local subscriber in each region with local rates and local regulatory standing. For telematics that crosses borders into markets where permanent roaming is restricted, multi-IMSI is usually the difference between a working device and a disconnected one, so confirm which of the two your IoT connectivity provider is actually supplying.
How does eUICC remote profile switching work for cross-border fleets?
The eUICC holds a bootstrap profile that gets the vehicle online anywhere it powers up. Once the fleet is deployed and the operating region is known, the provider pushes a full operator profile over the air to the eUICC, which then attaches as a local subscriber. Switching again later needs no physical access to the vehicle. The trade-off against multi-IMSI is speed: a whole profile has to download, so switching takes longer than selecting an identity already on the card.
Key Takeaways
Country counts are marketing; operator depth per country is engineering. Ask for the named host operators in your top markets and how many are available per country.
Multi-network, multi-IMSI and eUICC solve different problems. Most global deployments end up hybrid, with a multi-IMSI bootstrap on an eUICC platform and a localized operating profile pushed after deployment.
Carrier-agnostic is a contractual position, not a feature. If the supplier controls which profiles can exist on the SIM, you are not carrier-agnostic.
Radio availability is always conditional on the local carrier. Confirm whether 5G is non-standalone, and where LTE-M and NB-IoT are genuinely live on your routes.
Make a live platform walkthrough a condition of the shortlist. Suspend a SIM, set an alert, run a diagnostic and export a report while you watch, then ask which of those are available through the API.
Compare structures across IoT connectivity providers, not headline rates. Pooled versus per-device, overage treatment, what is billed separately, minimum term, and what happens to your profiles when you leave.
Send a precise brief to every provider. Device counts, ranked countries, data and SMS profiles, radio technologies, form factor, eUICC requirement, security needs and go-live date, and ask for the operator list per country alongside the quote.
Match the choice to the deployment profile. Single-country fixed, cross-border fleet, embedded OEM and industrial deployments have genuinely different right answers, and more coverage is not automatically better.
Choosing an IoT connectivity provider is a decision about who you want alongside you in year three, when a device on the other side of the world stops reporting and nobody remembers why the SIM was specified that way. The vendors who answer the nine questions above precisely, in writing, and without deflecting to a coverage map are the ones worth shortlisting. The vendors who cannot are telling you something useful too.
If you want a global IoT connectivity provider that gives IoT solution providers and growth businesses deploying devices across multiple countries one contract, one invoice and one platform for multi-network, multi-IMSI and eSIM data plans, Trafalgar Wireless will walk you through the trade-offs before you commit to any of them.
