Cell coverage reaches about 20% of Earth's land surface. If you're deploying IoT devices, that's probably been fine so far. Most prototypes, pilot sites, and early customers are in places with towers.
The harder deployments aren't. A water pump 200km from anything. Cattle stations in central Australia. Cargo containers on the Pacific. Until recently, these needed a completely different connectivity stack — proprietary hardware, separate firmware, closed ecosystems.
In 2022, 3GPP extended NB-IoT to work over satellite links. Your device uses the same protocol, modem, and SIM it already has. The satellite is just another cell tower, except it's in orbit.
3GPP is the standards body behind the cellular protocols most IoT devices use — NB-IoT, LTE-M, 4G, 5G. In 2022, they extended those standards to work over satellite links, under the umbrella term Non-Terrestrial Networks (NTN). The key point is that this is not a new protocol. It's the same NB-IoT your device already speaks, adapted for the higher latency and Doppler effects of talking to something in orbit.
Hardware caught up too. A modem like the Nordic nRF9151 handles LTE-M, NB-IoT, and satellite NTN from a single chip. When your device is near a cell tower, it connects normally. When it's not, it connects through a satellite. Your application code doesn't know the difference.
The previous generation of satellite IoT didn't work this way. Proprietary protocols, dedicated hardware, closed ecosystems. SpaceX's Swarm service shut down entirely in March 2025. The market is consolidating around the 3GPP standard, and multiple satellite networks now support it — some geostationary (always visible, but 600ms latency), others low-earth orbit (30-50ms, coverage still expanding). Several work with the same modem hardware, so you're not locked to a single operator.
Satellite connectivity costs roughly 700-900 times more per byte than terrestrial cellular. But if you're monitoring a $50,000 pump in a remote location, "no data" costs more than "expensive data."
The economics work when three conditions are true:
The asset is valuable. A water treatment sensor in a rural catchment area. Agricultural equipment monitoring across thousands of hectares. A cargo container carrying temperature-sensitive goods across an ocean. If losing visibility on that asset costs more than the connectivity, satellite makes sense.
The data is small and infrequent. A 50-byte sensor reading sent once per hour costs roughly EUR 0.04 at satellite rates. Once per day, it's fractions of a cent. That's affordable. Streaming video or sending readings every second is not. Design your reporting frequency for the connectivity path.
There's no terrestrial alternative. Cell coverage reaches about 20% of Earth's land surface. If your deployment is in the other 80%, or if it crosses between covered and uncovered areas, satellite fills the gap. A device on a fishing vessel, a pipeline sensor in the desert, a weather station in a national park. These don't have a cellular option.
The strongest pattern is hybrid: cellular when available, satellite as fallback. The device transmits at normal frequency on cellular, then switches to less frequent, smaller payloads when it's on satellite. Same firmware, different reporting intervals based on what the network supports.
If you're building an IoT product today, the data flow looks like this:
→ Device (ESP32, nRF9151, or any NB-IoT modem)
→ NB-IoT (terrestrial or satellite, automatic)
→ Network infrastructure (ground station + core)
→ Protocol translation (NB-IoT → HTTP)
→ Cloud IoT platform (dashboards, mobile apps, alerts)
Satellite doesn't change what your cloud platform receives. The protocol translation layer, whether run by a network operator or middleware provider, converts device messages to HTTP or MQTT before they reach your application. Your platform receives webhooks or API calls just like it would from a terrestrial device.
Downlink works too, but it's asynchronous. You send a command, the middleware queues it, and the device receives it on its next uplink. For satellite-connected devices that check in periodically, commands aren't instant — so batch configurations rather than real-time control.
Blynk already works with satellite-connected devices through several paths. Iridium selected Blynk as the software partner for their Certus 9704 satellite development kit — that blueprint ships with firmware, dashboards, and device management ready to go. Myriota has a dedicated integration in the Blynk console with its own JavaScript payload decoder. And for other satellite networks, any middleware that can call Blynk's HTTP API works — use Data Converters to parse the incoming payload format.
The common thread: Blynk doesn't need to know how the data got there. Whether it arrived via cell tower, satellite, or LoRaWAN gateway, the platform handles it the same way. Dashboards, mobile apps, automations, and alerts all work regardless of the transport.
If you're evaluating satellite IoT for a product, three things are worth checking:
Satellite IoT isn't for every deployment. It's for the ones where the alternative is no connectivity at all. The new opportunity is that it no longer requires a separate technology stack. Standard protocols, dual-mode modems, and platforms that already support satellite mean you can prototype satellite IoT the same way you'd prototype any connected device.
Blynk is a low-code IoT platform used by 5,000+ businesses to build, deploy, and manage connected products. Start building →
.png)
