As drone operations move beyond visual line of sight, the SIM card choice stops being a detail and starts being a safety decision.

Commercial drone deployments have changed significantly over the past several years. What started as close-range visual inspection work has expanded into infrastructure monitoring across remote transmission lines, precision agriculture across hundreds of acres, package delivery in urban corridors, and emergency response operations where the drone is the first asset on scene. The common thread across all of these use cases is the same: the drone is no longer something you watch fly. It’s a remote platform that has to stay connected reliably, continuously, and often far beyond where you can see it.

That shift changes the connectivity requirement entirely.

The connectivity challenge for commercial drone operators

A drone operating within visual line of sight can use direct radio links for command and control — the pilot watches the aircraft and maintains the link through dedicated RF hardware. Beyond visual line of sight (BVLOS) is a different problem. The aircraft can be kilometers away, over terrain that breaks radio contact, or operating autonomously on a pre-planned route where the pilot needs real-time telemetry but isn’t actively flying the aircraft. Cellular connectivity is what fills that gap.

Drone cellular links carry several distinct data streams simultaneously. Command and control (C2) traffic is the critical link — the instructions the ground station sends to the aircraft and the telemetry the aircraft sends back. Lose this link and the drone enters a failsafe mode that may not be appropriate for the operational context. Alongside C2, many platforms transmit live video or still imagery, GPS position and flight data, and payload sensor readings. These streams have different bandwidth requirements and different tolerance for interruption.

The challenge is that cellular networks were not designed for aerial platforms. Tower antennas are directional, optimized to radiate signal toward the ground where devices are. At altitude, a drone may be within range of many towers simultaneously, creating interference from overlapping signals and making network handoffs less predictable than they are at ground level. Coverage that looks adequate on a map may behave differently in practice when the device is 50 meters in the air and travelling at speed.

Figure 1 — 2×2 card grid: four connectivity requirements unique to drone operations

Why consumer SIM cards fail in drone deployments

The fastest way to understand why standard SIM cards are the wrong tool for drone connectivity is to think about what a consumer SIM is optimized for. It’s designed for a single device, on a single carrier, at ground level, used by a human who can switch to Wi-Fi or wait for signal to improve. None of those assumptions hold for a commercial drone.

A single-carrier SIM connects to one network. If that network has inconsistent coverage along the flight route — particularly at the altitudes where drones operate, where antenna patterns behave differently than they do at ground level — the link degrades or drops without any fallback. The aircraft can’t switch carriers mid-flight because the SIM isn’t capable of it. Consumer prepaid SIMs compound this problem with data caps that cut service when the allocation is exhausted, which is a billing inconvenience on a phone and a safety issue on an aircraft.

Understanding how multi-carrier connectivity works at the network level is essential for anyone specifying drone connectivity. Direct bilateral roaming agreements — where the SIM provider holds agreements with each carrier individually — deliver more reliable network handoffs and better signal continuity than aggregated access through an intermediary. For a drone that may pass through the coverage zones of multiple towers during a single flight, how those transitions are managed matters.

There’s also a latency dimension. Consumer SIM traffic is typically routed through a carrier’s central core network, which may be geographically distant from the deployment site. For a pilot sending a control input and waiting for the aircraft to respond, that added round-trip time is felt. IoT-grade data breakout at regional points of presence — in the US, Europe, or APAC depending on where the fleet operates — keeps latency predictable and low.

What the right connectivity looks like for drone fleets

Three characteristics distinguish IoT connectivity that works for commercial drone operations from connectivity that doesn’t.

Multi-carrier access within each country is the most important. In the US, that means AT&T, T-Mobile, and Verizon on a single SIM, with the modem connecting to whichever carrier provides the strongest signal at any given moment in the flight. No manual selection, no single point of failure. The same principle applies globally — a drone fleet operating across multiple countries needs a SIM that doesn’t require per-country configuration or separate contracts for each market.

Right-sized data plans matter because drone payloads vary significantly. A telemetry-only mission transmits modest amounts of data — position, flight parameters, sensor readings at regular intervals. A mission streaming live HD video to a ground station or cloud platform transmits orders of magnitude more. A fleet running both types of mission needs either a pooled plan that absorbs the variability across the fleet, or a PAYG structure where each SIM is billed for actual consumption rather than a fixed allocation sized for the worst case.

Fleet management capability is the third requirement. A drone operator managing 20 or 200 aircraft needs to see per-SIM connectivity status, data consumption, and network registration in real time — not through a carrier support call, but through a management portal or API. Usage alerts that trigger when a SIM approaches its allocation limit, and the ability to adjust plan tiers without swapping hardware, are operational requirements rather than nice-to-haves.

Figure 2 — Ranked list: connectivity failure modes by operational risk

How Simplex fits the drone connectivity stack

Simplex IoT SIM cards provide multi-carrier access on a single SIM — AT&T, T-Mobile, and Verizon in the US; Rogers, Bell, and TELUS in Canada; and Tier 1 networks across Europe and APAC. For a drone flying a route that crosses coverage zones, the modem connects to whichever carrier is strongest at each point without the operator needing to configure or manage anything. There’s no single carrier dependency and no manual network selection.

Data breakout is available regionally — in the US, Europe, and APAC — keeping latency predictable for real-time C2 applications. For drone operators where round-trip control latency matters, this is a meaningful operational advantage over connectivity that routes all traffic through a geographically distant core.

Plan structures cover the full range of drone operational profiles. The 100MB postpaid bundle at $0.99 per month handles telemetry-focused missions where data consumption is modest and predictable. PAYG plans suit missions with variable payloads, where some flights are telemetry-only and others stream imagery. Pooled bundles work for larger fleets where heavy-data missions in one part of the fleet are balanced by low-data missions elsewhere. No activation fees, no minimum commitments beyond 10 SIMs for postpaid plans.

Figure 3 — Side-by-side comparison: standard SIM vs. multi-carrier IoT SIM for drone fleets

Cellular connectivity for commercial drones isn’t a feature — it’s infrastructure. The SIM decisions made during platform specification directly affect what operations are possible, how safely they can be conducted, and how the fleet scales as the operation grows. Choosing a connectivity model built for IoT deployments rather than adapted from consumer hardware is the difference between a link that holds and one that doesn’t. Explore Simplex’s drone connectivity options or get your IoT SIM to get started.

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 Commercial Drones and Cellular Connectivity: Why a Single Carrier Is Never Enough first appeared on Simplex Wireless.

Satellite connectivity for IoT has a cost. So does not having it. Here is how to work out which is larger for your deployment.

Most conversations about 5G NTN (Non-Terrestrial Network) IoT focus on the technology — what it is, how satellites replace towers, which industries it suits. The conversation that actually drives procurement decisions is different: what does it cost, what does it save, and how do you know whether the numbers work for your specific operation?

This guide is for the person building that business case. It won’t tell you NTN is right for every deployment — it isn’t. What it will give you is the framework to make an honest assessment, the cost factors that most analyses miss, and the questions you should put to any provider before signing.

What NTN IoT actually costs

The headline cost is the modem module. NTN-capable modules — built on chipsets like Qualcomm’s 212S or MediaTek’s MT6825 — currently run $20–$40 per device at modest volumes, compared to $5–$15 for a standard terrestrial NB-IoT (Narrowband IoT) or LTE-M module. That’s a real premium, and it’s the number that dominates most initial objections.

But the module is only one part of the cost picture. Figure 1 shows the relationship between operational cost of connectivity gaps and the NTN investment required across three industries. The pattern is consistent: the industries with the highest cost of being offline are also the ones where the NTN premium looks smallest relative to what it protects against.

Beyond the module, four additional cost factors belong in every NTN business case.

Connectivity plan cost. A hybrid architecture — terrestrial-first with NTN fallback — means you pay terrestrial rates when the device is in coverage, and satellite rates only when it isn’t. For a fleet truck that spends 80% of its time in urban or suburban corridors, the satellite component of the bill may be modest. For a sensor permanently installed in a remote basin, the satellite rate applies to every transmission. Know your coverage split before modeling connectivity cost.

Power budget redesign. NTN-capable chipsets require an onboard GNSS (Global Navigation Satellite System) receiver for Doppler pre-compensation. That’s an additional continuous power draw that doesn’t exist in terrestrial designs. Devices running years on a small battery over terrestrial NB-IoT will need their power model reworked. This is engineering time, not a line item, but it’s real cost.

Protocol tuning. Firmware configured for terrestrial latency will behave incorrectly on NTN. MQTT keep-alive intervals, TCP timeout parameters, and retransmission logic all need review and adjustment. For teams without in-house firmware experience, this may require external support.

Hardware generation timing. NTN requires modem support at the hardware level. Existing deployed devices cannot be software-upgraded. If you have a fleet in the field, NTN is a next-generation hardware decision, not a retrofit. Factor in the depreciation timeline of your current hardware when modeling payback period.

What connectivity gaps actually cost

This is the side of the equation that most business cases undervalue, because the costs are distributed across departments and don’t appear on a single line item.

For logistics and cold chain operators, a four-hour connectivity gap on a temperature-sensitive shipment is a potential cargo claim. The average refrigerated cargo claim in US trucking runs into thousands of dollars per incident, before legal costs. A single avoided claim on a high-value pharmaceutical shipment can exceed the NTN premium on an entire device fleet.

For energy infrastructure operators, a connectivity gap on a pipeline pressure monitor is a window during which a developing fault goes undetected. The cost of a missed anomaly — regulatory penalty, environmental remediation, emergency response — is orders of magnitude larger than the cost of continuous monitoring.

For agricultural operations, the cost is subtler but compounds across seasons. Irrigation decisions made on stale sensor data waste water and reduce yield. Livestock that wander beyond coverage boundaries and aren’t located promptly create replacement costs. These are not dramatic line items, but across a large operation they add up to meaningful numbers.

The question to answer before building the business case is: what does one connectivity gap event actually cost your operation, fully loaded? Once you have that number, the NTN premium calculation becomes straightforward. Figure 2 gives you the six questions that determine whether the case holds.

How to evaluate whether NTN is right for your deployment

The checklist in Figure 2 is designed to be used honestly. Two of the six questions are genuine filters that may lead you away from NTN: if a multi-carrier terrestrial SIM closes your coverage gaps, it’s the right answer — simpler, cheaper, no hardware change required. If your use case requires real-time control with latency under 20 ms, NTN as it stands today won’t meet that requirement.

For deployments that clear the filters, the business case typically rests on one of three value drivers.

Compliance and liability protection. In sectors with mandatory continuous monitoring requirements — pharmaceutical cold chain, pipeline integrity, hazardous materials transport — the value of NTN is not primarily operational efficiency. It’s the ability to produce an uninterrupted audit trail. Gaps in that record create liability exposure that no amount of operational cost savings offsets. If your industry has continuous monitoring requirements, NTN pays for itself in risk reduction before you count any operational savings.

Avoided exception costs. Calculate the frequency and cost of connectivity-related exceptions in your current operation: cargo claims, missed maintenance windows, unplanned truck rolls to investigate silent devices, manual data reconciliation. These costs are often absorbed by operations teams and never attributed to connectivity. Surface them, and the NTN investment often looks conservative by comparison.

Asset visibility at scale. For operators running large distributed fleets or sensor networks, the value of complete visibility is difficult to quantify but easy to observe in reverse. What decisions are you currently making without data because some portion of your fleet is always offline? What would change if that portion went to zero?

Total cost of ownership: the honest comparison

Figure 3 puts the cost structures side by side across a three-year device lifecycle — the timeframe over which most IoT hardware investments are evaluated.

The single-carrier terrestrial option wins on headline cost at every line item. The hybrid NTN option wins on operational risk — which, for operations where connectivity gaps carry real consequences, is the metric that matters. The crossover point depends entirely on your gap frequency and your gap cost. For operations that rarely leave terrestrial coverage and face low consequences when they do, single-carrier terrestrial is the right answer. For operations where assets regularly move beyond coverage and gaps carry financial, compliance, or safety consequences, the hybrid case is usually clear.

One honest limitation worth stating: NTN connectivity pricing is still early-market. Satellite data rates for IoT are not yet commoditized the way terrestrial rates are, and they vary meaningfully between providers. Get specific pricing from your provider for your actual payload size and transmission frequency before finalizing your model. Round-number estimates at this stage of the market can be off by a factor of two or more.

Questions to ask any NTN provider

Put these to every provider you evaluate, including Simplex.

What satellite operators are you working with, and what is their coverage SLA for my specific geography? LEO coverage is orbital, not static. Get a documented coverage commitment for the regions where your devices will operate, not a general global coverage claim.

Is your NTN connectivity on the same SIM and management platform as your terrestrial connectivity? Separate SIMs and separate portals for terrestrial and satellite create operational complexity at scale. Ask specifically how fleet management, usage monitoring, and billing work when a device switches between terrestrial and satellite.

What is the per-device data rate for NTN NB-IoT transmissions, and what is the pricing model? Per-message, per-KB, and per-device-per-month pricing models produce very different bills depending on your payload size and frequency. Run your actual transmission profile through their pricing model before comparing.

What protocol configuration changes does your platform recommend for NTN latency? A provider who can’t answer this in specific technical terms hasn’t deployed NTN in production.

What happens when my device is in terrestrial coverage — does it automatically prefer terrestrial, and how is billing handled for mixed sessions? Hybrid architecture only works cleanly if the network selection and billing are handled correctly at the platform level.

5G NTN IoT is not a solution looking for a problem. It’s a connectivity layer for a specific set of deployments where the cost of being offline exceeds the cost of satellite connectivity — and where terrestrial infrastructure was never going to close the gap. For those deployments, the business case is straightforward once you account for the full cost of the status quo.

If you’re working through the numbers for a specific deployment, talk to our team — we’ll help you model the coverage split, transmission profile, and total cost before you commit. Or explore Simplex’s IoT connectivity plans to see how terrestrial and NTN pricing work together.

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 Business Case for 5G NTN IoT first appeared on Simplex Wireless.

A smart meter on NB-IoT wakes up for a few seconds a day, sends its reading, and goes back to sleep. It has no screen, no user nearby, and a battery that has to last a decade. Ask that device to run the same protocol stack a phone uses to download an eSIM profile, and it either fails outright or burns through years of battery life doing it. That mismatch is exactly why SGP.32 doesn’t use the same transport as the standards before it.

What it is and how it works

The protocol choice has changed with every generation of the GSMA’s remote provisioning standards, and each change tracks the devices it was built for. SGP.02, the original machine-to-machine standard, used SMS to trigger profile changes, coordinated through a Subscription Manager Secure Routing (SM-SR) server that pushed instructions to the device. SMS worked because early M2M devices sat on 2G and 3G networks where it was universally available, but it’s a channel many newer IoT networks, including NB-IoT, don’t support at all.

SGP.22, the consumer standard, replaced that with HTTPS over TCP, paired with a QR code the user scans and a Local Profile Assistant (LPA) running on the phone that handles the download. That model assumes a screen, a user, and a device with the power budget of a smartphone. None of those assumptions hold for a battery-powered sensor.

SGP.32 drops both of those and defines CoAP (Constrained Application Protocol) over UDP, secured with DTLS, as its lightweight transport option, alongside the standard HTTPS/TCP path for devices well-connected enough to use it. CoAP keeps the same request-response shape as HTTP but strips out the overhead that makes plain TCP and TLS expensive to hold open on a constrained radio link. On the device side, an IoT Profile Assistant (IPA) replaces the LPA and speaks CoAP to the eIM, the server-side manager that decides what happens to a device’s profile and when.

Why it matters for IoT specifically

TCP’s overhead comes from the handshake it needs before any data moves, and TLS adds another handshake on top of that. On a well-connected phone that cost is invisible. On NB-IoT or LTE-M, where a device might have a data budget measured in kilobytes and a radio that’s asleep most of the day, that same handshake can eat a meaningful chunk of a device’s power and airtime just to say hello. UDP skips the connection setup entirely, and CoAP was purpose-built to run on it while DTLS still provides the authentication and encryption the profile exchange needs.

This is also what makes the provisioning model asynchronous rather than user-driven. A device doesn’t need to be actively browsing or scanning anything. It wakes on its own schedule, checks in briefly, and the eIM can push a profile change during that short window. That’s the difference between a model built around a person tapping a screen and one built around a sensor that spends 99 percent of its life asleep.

What can go wrong

The most common misunderstanding is treating CoAP as a lightweight or lower-security shortcut. It isn’t. DTLS provides the same category of cryptographic protection TLS does, adapted to run over UDP, and SGP.32 still requires mutual authentication between the eIM and the eUICC regardless of which transport carries it.

The second mistake is assuming every SGP.32 device has to use CoAP. It doesn’t. SGP.32 supports HTTPS over TCP as well, for devices with the power and connectivity to justify it, and CoAP as the option for genuinely constrained hardware. Picking the wrong one for your device class either wastes a battery budget you didn’t need to spend or asks a constrained radio to do something it can’t sustain.

The third is underestimating what a CoAP/DTLS stack asks of a module or firmware team. Not every existing modem or cellular module ships with a certified CoAP implementation, and interoperability between eUICC, module, and eIM is still something to verify directly rather than assume from a spec sheet, since compliance with SGP.32 on paper doesn’t guarantee two vendors’ implementations behave identically together in practice.

What to do about it

Three things worth checking before you commit to a device design. First, confirm with your module or chipset vendor that CoAP over UDP with DTLS is actually implemented and certified, not just planned. Second, ask whether your eUICC handles the CoAP stack itself (IPAe) or leaves it to your device firmware (IPAd), since that choice changes how much engineering work lands on your team. Third, size your power budget around the transport your device will actually use. A device on HTTPS/TCP and one on CoAP/UDP have meaningfully different energy profiles, and assuming the lighter one by default without checking your specific hardware is a common source of surprises late in a project.

The protocol change from SGP.02’s SMS to SGP.22’s HTTPS to SGP.32’s CoAP isn’t an arbitrary spec update. Each one matches the device it was designed for, and CoAP over UDP is what finally makes remote provisioning workable on hardware that has to survive years on a battery with no one watching it. Learn more about how eIM and the IPA work together once a device is on this stack.

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 Why Did SGP.32 Introduce CoAP in Addition of HTTPS for IoT eSIM Provisioning? first appeared on Simplex Wireless.

Every IoT SIM provider’s homepage claims global coverage, transparent pricing, and reliable failover. Those pages don’t help you when your first two hundred devices ship. What actually differs between providers is how the pricing model behaves at your usage pattern, whether the eSIM roadmap is real or a slide, and who answers when a device goes dark.

This comparison looks at five providers buyers evaluate most often alongside Simplex: Hologram, 1NCE, Twilio Super SIM, Soracom, and EMnify. Every claim below comes from each company’s own published pricing pages, product documentation, or press releases as of mid-2026. Connectivity pricing changes often and quote-only models mean the final number for your specific volume won’t show up on any page, ours included, so confirm current terms directly before you commit.

The five providers, briefly

Hologram runs its own multi-carrier network reaching 550+ carriers in 190+ countries, with a Hyper eUICC SIM at $0.03/MB and an Outage Protection option that gives each SIM two independent mobile cores for automatic fallback.

1NCE sells a flat, prepaid model: roughly $12 to $14 covers a SIM plus ten years of service, including 500 MB of data and 250 SMS, across 173 countries. There’s no recurring bill unless you exceed the allowance and buy a top-up.

Twilio Super SIM connects to close to 400 cellular networks on a pay-as-you-go basis. Its mobile core is now operated by KORE Wireless rather than run entirely in-house by Twilio, which is worth knowing if a vendor’s own infrastructure ownership matters to your evaluation.

Soracom is a cloud-native, AWS-integrated platform spanning 500+ carriers across roughly 174 to 200 countries depending on the plan, with pay-as-you-go, pooled, and fixed-price tiers and no long-term lock-in stated in its terms.

EMnify connects through 540+ networks in roughly 190 countries, with a multi-IMSI eUICC design and a bootstrap-connectivity model well suited to manufacturers provisioning at the factory. Its pricing pages don’t publish rates; every quote is custom.

What the comparison actually shows

None of these five providers is a bad choice for the right use case, and it’s worth being straightforward about that. 1NCE’s flat-fee model is genuinely hard to beat for a low-data device with a long field life, like a smart meter that reports a few kilobytes a day for a decade: paying once and never thinking about the bill again removes an entire category of operational overhead. Hologram’s dual-core outage protection is a real, verifiable architecture, not marketing language, and its per-MB rate is published and easy to model against. EMnify’s AWS-native integrations (Transit Gateway attachment, multicloud data streaming) are a legitimate advantage for a team whose backend already lives entirely in one cloud.

Where the differences start to matter for a multi-year fleet decision:

Network reach varies less than the marketing suggests. Hologram, EMnify, Soracom, and Simplex are all in the same 500-to-550-network range. Twilio Super SIM’s roughly 400 networks is smaller, and it’s worth noting the connectivity now runs through KORE Wireless’s core rather than a platform Twilio operates end to end.

eSIM and SGP.32 readiness is uneven. Simplex, Hologram, and Soracom have shipped or are shipping production SGP.32 capability. EMnify’s Advanced eSIM reached production in 2026 after a longer runway. 1NCE’s eUICC support (branded “Freedom to Switch”) is limited to specific SIM types rather than the full product line, so a buyer standardizing on one SKU needs to check which one supports it before ordering.

Pricing transparency differs sharply. Hologram, 1NCE, and Simplex publish enough pricing structure to model a real cost estimate before talking to sales. EMnify does not publish rates at all: every number is quote-only, which makes a fair apples-to-apples comparison impossible without going through a sales process for each vendor being evaluated.

Where Simplex fits

On raw network count, Simplex sits in the same tier as Hologram, EMnify, and Soracom rather than ahead of them. That’s a fair comparison to make, and buyers should make it directly. Where Simplex’s approach differs is in three areas that don’t show up in a networks-and-countries table.

The eIM (eSIM IoT manager) server behind Simplex’s SGP.32 support was built in-house rather than licensed from a third party, and it’s been tested for interoperability with multiple eUICC manufacturers, including Kigen, STMicroelectronics, and Valid. The xoSIM product supports IPAe, so retrofitting existing hardware for eSIM doesn’t require a device redesign.

On contract terms, Simplex doesn’t require the kind of carrier lock-in that shows up in some multi-year deals, and its bring-your-own-operator option lets a team consolidate existing carrier contracts under one dashboard without switching connectivity first, something none of the five providers above publish as a core product.

On support, Simplex’s team is US-based out of Atlanta, with the engineers who built the multi-carrier failover system answering escalations directly rather than routing through a generalist ticket queue.

Where Simplex has a genuine limit worth naming against this specific set of competitors: Hologram, EMnify, and Soracom are larger operations with broader third-party integration ecosystems (native cloud provider integrations, wider public case-study libraries) than Simplex currently publishes. A team whose architecture is already deeply built around one hyperscaler’s tooling should weigh that directly rather than take coverage numbers as the deciding factor.

Questions to ask any of these providers

Ask each of the six the same questions, including Simplex:

1. Is your published pricing final, or does it change materially at my actual volume?
2. Is your eSIM management server your own, or licensed and operated by a third party?
3. What’s the average time from detection to resolution on your last ten support tickets?
4. If a device sits in a country with permanent-roaming restrictions, what happens automatically?
5. What’s the minimum commitment before I can leave, and what does leaving involve?
6. Can I see raw per-device usage data, or only account-level totals?
7. What happens to my SIMs and my data if your company is acquired or shuts down?

The decision framework

Coverage numbers cluster closer together across these six providers than the marketing suggests. The real differences sit in pricing transparency, how far along the eSIM roadmap actually is, what a contract locks you into, and who picks up the phone when something breaks. Weigh those four against your specific fleet size, data profile, and deployment timeline rather than the country count on a homepage. If you want a cost model built against your actual usage, compare plans or talk to Simplex’s engineering team directly.

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 IoT SIM Providers Compared: Simplex vs. Hologram, 1NCE, Twilio Super SIM, Soracom, and EMnify first appeared on Simplex Wireless.

Cellular IoT works well where cell towers exist. The industries that need it most are often in the places where they don’t.

The promise of IoT is visibility — knowing where your assets are, what condition they’re in, and when something needs attention. That promise holds in cities, in warehouses, in manufacturing facilities. It breaks down the moment your assets move into the 80% of the Earth’s surface that terrestrial cellular networks don’t cover. 5G NTN (Non-Terrestrial Network) IoT — the 3GPP standard that routes IoT data through LEO satellites instead of ground-based towers — is changing what’s possible for the industries where that breakdown has been most costly.

Five industries are seeing the clearest transformation. They share a common problem: the things they most need to monitor are precisely the things that end up out of range.

The industries most severely affected by coverage gaps aren’t evenly distributed. Figure 1 ranks them by what proportion of their typical operating environment falls outside reliable terrestrial coverage.

1. Maritime and offshore

A container ship leaving the Port of Los Angeles loses cellular connectivity within 20–30 kilometers of the coastline. From that point until it reaches its destination port — days or weeks later — any IoT device on board that relies on terrestrial cellular is offline. Temperature sensors on reefer containers, fuel consumption monitors, cargo condition trackers: all of them go dark.

The consequences are practical and expensive. Cold chain integrity records have gaps. Exception handling for damaged or shifted cargo can’t happen in transit. Port scheduling relies on last-known position rather than real-time location. Insurance claims require documentation that doesn’t exist because the data was never transmitted.

5G NTN IoT changes this by giving shipboard devices a connectivity path that doesn’t depend on coastal infrastructure. NB-IoT (Narrowband IoT) sensors transmit small payloads — temperature readings, position pings, hull condition data — via LEO satellite at regular intervals throughout the voyage. The data arrives at your operations center continuously, not in a burst when the vessel re-enters port waters.

The business impact is specific: cold chain compliance records become uninterrupted, cargo exception alerts fire in real time rather than after the fact, and port ETAs are calculated from live position data rather than last-known location extrapolation. For operators moving temperature-sensitive cargo — pharmaceuticals, perishables, chemicals — continuous visibility is not a convenience. It’s a compliance requirement.

2. Logistics and fleet

Long-haul trucking crosses terrain that no carrier has been paid to cover well. Rural stretches of I-70 through Kansas, I-90 through Wyoming, Highway 1 through the Canadian interior — these corridors carry enormous freight volumes and have consistent cellular dead zones measured in hours, not minutes.

Figure 2 shows what a single long-haul route looks like for a logistics operator, with and without NTN coverage.

The gap isn’t just a data inconvenience. For temperature-controlled freight, a four-hour visibility gap is a four-hour period during which a refrigeration failure could go undetected and unresponded to. For high-value cargo, it’s a period during which a route deviation or theft goes unlogged. For fleet operators under ELD (Electronic Logging Device) compliance requirements in the US, it creates record-keeping complications that require manual reconciliation.

Multi-carrier terrestrial SIMs close some of these gaps by accessing whichever carrier has the strongest signal in a given location. But in genuine dead zones — where no carrier reaches — only a satellite fallback keeps the device online. NTN-capable hardware with a hybrid connectivity architecture connects terrestrial-first and switches to satellite automatically when terrestrial coverage ends. The device doesn’t know it switched. Neither does your application. The data stream is uninterrupted.

For fleet operators, this translates to complete transit records, real-time exception alerting regardless of location, and the ability to prove chain of custody across the entire route — not just the portions where towers exist. Explore Simplex’s transportation and fleet connectivity for more on how multi-carrier SIMs perform across long-haul routes.

3. Agriculture

Precision agriculture depends on data from places that were never designed with cellular infrastructure in mind. A large arable farm in the US Midwest might span several thousand acres, with soil sensors, weather stations, irrigation controllers, and livestock trackers distributed across terrain that sits well outside the coverage footprint of the nearest carrier.

The conventional workaround is LoRaWAN gateways placed at the farm’s perimeter, aggregating sensor data locally and transmitting via whatever cellular signal is available. This works until the gateway loses signal, or until an asset — a livestock tracker, a mobile irrigation unit — moves beyond the gateway’s range. At that point, data stops.

5G NTN IoT removes the dependency on local gateway placement. Sensors and trackers with NTN-capable modems communicate directly with satellites. A soil moisture sensor bolted to a post in the middle of a 5,000-acre property transmits its readings on schedule, regardless of where the nearest tower or gateway sits. Livestock trackers report location continuously, including when animals stray to property edges or adjacent land.

The operational shift is from reactive to continuous. Irrigation decisions get made on live soil data, not on readings from the last time connectivity was available. Livestock location is known in real time, not discovered during a manual headcount. Equipment utilization is tracked across the full property, not just the areas with signal. See Simplex’s connected agriculture coverage for more on how this applies to specific farm IoT deployments.

4. Energy and utilities

Pipelines, wellheads, substations, and renewable energy installations share a locational reality: they’re built where the energy resource is, not where the infrastructure is. A gas pipeline running through a remote basin, a wind farm on an exposed plateau, a substation serving a rural distribution network — all of them generate operational data that needs to reach a control center continuously, and all of them are likely to have poor or no terrestrial cellular coverage.

The consequences of connectivity gaps in energy infrastructure are more severe than in most other sectors. A pressure anomaly on a pipeline that goes undetected for four hours because the monitoring sensor was offline is not just a data gap — it’s a liability event. A substation fault that doesn’t trigger an alarm until the device re-enters coverage is hours of unplanned outage that could have been caught and responded to immediately.

5G NTN IoT gives remote energy infrastructure the same always-on monitoring that urban infrastructure already has. Pipeline pressure sensors, flow meters, and corrosion monitors transmit continuously via satellite. Anomalies trigger alerts within minutes regardless of where the asset sits. Maintenance teams dispatch based on real data, not scheduled inspection cycles that assume the monitoring will catch what it can between visits. Simplex’s industrial IoT connectivity covers how this applies to remote energy and utilities deployments.

5. Environmental monitoring

Environmental monitoring has a fundamental placement problem: the sensors that matter most are in the locations that are hardest to connect. Flood early warning sensors belong in remote river catchments, not in town centers where connectivity is easy. Wildfire detection sensors belong in wilderness areas. Air quality monitors belong in industrial corridors, some of which have poor urban fringe coverage. Wildlife tracking collars belong on animals that move freely across landscapes with no regard for carrier footprints.

Traditional environmental monitoring networks solve this with a combination of satellite modems (expensive, proprietary, high power draw) and LoRaWAN gateways (limited range, requires local infrastructure). 5G NTN IoT offers a third path: standards-based, low-power connectivity using NB-IoT protocols over satellite, with the same SIM management infrastructure used for terrestrial IoT.

Figure 3 shows what this changes in concrete operational terms across four of these five industries.

For environmental monitoring specifically, the shift is from delayed awareness to real-time response. A flood sensor that can only transmit when cellular returns is useless for early warning. A wildfire detection sensor that goes offline during a dry wind event is precisely the sensor that needs to be online. 5G NTN IoT makes it possible to place sensors where they’re needed and get data from them reliably — not where connectivity happens to exist.

These five industries aren’t early adopters experimenting with satellite IoT. They’re sectors with long-standing connectivity problems that terrestrial networks were never designed to solve. 5G NTN IoT — built on the same 3GPP standards as the cellular infrastructure these industries already use — gives them a practical path to continuous visibility across the full geography of their operations.

Simplex Wireless is bringing NTN connectivity to the same platform our customers already use for terrestrial IoT SIM management. Get in touch if you’re evaluating NTN for a specific deployment, or explore our IoT connectivity options to see how terrestrial and satellite connectivity work together.

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 5 Industries Being Transformed by 5G NTN IoT first appeared on Simplex Wireless.

Each of these sounds like a five-second question. For most teams, it isn’t — here’s why, and what changes when it actually is.

“How many devices are active in Finland right now?” “Which SIM used the most data last week?” “Does Vodafone support LTE-M in Germany?” Ask any of these out loud in a network operations meeting and someone will have a rough answer within a minute. Ask for the exact number, confirmed, sourced, and current, and the same question can take an afternoon.

Why a simple-sounding question turns into an afternoon

None of these questions are hard in the abstract. The difficulty is that the answer to each one usually lives in a different place than the question was asked. “How many devices are active in Finland” means filtering a device list by country and by connection status, which may live in two different views. “Which SIM used the most data” means sorting a usage report that most dashboards don’t let you sort the way you actually want. “Does Vodafone support LTE-M in Germany” isn’t in your account data at all; it’s a carrier and technology lookup that means leaving your own tools entirely.

Add two more questions to the list, because they follow the same pattern: “Which devices had an unusual spike in data this week?” and “Which devices have gone quiet lately?” Both are simple to state and both usually mean someone manually scanning a usage report or a connection log looking for outliers, because most dashboards show you the current state, not the anomaly.

Why IoT data makes this worse than typical IT monitoring

Standard IT monitoring tools were built around a smaller, more uniform set of things: servers, endpoints, maybe a handful of locations. An IoT fleet routinely spans multiple countries, multiple carrier technologies, and thousands of individual SIMs, each with its own usage pattern and connection history. Every one of the five questions above cuts across at least two of those dimensions — country and status, device and usage, operator and technology, device and trend.

A dashboard built to show usage by device will not, by default, also let you filter by country. A dashboard built to show device status will not, by default, flag which of those devices is behaving differently than its own baseline. Each additional dimension means either a new view someone has to build in advance, or a manual cross-reference after the fact. That is the actual mechanism behind why fleet teams often find they spend more time finding IoT data than acting on it: not because the data is missing, but because it is scattered across views that were each built for a narrower question than the one being asked.

What the delay actually costs

The cost of these delays is not evenly distributed. A usage spike that takes three days to identify has already run up data charges for three days. A device that goes quiet and is not flagged for a week is a device that has been silently offline in the field for a week, possibly at real operational cost if it is a security camera, a tracker, or a piece of monitored equipment. Connection quality issues follow the same pattern: a rising drop rate on one carrier often goes unnoticed until it has already affected a meaningful share of a fleet, at which point the fix is reactive rather than preventive — the same failure mode behind why an IoT device keeps losing connection in the first place.

The coverage question has a different but equally real cost. A team planning a deployment in a new country that assumes an operator supports a given technology, without confirming it, can find out mid-rollout that the assumption was wrong. At that point the cost is not a data charge but a delayed launch and a scramble to find an alternative. Coverage maps lie more often than most teams expect, and confirming support ahead of time is the difference between a five-second question and a week of delay.

What changes when the answer is instant

The fix is not a new dashboard with more filters. Every additional filter option is still something a person has to know exists and remember to use. The fix is removing the dashboard from the path between the question and the answer entirely.

Three things follow from that shift. First, anomalies get caught while they are still cheap: a spike or a drop-rate change gets flagged and confirmed the same day it starts, not the week it shows up on an invoice. Second, coverage and technology questions get answered before a deployment commits to hardware, not during it. Third, the questions stop being routed through whoever happens to have report access, because asking in plain English does not require knowing where a metric lives or how to build a filtered view. That last point matters as much as the speed does — your IoT network data exists, and getting an answer from it shouldn’t take this long for anyone on the team, not just the person who happens to know the dashboard.

None of the five questions above are actually hard. What’s hard is the distance between asking them and getting an answer. Close that distance and they go back to being exactly as simple as they sound.

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 Five Questions Every IoT Team Asks Their Network (and Why They Usually Take Too Long to Answer) first appeared on Simplex Wireless.

A SIM management portal is operational infrastructure. If you can’t see your fleet in real time, you’re already behind.

If your current portal shows you a list of SIM cards and a monthly data total, you don’t have a fleet management tool. You have a billing summary dressed up as a dashboard. The gap between those two things is where outages go undetected, where fraudulent usage compounds, and where a five-minute fix becomes a truck roll.

This article lays out what a SIM management portal should actually do — so you can evaluate what you have, identify what’s missing, and know what to ask for.

The Six Things Your Portal Must Show You

A SIM management portal earns its name by giving you genuine operational control over your fleet. That means six specific capabilities. The absence of any one of them is a gap that costs real time and money.

Per-device usage in real time. Not yesterday’s data. Not a 15-minute delay. Every device in your fleet should be visible with current connection status, data consumed in the current billing period, and last active timestamp. When a device goes dark, you should know within minutes — not when a customer calls.

Historical consumption trends. Real-time data tells you what’s happening now. Historical trends tell you what’s normal so you can detect what isn’t. A device that typically sends 50 MB per month and suddenly consumes 2 GB has a problem. You can only see that if you have history to compare against.

Configurable alert thresholds. The portal should let you set data consumption limits per SIM or per group, and send an alert when a device crosses them. This is the difference between proactive operations and reactive firefighting. An alert at 80% of a plan limit gives you time to act. Finding out at 150% means you’re already dealing with a bill.

Fraud detection signals. This is where most low-end portals fall short entirely. Your portal should flag sudden foreign roaming — a device that was connecting in Ohio showing up on a network in another country without explanation. It should also detect wrong-device type usage: a SIM provisioned for a utility meter consuming gigabytes of data is almost certainly in a different device than the one it was assigned to. Simplex’s portal surfaces both of these automatically.

Sub-account structures. If you operate a fleet with multiple device types, customer accounts, or geographic regions, you need to be able to segment visibility accordingly. A sub-account lets a managed service provider see only their own devices. It lets an operations team see only the devices they’re responsible for. Without it, a 10,000-device fleet is an undifferentiated list.

On-demand exports. Billing reconciliation, capacity planning, and audit trails all require data you can pull and work with outside the portal. On-demand CSV or API export isn’t an advanced feature — it’s baseline.

What Happens Without These Capabilities

The cost of a poor portal isn’t always visible on a single line of a P&L. It shows up in aggregated operational drag — support tickets that shouldn’t have been raised, truck rolls that could have been remote fixes, bill shock from usage that was visible in the data for weeks before it became a problem.

The most serious failure mode is what’s sometimes called silent device failure. A device stops transmitting data. Its SIM remains active and appears connected at the network level. Nothing in your billing changes because the SIM is still registered. Nobody raises a ticket because no alert fired. The device could be offline for days or weeks before a field technician checks on it or a downstream system flags the missing data. A portal with real-time per-device visibility catches this immediately. A portal without it doesn’t catch it at all.

The fraud case is equally instructive. A SIM provisioned for a utility meter sits inside an enclosure that gets broken into. Someone removes the SIM and puts it in a tablet. Data consumption goes from roughly 5 MB per month to several gigabytes in days. Without wrong-device detection, you find out when the overage invoice arrives. With it, you find out within hours and can deactivate the SIM before the damage compounds. The Simplex management portal surfaces this automatically, flagging the device type mismatch as soon as the consumption pattern departs from provisioned behavior.

The billing opacity problem is subtler but persistent. If your portal can’t export usage data on demand, you’re reconciling invoices manually against whatever the carrier provides. For fleets of a few hundred SIMs this is annoying. For fleets of thousands, it’s a material operational cost.

API Access Is Not a Premium Feature

A portal without API access is a closed system. Every action that can’t be automated stays manual: pulling usage reports, adjusting data caps, deactivating SIMs when devices are decommissioned, integrating fleet status into your own monitoring stack.

For small deployments, manual portal operations are manageable. For anything above a few hundred devices, the absence of API access compounds with scale. An operations team managing 2,000 devices shouldn’t be logging into a portal to deactivate 50 SIMs when a batch of hardware is retired. That’s an API call.

The API also matters for alerting. Your SIM provider’s built-in alerts are useful, but they’re not integrated into your existing incident management system. If you use PagerDuty, OpsGenie, or any on-call rotation tooling, you need API access to route SIM alerts through the same channels as every other infrastructure event. A SIM going dark should trigger the same workflow as a server going down. Without API access, it doesn’t.

Sub-Accounts: Why Fleet Structure Matters at Scale

Sub-accounts are the feature that separates a portal built for small deployments from one built for organizations running connected hardware at any real scale.

The use cases are straightforward. A managed service provider deploying IoT devices on behalf of multiple end customers needs each customer to see only their own devices — not the full fleet. A company running both a fleet tracking product and an asset monitoring product wants separate billing and separate alert channels for each. A team responsible for devices in Europe doesn’t need visibility into devices in North America.

Without sub-account support, the only way to achieve any of this is to run separate accounts with separate billing relationships — which means separate invoices, separate support contacts, and no aggregate view when you need one. Sub-accounts give you the hierarchy: a parent account with full visibility, and child accounts with scoped visibility and their own administrators.

The operational cost of not having this scales with fleet size and organizational complexity. It’s barely noticeable at 100 devices. At 5,000 devices across three business units, it becomes a genuine management problem.

What to Do When Your Current Portal Falls Short

The honest answer is that not every SIM provider has invested meaningfully in their portal. Many legacy providers treat it as a secondary product — something that exists to show you’ve been billed correctly, not something designed to run fleet operations.

If you’re evaluating your current portal against the six capabilities above and finding gaps, the question is whether those gaps are fixable within your current provider relationship or whether they represent a structural limitation of their platform.

Ask directly: does the portal have per-device real-time status? Is there API access for programmatic SIM management? Can you configure alert thresholds per SIM? Does fraud detection flag device type mismatches automatically? If the answers are no, that’s not a roadmap item — it’s an architectural gap that’s unlikely to close.

For teams assessing a provider switch, the consumer SIM vs IoT SIM comparison covers the management layer difference in detail. And for the business case behind investing in proper fleet visibility before outages occur, the real cost of connectivity failures post in this series quantifies what poor visibility actually costs.

What the Simplex Portal Provides

The Simplex management portal is included with every IoT SIM at no additional cost. It’s not a paid upgrade or an enterprise tier — it’s part of the product.

It gives you real-time per-device status, historical consumption data, configurable alert thresholds, automatic fraud detection for sudden foreign roaming and wrong-device type usage, sub-account creation for fleet segmentation, full API access for programmatic management, and on-demand usage exports. The portal also handles BYOO (Bring Your Own Operator) — if you have existing carrier SIMs you’re not ready to migrate, you can bring them under the same dashboard without changing the underlying carrier relationship.

Support is US-based in Atlanta, Georgia. When something goes wrong in your portal, you talk to the people who built and manage the platform.

If your current portal doesn’t give you what you need, take a look at what the Simplex IoT SIM includes at simplexwireless.com/iot-data-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 What Your IoT SIM Dashboard Should Show You (And What to Do When It Doesn’t) first appeared on Simplex Wireless.

Most IoT failures aren’t hardware failures. They’re coverage failures — and they happen without warning.

A GPS tracker shows a truck leaving a distribution center in Kansas City. Three hours later, it shows the truck arriving at a depot in Denver. What happened in the 400 miles in between? Nothing — at least, nothing your system recorded. The device was running. The sensors were sampling. But somewhere along I-70, the cellular signal dropped, and the data stream stopped. By the time coverage returned, the connection had long since timed out.

This is one of the most common — and least visible — failure modes in deployed IoT. Understanding why it happens, and what you can do about it, starts with understanding how cellular connectivity actually works for IoT devices.

How cellular IoT connectivity works — and where it breaks

A cellular IoT device connects to the network the same way a smartphone does: it powers on, its SIM (Subscriber Identity Module) authenticates with a carrier, and the device registers on the network. Once registered, it can send and receive data.

The difference is that IoT devices are designed for environments where cellular infrastructure is inconsistent. A smartphone user who loses signal notices immediately and usually moves somewhere with better coverage. A soil sensor bolted to a fence post in rural Nebraska has no such option.

When a cellular IoT device — running NB-IoT (Narrowband IoT), LTE-M, or standard LTE — moves beyond the footprint of its registered carrier, the sequence in Figure 1 plays out.

The critical moment is step 3. The modem deregisters silently. No alarm fires in your application. No error message appears. From your backend’s perspective, the device simply stops sending data. Whether that silence lasts two minutes or two days depends entirely on how long the device stays outside coverage — and whether your monitoring logic is configured to detect the absence of data, not just the presence of bad data.

Many deployments aren’t. Most alerting systems are built around threshold breaches — a temperature too high, a pressure reading too low. A device that stops reporting entirely slips through, because the value never changes: it just doesn’t arrive.

Why IoT makes this problem worse than it is for consumer devices

Consumer cellular devices are designed around the assumption that the user is mobile and will return to coverage. The network and the device both reflect this. When a smartphone loses signal, it enters a low-power search mode, periodically scanning for available carriers. When coverage returns, it re-registers and resumes operation, usually within seconds.

IoT devices face a different set of constraints. Many are battery-powered and designed to transmit infrequently — hourly, or even daily — using protocols like NB-IoT or LTE-M with Power Saving Mode (PSM) enabled. PSM allows the modem to power down almost completely between transmissions, extending battery life to years. The trade-off is that when the device wakes to transmit and finds no coverage, it may exhaust its search window, fail to register, and go back to sleep. The next transmission attempt might be an hour away. The gap in your data grows.

The other compounding factor is single-carrier SIM behavior. Many IoT deployments use SIM cards provisioned to a single carrier. When that carrier’s signal ends, the device has nowhere to go. Figure 2 shows the difference in outcome between a single-carrier SIM and a multi-carrier SIM when terrestrial coverage ends.

The device hardware is identical in both scenarios. The firmware is identical. The only difference is the SIM — and whether it carries agreements with more than one carrier in that geography.

This is why coverage maps routinely mislead. A map from Carrier A showing strong coverage in a region tells you nothing about what happens when your device drifts outside Carrier A’s footprint into an area covered only by Carrier B or C. For a single-carrier SIM, that difference is total: connected versus not connected.

Where the consequences show up

Coverage loss isn’t a theoretical problem. Figure 3 shows four industries where it translates directly into operational and financial cost.

Each of these industries shares a structural reality: the assets that matter most are often in the places with the worst coverage. A fleet truck that never leaves a metro area is easy to track. The one that matters — the one carrying temperature-sensitive pharmaceutical cargo across a rural stretch — is the one most likely to go dark.

The pattern repeats across sectors. The pipeline segment most likely to develop a fault is in a remote basin with no cellular infrastructure nearby. The livestock tracker most likely to matter is on an animal that wandered to the edge of the property, beyond the coverage boundary. The container most likely to be needed in an exception workflow is the one that spent 12 hours in a dead zone.

This is the core problem: traditional terrestrial IoT connectivity is designed around where infrastructure already exists. Many of the things worth monitoring are in places where infrastructure doesn’t.

What to do about it

Three steps, in order of impact.

1. Audit where your devices actually lose signal — not where the map says they should.

Coverage maps are modeled predictions, not field measurements. Before deploying at scale, test devices on the routes and locations they’ll actually operate in. Log RSSI (Received Signal Strength Indicator) over time. Identify the gaps. This is the only way to know whether your coverage problem is solvable with a better SIM or whether it requires a different connectivity layer entirely — such as 5G NTN satellite connectivity for genuinely remote applications.

2. Switch to a multi-carrier SIM for any device that moves or operates outside major population centers.

A multi-carrier IoT SIM carries roaming agreements with multiple carriers and selects the strongest available signal automatically. In most rural coverage gaps, the problem isn’t that no carrier reaches the area — it’s that your SIM only talks to one of them. Switching to a multi-carrier SIM resolves this without any hardware or firmware change.

3. Build absence-of-data alerting into your monitoring logic.

Your application should treat silence as a signal, not a neutral state. If a device that normally reports every 15 minutes goes 45 minutes without a transmission, that should trigger an alert — even if the last reading was within normal range. Most IoT middleware platforms support heartbeat monitoring. If yours doesn’t, configure it at the application layer. A data gap is not a non-event. It’s information about where your coverage ends.

The coverage map will always look better than the field reality. Traditional cellular IoT connectivity is designed for the 20% of the Earth’s surface that terrestrial networks cover well. The other 80% — and the assets operating at the edges of the 20% — requires a deliberate connectivity strategy, not the assumption that one carrier’s footprint is enough.

If you’re seeing unexplained data gaps in your IoT deployment, explore Simplex’s multi-carrier IoT SIM plans — or get in touch to talk through what’s happening in your specific geography.

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 Why Traditional IoT Stops Working When Coverage Ends first appeared on Simplex Wireless.

Every eSIM spec before SGP.32 put control in the hands of the OEM or the MNO. This one hands the keys to the person actually running the fleet.

Ask an enterprise IT admin who controls their laptops and they’ll point to a mobile device management console. Ask the same person who controls their cellular subscriptions and, until recently, the honest answer was: not them. That’s what changes with the eIM, and it’s worth being precise about why.

What the eIM actually is

The GSMA’s official name for it is the eSIM IoT Manager, the new server-side component defined in the SGP.32 specification. But that name undersells what it does. Functionally, the eIM is Enterprise eSIM Management: it’s the first component in the entire eSIM ecosystem built to be operated directly by enterprise IT, not routed through a carrier’s back office or baked into a device’s firmware at manufacturing.

That’s a genuinely new role. Earlier specs split control between two parties who were never the enterise’s own staff. SGP.22, the consumer-facing standard, relies on the LPA (local profile assistant), software living on the device and controlled by the OEM. SGP.02, the M2M standard, relies on the SM-DP+ (subscription manager data preparation), a profile server controlled by the MNO. In both cases, if you wanted to change a subscription, you were asking someone else’s system to do it for you.

The eIM changes that by giving enterprise IT a system they can operate themselves, provisioning, switching, and monitoring eSIM profiles across a fleet the same way an SGP.32 approach was designed specifically for unattended devices that do not have user interfaces and must be managed autonomously. It’s a close cousin of mobile device management (MDM), the category IT teams already use to push software and policy to a fleet of laptops and phones. MDM manages what’s installed on the device. The eIM manages the mobile subscription itself, the eSIM profile that determines which network the device talks to.

Why this is a paradigm shift, not an upgrade

Call it a spec update and you’ll undersell it. Every prior eSIM generation assumed the enterprise deploying the device was a passive party, someone who negotiated a contract, then lived with whatever provisioning process the OEM or MNO had built. SGP.32 was designed specifically for unattended devices that do not have user interfaces and must be managed autonomously, and that autonomy requirement is what forced the spec to define a genuinely independent management layer for the first time.

The practical result: an enterprise IT admin can now sit in front of a single console and provision, swap, or retire eSIM profiles across thousands of devices without opening a ticket with a carrier or waiting on a firmware update from an OEM. That’s the same shift MDM caused when it moved software management off the manufacturer’s release cycle and onto the IT team’s own timeline.

What independence actually requires

Here’s where the paradigm shift can quietly fail. An eIM only delivers on this promise if it’s genuinely independent of three parties: the MNO, the OEM, and the EUM (the eUICC manufacturer, the company that makes the physical SIM chip). If an eIM is built or operated by any one of those three, the enterprise hasn’t gained control, it’s just moved the lock-in one layer up the stack.

This is exactly where Simplex built its eIM differently from day one. It’s designed to give enterprises independence rather than route control through a single connectivity provider, with interoperability tested across multiple EUMs rather than tied to one manufacturer’s chip. The R&D and support behind it are based in the US, which matters practically: when an enterprise IT admin needs to escalate a provisioning issue at 2am, they’re talking to the team that built the platform, not a support queue three time zones away.

Where this goes wrong

The most common failure mode isn’t a technical one, it’s a vendor relationship that recreates the old lock-in under a new name. If the eIM you adopt is operated by your existing MNO, you haven’t gained carrier independence, you’ve just moved the control panel. If it only supports one EUM’s eUICC, your next hardware order is constrained by whatever chip that eIM was built around. And if the eIM vendor has no track record running systems at carrier-grade reliability, unattended fleets are the wrong place to find that out. The lessons from running SGP.32 at scale point the same direction: the platform has to stay available under all conditions, because devices depend on it to restore their own connectivity.

The eIM didn’t just add a feature to eSIM, it added a stakeholder. For the first time, the enterprise IT admin running the fleet has a system built for them, not adapted from something the OEM or MNO already had. That’s worth evaluating carefully before you pick a vendor, because the independence is the entire point, and it’s the one thing that’s easy to lose if you’re not checking for it.

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 eIM Is the First Enterprise System eSIM Has Ever Had first appeared on Simplex Wireless.

A device’s SIM decision gets made once, usually early, and it’s expensive to unmake later — here’s what actually determines the right choice.

Most teams pick a SIM form factor the same way they pick a connector size: whatever fits the board. That works until the device needs to switch carriers two years into a five-year deployment, and the team discovers the physical package they chose has nothing to do with whether that switch is even possible.

What these terms actually are

2FF, 3FF, and 4FF are GSMA-defined size standards for a removable plastic SIM — what most people know as mini-SIM, micro-SIM, and nano-SIM. They sit in a tray or slot and can be physically pulled out and swapped. MFF2 is a different physical standard: a small solderable chip package, mounted directly onto the circuit board rather than inserted into a socket. It’s built for devices that won’t be opened for routine service.

Here’s the point most comparisons get wrong: eSIM isn’t a size. It’s a capability. An eSIM is a SIM built around an eUICC (embedded universal integrated circuit card) — a chip that can hold more than one carrier profile and switch between them remotely, without anyone touching the hardware. That capability is governed by GSMA specifications: SGP.02 for the original machine-to-machine remote provisioning model, SGP.22 for consumer devices, and SGP.32 for the newer specification built specifically for IoT fleets.

The two ideas are independent. An MFF2 chip can ship as a fixed, single-profile SIM, or it can ship as an eUICC capable of remote profile swaps. The same is true of a 4FF nano-SIM. “Which form factor” and “does it support eSIM” are two separate questions — and answering only the first one is exactly how teams end up locked into a carrier they didn’t mean to commit to permanently.

How this differs from the old approach

The older model treated the SIM as a one-time decision: pick a physical size that fits the device, order it pre-loaded with one carrier’s profile, and if the carrier relationship ever needs to change, send someone to physically remove and replace the card. That’s workable for a 2FF or 4FF SIM sitting in an accessible tray. It’s close to impossible for an MFF2 chip soldered into a sealed enclosure — the “swap” becomes a hardware respin.

An eUICC changes what happens after the SIM ships, not how it’s packaged. Instead of a fixed profile burned in at manufacturing, the chip holds a slot that can be reprovisioned over the air. The mechanics, explained in more depth elsewhere, work the same way regardless of whether the underlying chip is MFF2 or a removable cut:

What this means in practice

The practical decision splits into two independent choices, not one.

First, pick the physical package based on the device, not the carrier plan. If the enclosure is field-serviceable and someone can reasonably open it during the device’s life, a removable 2FF, 3FF, or 4FF SIM keeps that option cheap and simple. If the device is sealed, exposed to vibration, or expected to run for years without physical access — the pattern covered in more detail when comparing consumer, industrial, and automotive SIM grades — MFF2 is the more durable answer regardless of which carrier ends up on it.

Second, and separately, decide whether the carrier relationship might ever need to change: a multi-year regulatory shift, a coverage gap in one region, a renegotiation at renewal. If there’s any real chance of that, specify eUICC capability on the chip — ideally with IPAe, the on-SIM implementation defined in SGP.32 that lets existing hardware become eSIM-ready without a retrofit. That decision costs nothing to make correctly up front and a full hardware respin to fix later.

Where it goes wrong

The most common failure is treating “MFF2” and “eSIM” as synonyms — ordering a solderable chip and assuming it can be reprovisioned remotely, only to discover during a carrier renegotiation that it shipped as a fixed, single-profile part. The fix at that point is a new board revision, not a software update.

A second failure shows up in the opposite direction: choosing a 4FF nano-SIM for a device that will actually sit in a vibration-heavy environment, because nano-SIM was the default in the reference design. The connector, not the chip, is usually what fails first, and it tends to fail in the field rather than in testing.

A third, documented in more depth elsewhere, is assuming eSIM provisioning happens the way it does on a consumer phone — a two-minute activation. IoT provisioning across a fleet of unattended devices has more steps and more places it can stall, and planning for that difference in advance avoids a rollout that looks broken when it’s actually just slower than expected.

The decision, in short

Form factor and eSIM capability answer two different questions: how the SIM is physically packaged, and whether the carrier relationship on it can ever change without touching the hardware. Get both answers right at the design stage, and the SIM stops being a recurring decision at all. Simplex’s engineering team can walk through both questions against a specific device and deployment plan, and a trial SIM is the fastest way to confirm the combination works before it’s locked into a board revision.

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 MFF2 vs 2FF/3FF/4FF vs eSIM: Choosing a SIM Form Factor first appeared on Simplex Wireless.