If you are building a connected product and you have reached the point where you need to pick a SIM provider, the honest question underneath all the marketing is usually narrower than the one you started with. It is rarely “who has the best coverage.” It is something like: who can give me carrier-agnostic eSIM and eUICC for devices I will never physically touch again, at a price that stays predictable when my fleet goes from hundreds to tens of thousands.

That is a harder question than it looks, because most providers answer it with a coverage map and a data-plan grid, and coverage maps hide the parts that actually decide whether a deployment succeeds. Two providers can both claim reach in 180 or 190 countries and still behave completely differently the day a device lands in a market that restricts permanent roaming, or the day you need to suspend three thousand SIMs through an API instead of a support ticket.

So treat provider selection as a list of questions you ask before you sign, not a feature comparison you skim. This is that list. It is vendor-neutral by design, and the criteria are ordered roughly the way they bite: the ones near the top surface early in a pilot, and the ones near the bottom tend to surface after you have already scaled, and it is expensive to switch.

What an IoT SIM Provider Actually Is

Before the checklist, one definition because the category name is misleading. An IoT SIM provider is usually not a mobile network operator. Most are connectivity providers or IoT MVNOs: they do not own spectrum, they aggregate access across many operators’ networks and wrap it in software, security, and support. That aggregation is the point. It is what lets a single SIM reach hundreds of networks instead of one carrier’s footprint, and it is why the questions below are less about radio and more about software, contracts, and lifecycle.

A few terms recur through the checklist, so here they are in plain form:

• eSIM: in common usage, an embedded SIM, often the MFF2 chip soldered onto a board rather than a card you slot in and out.
• eUICC: the underlying capability that lets a SIM hold and switch between multiple operator profiles over the air. eUICC can live in a soldered chip or in a plastic card, so eSIM and eUICC are related but not the same thing.
• Multi-IMSI: a single SIM carrying two or more network identities (IMSIs), with an on-SIM applet that picks the best one for where the device is, so the SIM can behave like a local card in more than one place.
• Private APN: a dedicated, closed access point that keeps your devices off the public internet and under your own IP and access rules.

With those in hand, here is what to ask.

1. How Real Is the Coverage, and How Is It Delivered

Country counts are the least useful numbers on a provider’s site. Ask how the coverage is delivered, because the mechanism decides what happens at the edges.

A multi-network SIM roams onto the strongest available network in each location, which gives you wide reach through a single roaming agreement. A multi-IMSI SIM carries several network identities and switches between them, so it can present as local in markets where a single roaming profile would struggle. eUICC goes further and lets you provision a genuinely local operator profile after the device is already in the field. Most serious deployments end up using a blend.

The reason this matters more than the headline number is permanent roaming. Some countries restrict or prohibit devices from roaming indefinitely on a foreign SIM. Brazil and Turkey are the standard examples, and enforcement in both has tightened rather than loosened; Turkey moved in 2025 to require eSIM provisioning through local operators, and trade coverage has tracked how permanent roaming has gone from a quiet operational risk to a live compliance issue for global fleets. So the coverage question is really two questions: how many networks, and what does the provider do specifically in the markets where roaming is not allowed. If the answer to the second is vague, the country count is decoration.

For fleet tracking in particular, one more coverage detail earns its place: whether a single SIM can reach multiple networks within one country, not just across borders. A truck that loses signal on one carrier and cannot fail over to another is a truck you cannot see.

2. Does It Support eSIM, eUICC, and the SGP?32 Standard

If your devices are embedded and hard to reach, remote provisioning is not a nice-to-have; it is the difference between a firmware-style update and a service truck. Ask whether the provider supports eUICC and where it sits on the newer IoT provisioning standard.

The relevant standard is GSMA SGP.32, published in May 2023 and built specifically for IoT rather than for phones. It splits the provisioning job so that constrained devices can have profiles downloaded, enabled, disabled, and deleted remotely without the device having to carry a full consumer-style provisioning stack. The GSMA’s own SGP.32 specification for eSIM in network-constrained IoT devices describes the eUICC architecture and the remote-management interfaces it introduces. The practical caveat, and providers will not always volunteer this, is that operator support for SGP.32 is still maturing. So the useful question is not “do you support SGP.32” as a yes/no, but “what can I actually provision remotely today, in which markets, and what still needs a local relationship.”

A cheaper tell: ask what happens to a device’s connectivity if you need to change carriers three years into deployment. If the answer requires touching hardware, eUICC is either absent or not really wired up.

3. Can You Automate the Lifecycle Through an API

This is the criterion that separates a provider you can scale on from one you will outgrow. At a few hundred SIMs, you can manage connectivity by hand. Once hundreds become thousands, manual management breaks, and the questions become operational: can you activate, suspend, resume, rename, group, and diagnose SIMs programmatically, in bulk, without a human in the loop?

Ask specifically:

• Is there a documented, open API, or only a portal?
• Can you set data limits and usage alerts per SIM or per group through that API?
• Can you pull real-time status, location, and usage for a device rather than waiting for a report?
• Can you run diagnostics and suspend a misbehaving SIM the moment you spot it, at scale?

Automation is also where cost leaks or holds. A SIM that you can suspend the instant a device goes dormant is a SIM you are not paying full freight on. If lifecycle actions are gated behind support tickets or extra fees, model that friction into your total cost before you commit, not after.

4. Security: Private APN, VPN, Static IP, and Device Locking

Security is where off-the-shelf connectivity and serious IoT connectivity separate, because most connected devices ship with weak built-in defenses and depend on the network to compensate. Four capabilities are worth confirming line by line.

A private APN gives you a dedicated, closed network that isolates your devices from public internet traffic, with your own IP addressing and your own access policies. A site-to-site IPSec VPN encrypts the tunnel between your network and the provider’s points of presence. Static or fixed private IP addressing lets you reach and manage devices reliably instead of chasing rotating addresses. IMEI locking binds a SIM to a specific device so a pulled SIM is useless in anything else. These are not exotic. For regulated deployments in healthcare, payments, or utilities, they are frequently the baseline.

Running these well, across a fleet, is where a lot of teams stall, because a private APN and fixed IP scheme is easy to describe and fiddly to operate at scale. A handful of specialist providers run it as a managed service rather than leaving you to assemble it. One of them, Trafalgar Wireless, builds its M2M SIM cards and IoT connectivity around exactly this pattern: private APNs with customer-controlled IP addressing and access policies, site-to-site IPSec VPN across a global points-of-presence backbone, and IMEI locking, all managed for solution providers through a single connectivity platform with a dedicated service manager rather than a ticket queue. For teams deploying medical devices, trackers, or industrial sensors that need secure carrier-agnostic connectivity out of the box, that combination of security posture and hands-on managed support is the specific thing to price against doing it yourself.

The general point stands regardless of provider: confirm which of these four you get by default, which cost extra, and which the provider operates for you versus hands you to configure.

5. Which Pricing Model Fits Your Traffic

Pricing is where the mismatch between a provider’s model and your traffic pattern quietly turns into overspend. There is no universally cheapest model; there is only the one that fits how your devices actually behave.

The two common shapes:

• Per-SIM or pooled data: you buy a shared pool across the fleet, and quiet devices subsidize busy ones. This suits large fleets with uneven, mostly low usage, and it removes the sting of individual overages when one device spikes.
• Per-MB or pay-as-you-use: you pay for what each device consumes, usually plus a monthly SIM fee. This suits predictable, low-data devices where a pool would leave you paying for headroom you never touch.

The questions that actually protect the budget are about the edges. What happens on an overage, a throttle, a surcharge, or nothing. Is there a minimum contract term, and how long. Are portal access, API calls, activation, and suspension billed separately or included? Can you test connectivity on a device before billing starts? Vague answers on overages and minimum terms are the most common source of a bill that does not match the quote.

6. Which Network Technologies You Actually Need

Not every device needs the same radio, and paying for the wrong one is common. The cellular IoT families exist because different devices have genuinely different needs.

NB-IoT and LTE-M are the low-power wide-area cellular technologies, both standardized by 3GPP in Release 13 and designed for small, battery-constrained devices sending modest amounts of data. 3GPP’s own overview of the cellular Internet of Things and how NB-IoT and LTE-M were designed for low-power machine communication explains why licensed-spectrum technologies like these offer control and quality assurance that unlicensed alternatives cannot. NB-IoT suits stationary, deep-indoor, very-low-data sensors. LTE-M handles mobility and a bit more throughput, which makes it the better fit for trackers and anything that moves. 4G LTE and 5G carry the higher-bandwidth work, like video telematics and dashcams.

The catch worth asking about: availability. LTE-M, NB-IoT, and standalone 5G are not live everywhere; they depend on local carrier support, and much of the current 5G footprint is non-standalone rather than full standalone. So the useful question is not “do you support NB-IoT” but “is NB-IoT available on your networks in the specific countries where I deploy?” A technology you cannot actually get in your market is not coverage.

7. What the Support and SLA Terms Really Commit To

Support is easy to underweight during selection and expensive to underweight in production. When a fleet goes dark, the thing that determines how long it stays dark is who picks up and what they are contractually on the hook for.

Ask the unglamorous questions. Do you get a named contact who understands your deployment, or a general queue? What are the stated response and resolution targets, and are they in a contract or a brochure? Is support handled by IoT specialists or a generalist call center? Managed-service models, where the provider actively monitors your estate and flags problems before you notice, cost more up front and tend to cost far less across a multi-year deployment than the ticket-queue alternative. Contract terms belong here too: a long lock-in with weak support is a bad trade at any headline rate.

8. Does the Management Platform Give You One Pane of Glass

You will live in the platform more than anywhere else, so evaluate it as a daily tool, not a demo. The core test is whether it unifies everything or fragments it.

Look for one place to see and control the whole SIM estate: real-time device and usage visibility, activate and suspend controls, data limits and alerts, diagnostics, billing, and, if you resell, sub-accounts. If SIMs live in one system, APNs in another, and billing in a spreadsheet, that fragmentation becomes your operational overhead, and it grows with the fleet. The platform question is not “is there a dashboard,” it is “can one person see the whole estate and act on it without switching tools.”

9. When to Lock In a Provider

Timing is a real criterion, not an afterthought, because connectivity is one of the hardest things to change after a device ships. The SIM form factor, the provisioning approach, and the carrier relationships are baked into hardware and firmware decisions you make early.

Engage a connectivity provider during hardware design, not after. The choice between a plastic card and a soldered MFF2 chip, whether the design supports eUICC, and which radios the module includes all constrain your provider options later. Bring the provider in while those are still decisions rather than facts. The corollary: favor a provider and a contract that let you start small and scale, with short minimum terms and a real path from pilot to production, so an early commitment does not become a cage when your requirements shift, which for most IoT products they will.

Frequently Asked Questions

What is the difference between eSIM and eUICC in IoT?

eSIM usually refers to a physical form factor, most often the MFF2 chip soldered permanently onto a device board. eUICC refers to a capability: the ability of a SIM to securely hold and switch between multiple operator profiles over the air. The two overlap but are not identical, because eUICC can live in a soldered eSIM or in a removable plastic card. For an embedded device you cannot easily reach, the eUICC capability is what lets you change carriers remotely, and that is usually what matters more than the form factor label.

Do I need a provider that supports SGP.32 yet?

It depends on how long your devices live and how likely your carrier needs are to change. SGP.32 is the GSMA’s IoT-specific remote provisioning standard, and it is designed to let you move operator profiles without per-device manual work. Operator support for it is still maturing, so for a short-lived or single-market deployment, you may not need it today. For a long-life, multi-market fleet, it is worth choosing a provider on a credible path toward it, and asking exactly what can be provisioned remotely now versus later.

How do I compare private APN options between providers?

Look past the label at what you actually control. A meaningful private APN gives you your own IP addressing, your own access and firewall policies, the option to block public Internet traffic entirely, and fixed private IPs so you can reach devices reliably. Then ask who operates it: some providers hand you the configuration, others run the APN and the associated VPN and IP scheme as a managed service. For a small team, the managed option often removes more risk than the feature list suggests, so weigh the operational model alongside the capabilities.

The One Thing to Carry Out of This

If you strip the checklist down to a single lever, it is this: choose for the day you scale and the day a device lands somewhere awkward, not for the day you run the pilot. Coverage maps, data grids, and API docs all look fine in a demo. What separates providers is what happens when a fleet of embedded devices you cannot touch hits a market that restricts roaming, spikes its data, or needs a carrier change three years in.

Ask the nine questions above before you sign, get the answers in writing where they touch security, pricing, and support, and weigh the criteria that are expensive to fix after you have scaled. The provider that answers the awkward questions plainly, rather than pointing back at the coverage map, is usually the one worth committing to.