The data bill is never the problem. The problem is everything that happens after the device goes offline.

A fleet of 2,000 asset trackers. One carrier experiences a regional outage at 11pm on a Wednesday. By morning, 340 devices haven’t reported. The operations team assumes a firmware issue. An engineer spends half a day ruling that out. Someone eventually calls the carrier. The outage is acknowledged. The devices come back. Total cost of the data disruption: zero dollars. Total cost of the response: a day of engineering time, a delayed shipment investigation, and a customer who noticed the gap in tracking and started asking questions.

This is how connectivity failures actually cost money — and why the cost almost never shows up on the connectivity bill.

The four cost categories

A connectivity failure has four distinct cost categories, and only one of them is the data you didn’t transmit.

Direct costs are the most obvious: lost transactions, missed SLA commitments, regulatory penalties for data gaps in metered or medical devices. For some industries these are measurable and contractual — a missed delivery window, a failed payment at an EV charger, a billing gap in a metering cycle. These show up on a spreadsheet.

Operational costs are often larger and harder to see. A technician dispatched to reboot or swap a SIM card is the most visible form — what the industry calls a truck roll. The cost combines travel time, technician labor, and device downtime for the duration — a number that scales quickly with site remoteness and fleet size. Multiply that by the number of single-carrier failures in a year across a fleet of thousands, and it stops looking like a connectivity cost and starts looking like a staffing cost.

Reputational costs are the hardest to quantify and the longest to recover from. A customer whose GPS tracker went dark during a critical shipment doesn’t forget. A field service operator whose monitoring platform showed a gap during an audit has a conversation they’d rather not have. These costs don’t appear on any invoice.

Invisible costs are the most dangerous. A device that fails silently — where the SIM registers as active but the device isn’t transmitting — looks fine on every dashboard that doesn’t know what to look for. Your fleet shows green. Your carrier reports no outages. Your device is sitting there, doing nothing, and you don’t know.

The truck roll problem and the silent failure problem

The truck roll is the cost that gets the most attention because it’s the most visible. Someone has to physically go somewhere. That trip has a number attached: travel time, labor time, parts if needed. For a device deployed in a city, that might be a two-hour round trip. For a device on a remote utility installation, it might be half a day. Multiply by however many single-carrier outages your fleet experiences in a year — and then consider that multi-carrier failover eliminates most of those trips entirely by switching to a backup carrier automatically when the primary drops.

The silent failure problem is harder to solve because it requires active visibility, not just better hardware. A device running on a single-carrier SIM can lose signal and the SIM will show as registered. The carrier’s network accepted the SIM — it just isn’t routing traffic. Without a portal that monitors actual data transmission (not just SIM registration), this failure mode is invisible until something downstream triggers an alert: a customer complaint, a gap in a report, a missed alert that should have fired.

The difference between knowing about a silent failure in minutes versus days is the difference between a recoverable blip and an operational incident.

Where the cost is highest — and why

Not all IoT downtime costs the same. The industries below represent the highest downtime exposure — not because connectivity failures are more likely, but because the consequence of each failure is larger.

EV charging stations generate revenue per session. A charger that drops offline during peak hours loses those sessions permanently — they don’t queue up for later. Operators also face chargebacks and support calls when a payment fails mid-session because the device lost connectivity at the wrong moment.

Fleet and asset tracking carries liability exposure. A vehicle that goes dark for two hours may have missed location events that matter in a compliance audit, an insurance claim, or a customer SLA dispute. The device not reporting isn’t just an operational inconvenience — it’s a data gap in a record that someone may later need.

Medical monitoring is the highest-stakes category. Devices that transmit patient data or environmental readings in clinical settings are subject to regulatory requirements around data continuity. A connectivity gap isn’t a billing problem — it’s a documentation problem, and in some cases a patient safety concern.

Metering — utility meters, sub-meters, industrial consumption monitoring — depends on continuous data for accurate billing. A device that stops transmitting for 24 hours creates a billing gap that either goes unresolved or requires manual estimation — neither is acceptable at scale.

How to calculate your fleet’s downtime exposure

You don’t need an outage to know what one would cost. Run this exercise before your next deployment decision.

Count your single points of failure. How many devices in your fleet run on a single-carrier SIM? Each one is an outage waiting for a carrier to have a bad day. If that number is more than a handful, the exposure is real.

Estimate your truck roll rate. How many field dispatches in the last 12 months were connectivity-related? Multiply by your average dispatch cost — travel time, labor rate, device downtime. That’s your baseline: the cost you’re already paying.

Identify your silent failure risk. Does your current portal alert you when a device stops transmitting data — or only when the SIM deregisters? If you can’t answer that question immediately, assume the answer is no. That gap is where silent failures live undetected.

Apply your industry multiplier. A connectivity failure in an EV charging network at 6pm on a Friday costs more than the same failure on a metering device at 3am. Adjust your exposure estimate for when and where your devices run.

The Livelox team ran a version of this exercise before switching to multi-carrier SIM cards. Their GPS trackers across Nordic race venues had been dropping signal in remote forests — not because the technology was wrong, but because no single carrier covers everywhere. The switch to multi-carrier eliminated the drops. The overhead of managing fragmented carrier contracts disappeared with it.

Connectivity redundancy isn’t an insurance policy you hope never to use. For most deployed IoT fleets, it’s the cheaper option once you total up what single-carrier failures actually cost. If you’re ready to see what multi-carrier coverage looks like for your deployment, explore Simplex IoT SIM cards and request a trial SIM.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post The Real Cost of IoT Connectivity Failures: Downtime, Truck Rolls, and What’s Actually at Risk first appeared on Simplex Wireless.

When you can’t switch carriers, you’re not just overpaying on data rates. You’re surrendering negotiating leverage on every contract renewal — and the bill compounds at fleet scale.

Most IoT fleet operators know their carrier relationship isn’t working for them. The rates aren’t great, the service isn’t ideal, but switching feels harder than staying. That calculation — stay because leaving is expensive — is exactly the leverage your carrier is counting on. The cost of lock-in isn’t a single line item. It’s the sum of what you overpay in data rates, what a SIM swap campaign would cost, what roaming eats into your margins, and what you’ve given away at every renewal. This post puts numbers to each of those.

The data rate gap: what non-negotiated rates cost at scale

Carrier contracts for IoT data plans are negotiated. Most SMEs don’t negotiate — they accept the published rate or the renewal offer that arrives. Larger customers with volume commitments and credible alternatives get better rates. The difference isn’t dramatic per device. But it compounds.

Consider a fleet of 10,000 devices where the current rate is $1 per device per month higher than a competitive alternative. That’s $10,000 per month, or $120,000 per year — for rates alone, before any service or coverage differences.

The numbers change with fleet size and the actual rate gap, but the structure doesn’t. Small per-unit differences become material annual amounts at scale. The illustration below uses a $1/device/month differential across three fleet sizes to show how quickly the gap widens.

The deeper problem isn’t the current overpayment — it’s the renewal dynamic. When your devices run on physical SIMs tied to one carrier, you walk into a renewal negotiation without a credible alternative. Switching carriers on a physical SIM fleet requires a truck roll to every device — or thousands of them. The cost of that alternative is so high that it’s not really an alternative. Your carrier knows it.

The truck roll bill: what a SIM swap campaign actually costs

When a physical SIM fleet needs to change carriers, someone has to touch every device. In practice, that means a service call — a technician dispatched, a SIM card replaced, a device back online. The cost per visit varies by industry, geography, and device location, but it’s never trivial.

For devices in accessible locations — a retail location, a logistics hub — the per-device cost is lower. For devices mounted on infrastructure, installed in remote locations, or embedded in equipment that requires disassembly, it’s higher. The total scales directly with device count.

What makes this cost invisible in most fleet budgets is that operators rarely model it explicitly. If you’ve never switched carriers at scale, you’ve never seen the line item. The truck roll cost is theoretical until it isn’t — until coverage degrades, a better rate becomes available, or a regulatory change forces a profile update that a physical SIM simply can’t receive.

Remote SIM provisioning under SGP.32 converts that potential line item from a capital event to a software command. The cost doesn’t disappear — it shifts from per-swap to the eIM service fee, which is a fixed or volume-based operational cost rather than a per-device mobilization.

The roaming trap: when devices travel

A SIM card registered on a foreign network indefinitely is in permanent roaming. For fleets that cross borders — logistics vehicles, shipping containers, agricultural equipment operating across regions — this is a common condition.

The cost has two dimensions. The first is commercial: roaming data rates are typically higher than local connectivity rates. A device roaming on a foreign network pays the roaming tariff on every byte, which is rarely as competitive as a local plan. At scale, across many devices, that differential is significant.

The second dimension is regulatory. As eSIM standards have evolved, regulators in markets including Brazil, Turkey, Saudi Arabia, and the EU have introduced restrictions on permanent roaming SIMs. In some cases the restriction is a flag or warning; in others, service is suspended. For a fleet that depends on those devices staying online, that’s not a compliance footnote — it’s an operational risk.

Remote SIM provisioning solves both problems. A device traveling into a new region can be switched to a local carrier profile over the air. Roaming rates drop. Regulatory exposure drops. No one touches the hardware.

What changes when you own an independent eIM

The leverage mechanism is straightforward: if you can switch carriers without a SIM swap, your carrier knows it. That changes every renewal conversation.

You walk into the negotiation with competitive profiles loaded on your eIM and ready to activate. You’re not asking for a discount — you’re presenting a credible alternative. The carrier’s pricing offer now has to compete against what you can load tonight. That’s what the SGP.32 specification makes structurally possible for the first time at the enterprise fleet level.

One important clarification: this only works if the eIM is independent from your connectivity provider. If you buy your eIM from your MNO, the leverage disappears. Your profile management platform and your data plan are now controlled by the same party. You’ve replaced SIM-level lock-in with management-level lock-in — and the renewal dynamic is identical.

An independent eIM — one that will load any MNO’s profiles and has no stake in your carrier choice — is the structural requirement for the leverage to be real. That independence is not a feature. It’s the product.

The cost of carrier lock-in isn’t speculative. It’s the sum of rates you couldn’t negotiate, SIM swaps you couldn’t afford to run, roaming charges you couldn’t avoid, and renewal leverage you didn’t have. An independent eIM changes all four of those conditions — but only if it’s genuinely independent.

See how Simplex Wireless built its eIM platform to work with any MNO’s profiles, without connectivity lock-in built into the model.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post The Hidden Cost of Carrier Lock-In on a Cellular Fleet first appeared on Simplex Wireless.

Most billing surprises aren’t about the per-MB rate. They’re about choosing the wrong pricing model for how your devices actually behave.

When IoT operators compare data plans, they usually compare per-MB rates. That’s the wrong variable. A plan with a higher per-MB rate that fits your fleet’s usage pattern will cost less — and produce fewer surprises — than a cheaper plan that doesn’t. The pricing model is the variable that determines whether your bill is predictable or not. The per-MB rate just scales it.

Three pricing models exist for IoT connectivity because device fleets behave in genuinely different ways. Each model is right for one kind of deployment and wrong for another — and the failure mode of each is specific enough that you can usually diagnose which one you’re experiencing without switching anything first.

PAYG: the right flexibility premium, in the right situation

Pay-as-you-go charges a low monthly base per SIM plus a per-MB rate on actual data consumed. A SIM that transmits nothing costs almost nothing. A SIM that transmits a lot costs proportionally more. The flexibility premium is real — the per-MB rate is higher than on a pooled plan — but it’s worth paying when usage is genuinely unpredictable or when the fleet includes a large number of inactive SIMs at any given time.

The failure mode appears when a fleet grows and usage stabilizes. An operator who starts on PAYG with 50 devices and highly variable usage may find that at 500 devices with consistent moderate consumption, the aggregate PAYG cost exceeds what a pooled plan would cost for the same data volume. The flexibility premium they’re paying no longer buys anything useful. Knowing how much data your devices actually use is the prerequisite for identifying this transition point.

Pooled bundles: the shared pool that creates outlier risk

A pooled data plan assigns a shared monthly data allowance across all SIMs in the account. A sensor that uses 5MB draws from the same pool as a gateway that uses 500MB. In a homogeneous fleet — where most devices have similar usage profiles — pooling is efficient: the aggregate usage is predictable, the pool is sized appropriately, and overages are rare.

The failure mode is device heterogeneity. When a fleet mixes low-usage sensors with a smaller number of high-consumption devices — security cameras, video gateways, asset trackers in high-frequency mode — the high-usage outliers drain the pool disproportionately. The sensors don’t consume their share, but that headroom doesn’t offset the gateways exceeding theirs. The result: the fleet triggers overage on the pooled plan while the aggregate usage across all devices might actually fit a larger pool, or might warrant segmenting device types onto different plans entirely.

Prepaid: the lifetime plan that assumes a known lifetime

Prepaid IoT data purchases a fixed allocation — typically 250MB to 1GB — over a fixed service period of one to ten years. There’s no monthly billing, no recurring invoices, and no ambiguity about what was spent. For devices with a defined mission lifecycle and stable, forecastable usage, prepaid is the cleanest pricing structure available.

The failure mode is assumption drift. Prepaid makes sense when both the usage volume and the deployment timeline are known. When either changes — a firmware update adds telemetry that doubles transmission frequency, a deployment extends beyond the original plan period, or devices are decommissioned early — the prepaid budget breaks in one direction or the other. Either the allocation runs out before the service period ends, or it expires with data remaining. Both outcomes represent money spent on data that didn’t map to actual device behavior.

The decision variable operators overlook: structure, not rate

The per-MB rate matters, but it’s not the first thing to optimize. Before comparing rates across providers, it’s worth diagnosing whether the current plan structure is creating costs that have nothing to do with rate. An operator on PAYG with consistent high usage could reduce their bill significantly by switching to a pooled plan — with the same provider, at the same rate sheet. An operator with a heterogeneous fleet on a single pooled plan could eliminate overage by splitting device types across separate plan segments. Neither of those changes requires switching providers. The hidden cost of IoT connectivity is often structural, not rate-based.

That said, rate transparency matters too. A plan with the right structure but hidden fees — platform charges, activation costs, inactivity penalties, minimum volume commitments — can produce just as many billing surprises. The case for transparent IoT pricing is straightforward: if you can’t read the invoice and predict next month’s bill before it arrives, the pricing model is designed to obscure costs, not reflect them.

If any of those warning signs are familiar, the starting point is your usage data — not a new provider. Pull per-device consumption from your portal, identify outliers, and map actual behavior against the model structure you’re on. If you don’t have a portal that shows per-device usage, that’s the more fundamental problem. The Simplex IoT data SIM includes full fleet visibility as standard — usage per SIM, threshold alerts, and a transparent pricing structure across all three models. The diagnostic starts with the data, not the rate sheet.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on linkedin.com/in/JanLattunen.

The post Why Your IoT SIM Bill Is Higher Than It Should Be first appeared on Simplex Wireless.

The mechanics of a profile swap — from the moment the eIM receives an instruction to the moment the device connects on a new carrier.

The most common skepticism about remote SIM provisioning is a single question: can this really work without sending a technician? The short answer is yes. The more useful answer is understanding exactly what happens — step by step — so you can deploy with confidence rather than on faith.

The trigger: how a profile swap starts

A remote SIM provisioning operation begins with an instruction to the eIM (eSIM IoT Manager). That instruction can come from three places: a fleet operator using the portal, a business system sending an API call, or an automated rule the operator defined in advance — for example, “switch all devices in Region X to Carrier B when Carrier A signal drops below threshold.”

Once the eIM receives the instruction, it does three things before any data moves to the device:

First, it authenticates the request. The eIM verifies that the instruction is authorized — that the requestor has permission to issue a profile command for these specific eUICCs (the embedded SIM chips inside the devices).

Second, it identifies the target profile. The eIM locates the correct operator profile on the SM-DP+ (Subscription Manager – Data Preparation Plus) server — the profile store where carrier credentials live.

Third, it queues the operation. If the device is online, execution begins immediately. If the device is temporarily offline, the operation queues and executes automatically when connectivity returns. No manual retry required.

This queuing behavior is defined in the SGP.32 specification, not a vendor feature — it’s the standard’s answer to the fundamental challenge of managing devices that aren’t always reachable.

The execution: what happens over the air

Once the eIM initiates the profile delivery, the sequence runs between four parties: the eIM, the SM-DP+, the IPA (IoT Profile Assistant), and the eUICC. Here’s what each does.

The IPA — which lives either on the SIM card itself (IPAe) or on the device’s application layer (IPAd) — establishes a secure session with the eIM. This session uses mutual authentication: both the eIM and the eUICC verify each other’s certificates before any profile data moves. A swap that fails authentication at this stage doesn’t proceed.

Once the session is established, the eIM instructs the SM-DP+ to release the target profile to the eUICC. The profile downloads over the cellular connection the device already has — no separate channel, no special hardware.

After the download completes, the new profile is installed on the eUICC and the previously active profile is disabled. The device then re-registers on the new network. From the carrier’s side, the device appears as a new subscriber authenticating for the first time. From the device’s side, connectivity resumes on the new network — typically within seconds to minutes, depending on network conditions.

One detail that matters: the previous profile is disabled, not deleted, until the operator explicitly removes it. That means if something goes wrong after the switch, the fleet operator can re-enable the original profile from the eIM without starting the provisioning process from scratch.

What happens when something goes wrong

The SGP.32 specification was written with the realities of IoT deployments in mind. Every meaningful failure scenario has a defined behavior — not a silent failure.

Device offline during the operation. The eIM queues the profile state command. When the device comes back online and establishes a session, the pending operation executes. The SGP.32 design for unattended devices treats intermittent connectivity as a normal condition, not an exception.

Download interrupted mid-transfer. Profile delivery uses a resumable process — if the connection drops partway through, the transfer resumes from the interruption point rather than restarting from zero. On a constrained IoT network with limited throughput, this matters.

Authentication failure. If the mutual authentication between the eIM and eUICC fails — due to a certificate mismatch, a misconfigured eUICC, or an attempt from an unauthorized eIM — the operation stops. The existing profile remains active. The device stays connected on its current carrier.

Retry exhausted. If a profile operation fails repeatedly, the eIM logs the failure state and flags the device for operator review. No automatic recovery that could leave the device in an undefined state.

In all four scenarios, the device never ends up stranded — either the swap completes cleanly, or the original profile remains in place. That’s the fundamental guarantee that makes remote provisioning viable for unattended fleets rather than a managed risk.

What to do before you deploy

Three things to verify before you’re dependent on remote provisioning in production.

Test the full round-trip with your specific hardware. Run a profile push, a switch, and a rollback on representative devices from your fleet before deployment. Implementation differences between eUICC manufacturers mean that a profile swap that works on one chip may behave differently on another. Validate against the actual chips in your devices, not against the spec in the abstract.

Understand your eIM’s retry and rollback behavior. Ask your eIM provider what happens when a swap fails — how many retries, over what interval, and what state the device is in at each stage. This is not a theoretical question. You will encounter devices that miss operations, and the answer determines how much manual intervention your team will need.

Confirm your connectivity fallback. Remote provisioning runs over the device’s existing cellular session. If that session drops during a swap, the queuing behavior covers you — but your devices need a viable bootstrap profile to maintain the connection in the first place. Verify that your bootstrap carrier has the coverage you need in your deployment geography before you depend on it for profile switching.

A profile swap that used to take days — field technician dispatched, SIM replaced, device back online — now takes minutes. Remote SIM provisioning via SGP.32 is what makes that possible. Understanding the mechanics, including what happens when steps fail, is what makes it reliable at scale.

If you want to see how Simplex Wireless handles profile management from the eIM server side, the product overview covers the architecture in detail.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post Remote SIM Provisioning Explained: What Actually Happens When You Switch Carriers Over the Air first appeared on Simplex Wireless.

They look identical. The spec sheet doesn’t.

The short answer: Consumer SIMs are provisioned for one carrier, rated for phone environments, priced for human usage patterns, and have no management layer. IoT SIMs are provisioned for multiple carriers, rated for industrial conditions, priced for device usage patterns, and ship with a fleet management platform. Every one of those differences has a specific operational consequence at deployment scale.

Both cards store subscriber credentials. Both authenticate with cellular networks. Beyond that, the design assumptions diverge in six distinct ways — and understanding each one tells you exactly what you’re trading away when you put a consumer SIM in a deployed device.

Network access: single-carrier vs. multi-carrier

A consumer SIM is provisioned for one carrier. Its authentication credentials are tied to that carrier’s network, and when that carrier has an outage, a coverage gap, or a congestion event, the SIM has no fallback. The device goes offline and stays offline.

An IoT SIM holds credentials for multiple carriers simultaneously. In the US, a Simplex SIM can register on AT&T, T-Mobile, and Verizon. When one carrier’s signal degrades or disappears, the device reattaches to the next available network automatically — typically within seconds, without a reboot or any application-layer intervention. This is carrier failover, and it’s the primary reliability mechanism that consumer SIMs don’t have. The mechanics of how multi-carrier network access is provisioned and how failover actually works are worth understanding before evaluating any provider’s coverage claims.

Form factor and durability: plug-in vs. MFF2

Consumer SIMs are available in three removable form factors: 2FF (mini), 3FF (micro), and 4FF (nano). All three are plastic cards designed for slots in consumer electronics. They can be removed, lost, stolen, or damaged by an end user. In harsh environments — vibration, humidity, thermal cycling — the physical contact between a removable SIM and its slot is a failure point.

IoT SIM providers offer the same three removable form factors plus MFF2 (Machine Form Factor 2): a component-grade chip soldered directly to the device’s circuit board during manufacturing. MFF2 has no removable parts, no slot contact, and is rated for industrial environmental conditions. For deployments where the device enclosure will be sealed, the hardware will be in a harsh environment, or the SIM should not be physically accessible to anyone, MFF2 is the correct choice. It’s the one form factor consumer SIMs don’t come in.

Pricing: consumer plans vs. IoT billing models

Consumer data plans price for human usage: monthly allotments measured in gigabytes, overage charged at consumer rates, throttling built in after the threshold. An IoT device that transmits 30MB per month is paying for a plan designed for someone who streams video on their commute.

IoT pricing models are structured around device behavior. Pay-as-you-go charges per MB consumed, with a low base monthly cost — right for devices with variable or low usage. Pooled plans share data across the fleet, so high-usage devices draw from the same pool as low-usage ones — right for fleets with predictable aggregate consumption. Prepaid covers a fixed data budget over a defined device lifetime — right for sensors and meters with stable, forecastable usage. Understanding how much data your devices actually need is the prerequisite for choosing the right model. The wrong pricing structure costs more than a high per-MB rate — it creates billing surprises that compound at scale.

Management: no portal vs. full fleet visibility

Consumer SIMs ship with no management layer. You activate the SIM with the carrier, you put it in a device, and from that point on your visibility is limited to what the device itself reports — if it can report at all. There is no dashboard showing which SIMs are online, no usage alerts, no fraud detection, no way to deactivate a SIM remotely if a device is compromised or lost.

IoT SIMs from a managed connectivity provider come with a fleet portal included. Every SIM in the account is visible in real time: connection status, data consumed, last active timestamp. Operators can set per-SIM or fleet-level data thresholds, receive alerts when usage crosses them, flag anomalous behavior like a SIM suddenly transmitting from an unexpected country, and suspend or deactivate any SIM instantly without touching the hardware. Full API access means those actions can be automated and integrated into existing operations tooling. The absence of this layer isn’t just inconvenient — it’s a gap that becomes an invisible cost as the fleet grows. Operators who’ve learned this the hard way often describe it as paying for connectivity twice: once for the SIM, once for the manual overhead of managing without visibility.

Carrier policy: commercial use is often outside the terms

Consumer carrier agreements typically prohibit or restrict commercial use — sustained machine-to-machine traffic, continuous fixed-location data transmission, or commercial IoT applications. Most operators running consumer SIMs on deployed devices are technically outside the terms of service, even if the carrier hasn’t flagged it yet. Enforcement is inconsistent but real: carriers periodically audit accounts for non-phone usage patterns and can terminate service without notice. An IoT SIM from a commercial provider has no such ambiguity. The use case is what it was designed for.

The practical upshot: for a prototype or a small, short-lived pilot, consumer SIMs are a reasonable shortcut. For any deployment that will run unattended at scale, in variable conditions, with uptime requirements — the right SIM is an IoT SIM. The full breakdown of what M2M SIM cards are and how they’re built is a useful companion to this comparison. And if you’re ready to look at what an IoT SIM with full fleet management actually costs, the Simplex IoT data SIM is a reasonable place to start.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on linkedin.com/in/JanLattunen.

The post Consumer SIM vs. IoT SIM: What’s Actually Different? first appeared on Simplex Wireless.

SGP.32 introduced a management layer built specifically for IoT fleets. Here’s what it does, how it differs from what came before, and why the architecture choices you make now will matter at scale.

Consumer eSIM works because there’s always a person holding the device. You scan a QR code, tap “Activate,” and the carrier profile downloads. IoT devices don’t have that option — they’re sealed inside a meter cabinet, mounted on a highway gantry, or bolted to a shipping container. SGP.32’s eSIM IoT Manager — the eIM — was built to handle that reality. It’s not just a new server. It’s a redesign of who is in charge of SIM provisioning when no human is available.

What the eIM is — and why the old infrastructure wasn’t enough

The consumer eSIM specification, SGP.22, was built around two components: the SM-DP+ (Subscription Manager – Data Preparation Plus), which stores operator profiles, and the LPA (Local Profile Assistant), which runs on the device’s OS and waits for the user to initiate a download. The earlier M2M specification, SGP.02, replaced the LPA with an SM-SR (Subscription Manager – Secure Routing) that handled profile delivery server-side — but still required the MNO to coordinate each swap, not the enterprise customer.

Neither architecture was designed for the scenario where a fleet operator needs to switch 10,000 devices to a different carrier at 2am without dispatching a technician.

SGP.32 changed this by introducing the eIM (eSIM IoT Manager). The eIM is the server-side component that handles all profile lifecycle operations — push, enable, disable, and delete — for eUICCs (the embedded SIM chips) inside IoT devices, without requiring user interaction or MNO mediation. It communicates with each device through the IPA (IoT Profile Assistant), which can live either on the SIM card itself (IPAe) or on the device’s application layer (IPAd).

The critical architectural shift: control moves from the carrier’s portal to the enterprise’s operations platform.

What a fleet operator controls via the eIM

Four operations define what the eIM can do, and all four share one important property: the device doesn’t need to initiate anything.

Profile push. Load a new operator profile onto a device running a bootstrap or existing profile. The eIM sends the instruction. The IPA on the eUICC executes it.

Profile enable/switch. Activate a different stored profile, moving the device to a new carrier without physical access. What used to require a truck roll now requires a command.

Profile delete. Remove profiles that are no longer needed from the device’s storage.

Inventory and state management. Track which profiles are loaded on which devices and in what state — active, inactive, or pending.

The eIM also acts as the intermediary between your fleet and the SM-DP+ servers where operator profiles are stored. You’re not going through the MNO’s portal every time you need a profile change — the eIM handles the coordination. And because SGP.32 was designed for unattended devices, the spec defines behavior for devices that are temporarily offline: profile operations queue and execute when connectivity resumes, rather than failing silently.

That design requirement — unattended — is architectural, not just a feature claim.

What can go wrongThe eIM architecture is well-specified. How it’s implemented, and who sells it to you, determines whether you get genuine independence or just a new layer of the same problem.

Buying eIM from your connectivity provider. If your MNO bundles the eIM with your data plan, you’ve moved the lock-in up one layer. You can technically switch profiles — but only to profiles the same provider controls. The independence SGP.32 makes possible requires an eIM that operates outside any single MNO’s commercial relationship with you. The shift eSIM standards are creating for enterprise fleet buyers is exactly what’s at stake when you make this procurement decision.

Skipping EUM compatibility verification. An eIM tested against only one EUM’s (eUICC Manufacturer’s) chips is a pilot platform, not a production system. The GSMA spec allows for implementation differences between EUMs, and those differences surface in edge cases: state machine transitions, error handling, timing under load. Before you deploy, ask your eIM provider which EUM chips they’ve validated against — and ask for specifics, not just “yes, we’re compatible.”

Underestimating throughput requirements. A fleet of 1,000 devices feels manageable. 10,000 devices with simultaneous profile operations is a different engineering problem. Some eIM platforms were built for pilots and start queueing operations when fleet-scale load hits. Verify that the platform’s throughput ceiling fits the fleet size you’re planning for, not the one you have today.

What to do

Three steps to get SGP.32-ready with an eIM that delivers what the spec promises.

Confirm your eUICC exposes the IPA interface. Not all devices marketed as “eSIM-ready” are SGP.32-compliant. The eUICC must implement the IPA — either as IPAe (on the SIM) or IPAd (on the device). If your existing hardware doesn’t have this, a turnkey IPAe SIM card — one where the IPA is built into the SIM itself — lets you bring SGP.32 capability to deployed devices without a hardware refresh.

Choose an eIM that operates independently from your connectivity provider. The eIM should work with any MNO’s profiles, not only the profiles of the vendor selling it to you. If the same company is selling you the eIM and the connectivity, ask directly: can this eIM manage profiles from a different carrier? The answer tells you what independence you’re actually buying.

Ask which EUMs the platform has been tested with — by name. Interoperability claims without named EUM validation are not interoperability. A credible eIM provider can tell you exactly which chip manufacturers they’ve certified against and describe what that validation covered.

The eIM is the piece of SGP.32 that turns fleet SIM management into a software operation rather than a logistics one. Getting the architecture right — who controls the eIM, whether it’s independent, and whether it’s been validated against your hardware — is the decision that determines whether you realize that.

Explore how Simplex Wireless built its eIM platform in-house, on private cloud infrastructure, with carrier-grade throughput designed for production fleets.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post eIM Explained: The Server That Lets You Switch Carriers Without Touching the Hardware first appeared on Simplex Wireless.

Single-carrier SIMs are the hidden culprit behind most unexplained IoT outages. Here’s the failure mode, and the fix.

Your device shows a green status light. The carrier reports no outages. Your modem firmware is current. And somehow, a portion of your fleet went offline at 3 AM on a Tuesday in rural Ohio, and you found out when a customer called. If that sounds familiar, you’re probably not dealing with a hardware problem or a firmware bug. You’re dealing with a single-carrier SIM in a world that doesn’t guarantee single-carrier coverage.

The fix isn’t a signal booster or a firmware patch. It’s a different class of SIM card — and understanding why requires a quick look at how cellular IoT connectivity actually fails.

How a Single-Carrier SIM Fails

When an IoT device — a fleet tracker, a trail camera, an EV charging station, a remote sensor — powers on, the SIM card inside authenticates with a nearby cell tower and registers on a carrier’s network. From that point forward, the device stays attached to that carrier unless the connection drops, at which point the modem attempts to reconnect. To the same carrier. Because that’s the only one it’s provisioned for.

If that carrier’s tower loses power, gets overloaded, or simply doesn’t reach the specific building, field, or enclosure where your device is installed, the SIM has nowhere to go. The device goes offline and stays offline until either the carrier restores service or someone physically intervenes. No fallback. No automatic recovery. Just silence until someone notices.

A multi-carrier SIM — also called an IoT SIM or M2M SIM (Machine-to-Machine) — works differently. Instead of being locked to one carrier, it holds network access credentials for multiple carriers simultaneously. When the primary carrier drops, the device’s modem automatically registers on the next available network. This is called failover. In a well-configured multi-carrier SIM, it happens within seconds and without any action from your operations team.

Why This Matters Specifically for IoT

Consumer devices can tolerate brief outages in ways that deployed IoT devices cannot. If your phone loses signal in a parking garage, you notice when you get outside and reopen the app. No process is broken. No data is permanently lost.

Deployed IoT devices don’t have that luxury. A fleet tracker that goes silent for two hours may miss location events that trigger a compliance audit. An EV charging station that disconnects may fail to process a payment and not report the hardware fault it was supposed to log. A metering device that stops transmitting for 24 hours may produce a data gap that invalidates an entire billing cycle.

Because these devices are unattended and often physically inaccessible, the standard response to connectivity failure — “reboot it” — isn’t an option. A field technician who has to drive to a remote installation just to swap a SIM card or reboot a modem is performing what the industry calls a truck roll. A single truck roll to a remote site can cost hundreds of dollars in labor and travel time, not counting the operational downtime. Multi-carrier failover eliminates that truck roll in most single-carrier outage scenarios.

The deeper mechanics of what M2M SIM cards are and how they differ from consumer SIMs are worth understanding before you evaluate any IoT connectivity provider.

What Goes Wrong — and Where Operators Make It Worse

The most common mistake is running a consumer SIM card on a deployed device. Consumer SIMs are single-carrier by design, have no fleet management features, and are subject to data throttling policies written for smartphones. Carriers also terminate consumer SIM accounts much more readily when they detect sustained, non-phone usage patterns — which describes every IoT device you’ve ever deployed.

A less obvious mistake is buying a multi-carrier SIM without understanding how failover actually works. Not all multi-carrier SIMs behave the same way. Some use steering: there’s a preferred carrier, and the SIM only switches to a backup after a significant timeout — sometimes measured in minutes. Others use dynamic, unsteered carrier selection, where the modem evaluates network quality continuously and switches immediately when signal drops below a threshold. For latency-sensitive applications, the difference between 30-second failover and 3-second failover is the difference between a recoverable blip and a customer complaint.

A third failure mode: operators who buy the right SIM but skip field validation before scaling. Carrier coverage maps show theoretical signal boundaries — not actual device-level performance inside a steel enclosure in a basement, or under a bridge, or in a concrete utility vault. Validating connectivity with trial SIMs at actual deployment locations before committing a full fleet is not optional for any deployment where downtime has a measurable cost.

What to Do About It

Audit your current SIM inventory. If you’re running consumer SIMs or single-carrier IoT SIMs on deployed devices, you have a latent outage risk that compounds as your fleet grows. Pull your SIM inventory, identify the provisioned carrier for each device, and flag anything that can only access a single network. That’s your risk register.

Ask the right questions before your next SIM purchase. Which carriers are accessible on this SIM in the regions where I deploy? What is the failover mechanism and what is the expected failover time? Is carrier selection unsteered, or does the SIM have a preferred carrier that it holds onto longer than it should? If you don’t get clear, specific answers, that’s information too. The network architecture behind a multi-carrier SIM matters more than the spec sheet.

Test at actual deployment locations before you scale. Order a small batch of trial SIMs and test them where devices will actually live — not in your lab, not in a conference room. You’re validating failover behavior under real conditions, not just whether the SIM can make a connection at all.

Most IoT connectivity failures are not random. They’re the predictable result of single-carrier architecture in environments that don’t guarantee single-carrier coverage. The solution has been available for years, it works, and at scale it’s not materially more expensive than the infrastructure it replaces. If you’re ready to look at your options, start with Simplex’s IoT data SIM cards — multi-carrier access across the US, Canada, and 191 countries, with full fleet management included at no extra charge.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on linkedin.com/in/JanLattunen.

The post Why Your IoT Device Keeps Losing Connection — and What a Multi-Carrier SIM Does About It first appeared on Simplex Wireless.

The way cellular IoT fleets are managed is changing. Here’s what that means if you’re still doing it the old way.

The technician drives two hours to a remote utility cabinet, opens the enclosure, and swaps a SIM card the size of a thumbnail. Then drives back. Multiply that by a thousand devices, or ten thousand, and you start to understand the real cost of managing a cellular IoT fleet on physical SIM cards. SGP.32 — the GSMA’s specification for IoT eSIM management — was designed to eliminate exactly that problem.

What an eUICC Is and Why It Changes Everything

A physical SIM card does one thing: it identifies your device to a specific carrier’s network. To change carriers, you change the card. That’s been the arrangement since the 1990s.

An eUICC (embedded Universal Integrated Circuit Card) is a different kind of SIM chip — soldered directly into the device rather than slotted in a tray. The key difference isn’t the form factor; it’s what the chip can hold. An eUICC stores multiple operator profiles — the digital equivalents of SIM cards — and can switch between them without any physical intervention.

Remote SIM provisioning (RSP) is the capability that makes this useful at scale. Instead of dispatching a technician, your management system pushes a new operator profile to the eUICC over the air. The device authenticates to the new network, typically within minutes. No site visit, no downtime window, no logistics coordination.

SGP.32 is the GSMA specification that standardizes how this works for IoT fleets specifically. Its predecessors — SGP.02 for M2M, SGP.22 for consumer devices — weren’t built for the unattended, large-scale deployments that characterize IoT. SGP.32 introduces a new server-side component called the eIM (eSIM IoT Manager) to orchestrate profile management across fleets of devices that have no user interface and may be operating in remote locations with intermittent connectivity.

Why IoT Is Different From Consumer eSIM

Consumer eSIM — the version you use when activating a smartphone on a new carrier — works differently from what your fleet needs.

The SGP.22 standard for consumer eSIM assumes a user is present: someone scans a QR code, taps a confirmation, and the profile activates. That model fails completely for IoT. A water meter in a field doesn’t have a screen. A GPS tracker sealed inside a shipping container can’t scan a QR code. An industrial sensor in a hazardous enclosure won’t be physically accessed for months.

SGP.32 is designed for unattended operation from the start. Profiles can be pushed, switched, and deleted by the eIM server without any interaction from the device side beyond connectivity. The specification also addresses the scale problem: it’s built to handle large volumes of profile operations in parallel, not sequentially as consumer specs were designed.

There’s a practically important distinction here: SGP.32 supports two interfaces for connecting the eIM to devices. IPAe (IoT Profile Assistant embedded) lives on the SIM card itself. IPAd (IoT Profile Assistant device-side) lives on the device’s application layer, which requires firmware or OS integration. For fleets with existing deployed hardware, IPAe is the more practical path: the SGP.32 management capability lives on the SIM, not the device. You can bring an older device into SGP.32 compliance by upgrading the SIM card, without touching the hardware.

What’s Costing You Right Now

Most fleet operators know truck rolls are expensive. Fewer have calculated what they actually total across a fleet’s operational life.

A field service call to swap a single SIM — accounting for technician time, travel, scheduling overhead, and device downtime — can run into the hundreds of dollars per visit. For a large-scale IoT deployment of several thousand devices, a carrier migration requiring physical SIM replacement can cost millions before a single new SIM card is purchased. That number rarely appears in procurement analysis; it gets absorbed across operations budgets and written off as routine maintenance. But it’s there.

Carrier lock-in is the downstream consequence. If switching providers requires a truck-roll campaign, most companies don’t switch. They renew, on whatever terms the carrier offers. The negotiating power that comes from operating in a competitive market disappears the moment your connectivity is physically fixed into hardware.

There’s a third pressure that’s becoming more urgent: permanent roaming restrictions. Regulators in Brazil, Turkey, Saudi Arabia, and across the EU are increasingly restricting or banning devices that connect permanently to foreign networks. Fleets that rely on international roaming SIMs as a cost-control mechanism are now facing compliance risk. Switching to local operator profiles on demand is an operational requirement in these markets — not an optional improvement.

What the Workflow Looks Like After the Switch

Managing a cellular IoT fleet under SGP.32 isn’t a different version of what you do today — it’s a different kind of activity.

Instead of coordinating SIM replacement campaigns, you manage profiles from a dashboard or API. When coverage degrades in a region, you switch affected devices to a carrier with better signal there. When a contract comes up for renewal, you negotiate with real options — or switch. When a device is deployed in a market with local SIM requirements, you provision the right profile before it goes live.

The practical steps for moving an existing fleet toward SGP.32:

Audit your hardware for eUICC compatibility. Devices that already include an eUICC chip can often begin the transition without hardware replacement — particularly if the eUICC supports IPAe, which puts the management interface on the SIM rather than requiring a firmware update.

Identify devices with no eUICC. For these, turnkey IPAe SIM cards — like the ones Simplex offers through the Works With Simplex program — can bring older hardware into SGP.32 compliance without a full device retrofit.

Evaluate eIM providers on criteria that hold up. Independence from your current carrier, breadth of interoperability testing across eUICC manufacturers, and flexibility in commercial model are the dimensions that matter most at this stage.

The shift from physical SIM management to SGP.32 doesn’t require replacing your fleet overnight. In most cases, it starts with understanding what your devices already support — and what a single SIM upgrade can unlock. For a closer look at how the profile provisioning process works at the device level, the article on eSIM provisioning mechanics for IoT covers the step-by-step in detail.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post From Physical SIMs to SGP.32: What Changes for Your IoT Fleet first appeared on Simplex Wireless.

Picking the wrong connectivity provider doesn’t just cost money — it can strand hundreds of deployed devices when you can least afford it.

Most IoT deployment decisions start with coverage maps and pricing tiers. Those things matter, but they answer the wrong question first. The question that actually determines long-term risk isn’t “can they cover my deployment region?” It’s “will they still be operating in year six of a ten-year device lifecycle?”

The IoT MVNO (Mobile Virtual Network Operator) market is crowded, fast-moving, and subject to real business failures. Providers get acquired, run out of runway, or quietly wind down services — and when that happens, companies managing deployed device fleets face emergency migrations that are expensive, disruptive, and sometimes physically impossible without hardware replacement. That exposure is rarely discussed during the sales process. This guide gives you the framework to close that gap before you commit, not after.

What to evaluate

Six criteria separate providers worth trusting with a long-term deployment from those that look attractive on a pricing sheet and nothing else.

The financial model is the starting point. The IoT connectivity market has a high proportion of VC-funded operators who are burning cash to acquire customers and grow market share. That model works until it doesn’t — and when funding rounds stop, services get disrupted before customers have time to migrate. A cashflow-positive provider with a stable revenue base is a categorically different risk profile. Ask directly how the business is funded. A credible provider will answer.

Corporate structure and parent company backing matters alongside the financial model. A young MVNO subsidiary of a 25-year-old software company serving Tier 1 carriers is a different proposition than a standalone startup. The parent company’s history, client base, and financial health all transfer as backstop to the subsidiary’s reliability.

eSIM portability is your exit strategy if a provider fails. The critical distinction is whether your devices support Remote Sim Provisioning (RSP) profile switching — meaning you can migrate to a new provider without physically touching the hardware. If your device fleet requires a truck roll to swap SIMs, a provider failure becomes a significant capital event. Confirm OTA switching capability with your specific hardware before signing.

Network architecture determines coverage quality in practice. Multi-carrier connectivity through direct carrier agreements is more reliable than aggregated access through intermediaries — direct agreements mean better support escalation paths, more control over service quality, and fewer single points of failure in the network stack.

Platform ownership tells you who you’re actually talking to when something breaks. If the provider runs their own SIM management platform built in-house, their engineering team can diagnose and fix issues directly. If they’re reselling someone else’s platform, they’re a middleman in their own support process.

Finally, operational track record: how long have they been running, and what does their maintenance history look like? Providers who publish a status page with historical incident data are signaling accountability. Providers who don’t are telling you something.

Figure 1 — Comparison cards: VC-funded MVNO vs. cashflow-positive MVNO

Common pitfalls when evaluating providers

The most consistent mistake is letting pricing dominate the evaluation. A provider offering the lowest per-MB rate may be doing so because they’re subsidizing customer acquisition with investor capital — a model that doesn’t survive indefinitely. Pricing transparency matters, but the right question isn’t just “what does it cost today?” It’s “what does the pricing model reveal about the underlying business?”

The second pitfall is treating eSIM support as a binary. Buyers hear “we support eSIM” and assume they’re protected from lock-in. The reality is more specific: OTA profile switching requires compatible hardware, a properly structured eUICC (embedded Universal Integrated Circuit Card), and a provider platform that supports the relevant GSMA standard. If any of those three elements is missing, the theoretical portability doesn’t translate into practical migration capability. Confirm all three before treating eSIM as your exit option.

The third mistake is skipping the trial period. Most providers offer trial SIMs, and the trial isn’t just for testing signal coverage — it’s for evaluating support response times, portal usability, and how the provider communicates when things don’t work as expected. A provider that goes quiet during a trial period technical issue tells you exactly how they’ll behave when a production problem surfaces at 2 AM.

Figure 2 — Ranked list: evaluation criteria by deployment risk weight

How Simplex addresses each criterion

On financial model: Simplex operates as a cashflow-positive business — not VC-funded, not burning toward a growth milestone. When prospects ask whether Simplex will still be operating in a decade, the answer isn’t just “we think so” — it’s grounded in an organizational track record that predates the IoT connectivity market itself.

On eSIM portability: Simplex’s xoSIM platform supports over-the-air profile switching via SGP.32, the current GSMA standard for IoT eSIM management. The EIM (eSIM IoT Manager) server is built entirely in-house in Atlanta, which means Simplex isn’t dependent on a third-party platform operator to execute a migration. If a customer ever needed to leave, the exit path is technically available without hardware replacement on compatible devices. Simplex acknowledges one honest limitation here: OTA portability still requires the customer’s hardware to support the relevant eSIM spec. That’s a device decision made before deployment, not something the provider can fix retroactively.

On platform ownership: the SIM management platform is proprietary, not licensed from an MVNE (Mobile Virtual Network Enabler). When something breaks at the network layer, the team debugging it is the same team that built it. That shortens escalation paths considerably compared to providers who operate on resold infrastructure.

On carrier agreements: Simplex holds bilateral roaming agreements with carriers that explicitly permit permanent roaming — a distinction that matters for IoT deployments where devices may spend their entire operational life attached to a network other than their home carrier. Standard roaming arrangements used by consumer-grade providers don’t carry this permission, which creates a real termination risk for devices in multi-region deployments.

On pricing: no activation fees, no platform fees, no minimum contract commitments on standard plans. Plan tiers can be adjusted monthly. Flexible plan structures — prepaid, pay-as-you-go, and pooled bundles — mean you’re not forced into a fixed commitment model as your deployment scales or your usage patterns change.

Questions to put to any provider

These apply equally to every provider you evaluate — including Simplex.

Is the company cashflow positive, or VC-funded? If VC-funded, what is the runway, and what happens to customer SIMs in a wind-down scenario?

Who owns the SIM management platform? If it’s licensed from a third party, who holds the relationship with that platform operator, and what happens to your account if that relationship ends?

What GSMA eSIM specification do your SIM cards support — SGP.02, SGP.22, or SGP.32 — and does OTA profile switching require hardware changes on my specific modules?

Which carriers provide your coverage in my primary deployment regions, and are those direct bilateral agreements or aggregated access through another MVNO?

Do your roaming agreements explicitly permit permanent roaming, and in which countries? Can you provide that in writing?

Where is your status page, and how far back does the maintenance history go? Have there been any unplanned outages in the past 12 months?

Figure 3 — Checklist: due diligence before you sign

Before you commit

A provider who can’t or won’t answer the questions in this guide is giving you the most important piece of information available: they haven’t thought through your deployment risk, or they have and don’t want to discuss it. Either way, that’s the answer.

If you’re evaluating connectivity for a deployment that will outlive most software projects, start your trial with Simplex — request a trial SIM, or bring your specific deployment questions directly to the sales team at sales@simplexwireless.com.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post How to Evaluate an IoT SIM Provider: A Due Diligence Guide for Multi-Year Deployments first appeared on Simplex Wireless.

The company you buy your IoT SIM from almost certainly doesn’t own the towers your devices connect to. Here’s what that means, how it works, and why the distinction matters when you’re evaluating providers.

MVNO stands for Mobile Virtual Network Operator. An MVNO is a company that provides cellular connectivity without owning the physical network infrastructure — no spectrum licenses, no cell towers, no radio access network. Instead, an MVNO buys wholesale access to one or more mobile networks from the companies that do own them (called MNOs, or Mobile Network Operators), then builds its own services, pricing, and management platform on top. When your IoT devices connect to AT&T or T-Mobile through a Simplex SIM, they’re using the MNO’s towers — but the SIM, the account, the management platform, and the support relationship are all Simplex’s.

Most IoT connectivity providers are MVNOs. Understanding what that means — and what varies between them — is one of the more useful things you can know before choosing one.

MNO vs MVNO — The Infrastructure Distinction

An MNO (Mobile Network Operator) owns everything: the spectrum license, the towers, the radio access network, and the core network that handles authentication, routing, and billing. AT&T, T-Mobile, Verizon in the US; Rogers, Bell, and TELUS in Canada; Vodafone in Europe — these are MNOs. Building and maintaining this infrastructure requires enormous capital investment. It also locks each MNO into their own coverage footprint, which is why no single MNO covers every location on earth with equal reliability.

An MVNO sits above the infrastructure layer. It negotiates commercial agreements with one or more MNOs for wholesale network access, then manages everything from that point forward: SIM cards, data plans, account management, fleet dashboards, billing, and support. The devices using an MVNO’s SIM connect to the underlying MNO’s towers, but the customer relationship — and all the operational tools — belong to the MVNO.

For IoT buyers, this structure has a direct practical benefit: a well-connected MVNO can offer access to multiple MNO networks on a single SIM. Where a direct MNO relationship locks your devices to one carrier’s coverage footprint, an MVNO with agreements across multiple carriers can route your devices to whichever network has the strongest signal at a given location. That’s how multi-carrier IoT connectivity works in practice — not magic, but commercial agreements, and the MVNO is the entity that holds them.

Not All MVNOs Are the Same

The term MVNO covers a wide spectrum, from branded resellers who do little more than put their name on another operator’s SIM, to full MVNOs who build and operate their own core network components, billing infrastructure, and service platforms. For an IoT buyer, the distinction matters in three specific ways.

What’s built in-house versus resold. A light MVNO essentially repackages another company’s platform. A full MVNO builds its own SIM management system, billing infrastructure, and network integration. The difference shows up most clearly when something goes wrong: a provider that owns its platform can diagnose and fix issues at the infrastructure level. One that resells a third-party platform escalates to their vendor, who escalates to the network, and the customer waits.

How many MNO agreements they hold — and what those actually cover. Country coverage maps are marketing. What determines whether your device connects reliably is the specific carrier agreements behind that map — which networks, under what terms, and whether permanent roaming is permitted in each market. Two MVNOs can both claim “191-country coverage” with very different carrier depth behind those claims.

Financial stability. The MVNO market has meaningful failure rates. Many operate on venture capital without clear paths to profitability. When an MVNO closes or degrades, the impact on a deployed device fleet can range from service disruption to stranded hardware — especially for MFF2 embedded deployments where physical SIM replacement is difficult. Asking whether a provider is cashflow positive isn’t an unusual question. It’s a reasonable one for anyone committing devices to a multi-year deployment.

What Varies Between IoT MVNOs

Consumer MVNOs compete primarily on price and brand. IoT MVNOs need to compete on different dimensions — and the ones that matter most aren’t always visible on a pricing page.

The management platform is often more important than the data plan itself. At small scale, logging into a portal once a week to check usage is manageable. At 50 devices, 500, or 50,000, you need API access, automated provisioning, per-SIM lifecycle control, usage alerts, and a billing structure that reflects actual consumption across a heterogeneous fleet. Some MVNOs include this as standard. Others charge for it separately or offer it only at higher tiers.

eSIM and OTA switching capability separates providers that can adapt to a deployment from those that can’t. A SIM that supports SGP.32-based over-the-air profile switching gives you options if your coverage needs change, if regulations in a market require a local profile, or if the provider relationship needs to change entirely. A SIM without OTA capability locks you into the hardware and the provider simultaneously.

Where Simplex Fits

Simplex is an IoT MVNO with access to AT&T, T-Mobile, and Verizon in the US and Rogers, Bell, and TELUS in Canada, extending to 550+ networks across 191 countries globally. The company is part of a sister company, which has more than 30 years of experience building carrier-grade software for tier-1 MNOs.

The EIM (eSIM IoT Manager) platform is built entirely in-house on Simplex’s own bare metal infrastructure — not a resold third-party system. When something needs to be diagnosed or fixed at the platform level, the people who answer the phone are the people who built it. The xoSIM platform supports SGP.32 over-the-air profile switching, which means a deployed fleet isn’t permanently locked to any single carrier profile or provider relationship..

Understanding what an MVNO is doesn’t require deep technical knowledge — but it does change the questions you ask before choosing one. The provider you buy from sits between you and the network. What they’ve built, who they hold agreements with, and how stable they are financially all determine what your devices actually experience in the field. Explore Simplex’s IoT data SIM to see how the MVNO model translates into specific plans and coverage for your deployment.

This article was curated by Jan Lattunen, CCO Simplex Wireless

About the Author: Jan Lattunen manages Sales and Marketing for Simplex Wireless. Jan has 20 years’ experience in working with SIM card technology and was involved in launching the eSIM in North America with major carriers and OEMs. His expertise in telecommunications is around SIM cards. On a personal note, Jan is a family man and avid cyclist with advocacy for safety in the roads. You can connect with Jan on https://linkedin.com/in/JanLattunen

The post What Is an MVNO? And Why It Matters More Than You Think for IoT Connectivity first appeared on Simplex Wireless.