When the Thing Goes Quiet: RF Interference, Jamming and the Blind Spot in IoT Monitoring
Modern monitoring pages you when a system stops doing useful work. But a jammed IoT device does not report an error. It sends nothing at all, and silence is the one symptom cloud-style observability was never built to catch.
Every IoT link, whether cellular, satellite or LoRaWAN, is a radio link, and radio can be jammed or interfered with. GNSS jamming has already turned from a conflict-zone curiosity into a daily fact of European aviation, and the same physics applies to the networks industrial IoT runs on. The problem is that the standard monitoring playbook assumes the telemetry arrives. When the radio layer is denied, the device goes silent rather than erroring, so resilience has to be designed in below the application, before the thing ever stops talking.
The playbook that assumes the network
There is a well-known monitoring playbook for modern infrastructure, circulated widely in Datadog's Monitoring Modern Infrastructure guide, and most of it is excellent. Treat hosts as cattle, not pets. Instrument everything. Alert liberally but page judiciously. Above all, page on symptoms rather than causes: raise the alarm when the system stops doing useful work, because that is what your users actually feel.
It is a framework built for the cloud, and in the cloud it holds up well. But it carries one assumption it never examines, because in a data centre the assumption is safe: that the network underneath is a reliable substrate. The telemetry gets through. The question is only whether the numbers inside it look healthy.
Take that framework out of the data centre and bolt it onto a fleet of cellular meters, LoRaWAN sensors or satellite trackers, and the assumption quietly breaks. In physical IoT the transport is not a given. It is the single most exposed layer in the whole stack, and its failure mode is not a red metric. It is absence.
Every link is a radio link
Strip an IoT deployment back to its foundations and the last hop is almost always a radio. That is the whole point of the field: no cable to the meter in the vault, no fibre to the sensor on the hillside. Convenience and reach come from the air interface, and the air interface is shared, finite and, by its nature, open to anything else transmitting on the same frequencies.
The bearers differ in important ways. Licensed cellular, unlicensed LoRaWAN and satellite-based non-terrestrial networks sit in different parts of the spectrum with different legal protections and different resilience characteristics. What they share is the fundamental exposure: a strong enough unwanted signal on the right frequency, close enough to the receiver, degrades or denies the link. That is not a design flaw in any one technology. It is physics that applies to all of them.
| Bearer | Spectrum | Interference exposure |
|---|---|---|
| Cellular (4G, 5G, LTE-M, NB-IoT) | Licensed, operator-exclusive | Legally protected and monitored by the operator, but the radio link is still physically deniable at close range |
| Satellite / NTN (NB-NTN, direct-to-device) | Licensed, signals arrive faint from orbit | Inherits the weak-signal exposure that already plagues GNSS; a faint downlink is the easiest kind to overpower |
| LoRaWAN | Unlicensed ISM (868 MHz in the UK and EU) | Shared band, contention-based access, no exclusivity; peer-reviewed studies show both deliberate low-cost jamming and accidental co-channel interference degrade it |
| GNSS (GPS, Galileo) | Licensed, extremely weak signals | The cautionary tale: jamming and spoofing are now routine across large regions, and many IoT devices depend on it for time and position |
The interference problem has left the conflict zone
This used to be a niche worry. It is not any more, and satellite navigation is where the change is most visible. Aviation reporting counted well over 120,000 flights affected by GNSS interference in just the first four months of 2025, and the disruption is no longer a scatter of isolated dots. Regulators now describe large, persistent zones across the Baltic, Eastern Europe, the Black Sea, the eastern Mediterranean and the Middle East through which hundreds of commercial aircraft pass daily.
The specifics are striking. Around Vilnius, pilots reported more than 800 interference cases in the final quarter of 2024, against 124 in the same period a year earlier. Finnair suspended flights to Tartu in Estonia in 2024 after repeated outages made landings impossible, and in September 2025 a flight carrying the European Commission president was disrupted over Bulgaria. In March 2026 EASA and EUROCONTROL published a joint action plan whose working assumption is blunt: this interference will persist for the foreseeable future, so the task is resilience, not elimination.
GNSS is not the data channel for most IoT, but it is the clearest public demonstration of a general truth: weak radio signals are cheap to deny, the equipment to do it is widely available, and the number of actors willing to use it is climbing. The same logic reaches the data bearers. In the UK, operating a jammer against any wireless service is a criminal offence under section 68 of the Wireless Telegraphy Act 2006, carrying up to two years in prison and an unlimited fine, and the government opened a call for evidence in 2026 on tightening the rules around possession. Illegality has never been the same thing as impossibility.
Licensed does not mean immune
It is tempting to sort the bearers into safe and unsafe. The reality is a spectrum of exposure rather than a binary.
Licensed cellular is the strongest position. The operator owns the spectrum, actively monitors it, and has legal recourse against interference. That deters casual disruption and means accidental clashes get investigated. It does not repeal physics: a determined local transmitter can still deny a cell, which is precisely why jammers are banned rather than merely discouraged.
LoRaWAN sits at the other end. It runs in the unlicensed 868 MHz band in the UK and EU, which it shares with anything else entitled to use that spectrum. There is no exclusivity to protect and no operator watching the band on your behalf. Peer-reviewed research has repeatedly shown that its contention-based access and lightweight physical layer can be disrupted with inexpensive, off-the-shelf software-defined radios, and, just as importantly, that ordinary congestion and co-channel interference degrade it without any malice at all. For a hobby sensor that is a nuisance. For leak detection or grid monitoring it is a design constraint.
Satellite and non-terrestrial IoT inherit the GNSS lesson. A signal that has travelled from orbit arrives faint, and faint signals are the easiest to bury. NTN extends genuine reach into places nothing else covers, which is exactly why it matters, but it does not sidestep the underlying exposure.
Denial is cheap and defence is expensive. A small amount of energy on the right frequency can silence a link that took real money to design, deploy and certify. And the threat is not only hostile: accidental interference, spectrum congestion and faulty nearby equipment produce the same outage. A resilience plan that only imagines attackers will still miss most of the real-world silences.
Why monitoring misses it: silence is ambiguous
Here is where the cloud playbook and the physical world part company. Symptom-based alerting works because a struggling service emits evidence: error rates climb, latency stretches, success rates fall. You page on the shape of that evidence. A jammed device emits nothing. There is no 5xx, no p99 spike, no queue depth to read. The signal you were going to alert on is the very thing that has been taken away.
Worse, silence is ambiguous. When a device stops checking in, has it been jammed, or has it simply entered a deep power-saving sleep, as NB-IoT endpoints are designed to do for days at a time? Is it out of coverage, flat-batteried, physically destroyed, or genuinely under attack? The monitoring layer, sitting up at the application, cannot tell these apart from the absence of a packet. That ambiguity is why so many fleets treat a quiet device as probably fine, and why a real denial can hide inside the noise of normal, expected quiet for far too long.
In the cloud you alert on bad data arriving. In the field you also have to alert on good data failing to arrive. Designing that second alarm, the one that fires on absence, is the part the standard playbook leaves out, and it is the part that matters most when the radio layer is under pressure.
Designing for silence: resilience outside the box
If you cannot page on a symptom the device is unable to send, you have to move the resilience below the application and build it into the connectivity and the endpoint themselves. Think of it in layers.
Alert on absence, not just on anomalies
Give every device an expected check-in window and treat a missed heartbeat as a first-class event, the way an industrial system treats a dead-man's switch. Silence should trigger investigation, not a shrug. Tuning that against legitimate power-saving sleep is the hard part, and it is exactly the work the application-layer view cannot do for you.
Read the radio layer directly
Most cellular modems report signal quality, and many can flag jamming or abnormal RF conditions. A sudden collapse in RSRP or a rising noise floor is telemetry in its own right. Treat it as a monitored metric, not a diagnostic you only check after something has already gone wrong.
Diversify the bearer, not just the SIM
Dual-SIM failover across two operators is the baseline, and a dual-modem router with two independent radios hardens it further. But two SIMs on the same 4G band share a failure mode if that band is denied locally. Genuine resilience means diverse bearers: cellular with a satellite or NTN fallback, so that one jammed slice of spectrum is a degradation rather than a blackout.
Make the edge autonomous
A device that keeps doing its job and buffers readings when the link dies turns an outage into a delay rather than a data loss. Store-and-forward at the edge, plus safe local fail-states for anything controlling physical equipment, means the system degrades gracefully instead of failing blind the moment the radio drops.
Treat connectivity as a security property
Availability belongs in the threat model alongside confidentiality and integrity. The usual hardening, firmware discipline, private APNs and VPNs, protects the data. Resilience against denial protects the mission. Both are security, and the RF layer has to be in scope for both.
The IoTPortal view
The monitoring playbook is not wrong. It is incomplete for anything that talks over the air. Its instinct, page on what the user actually experiences, is the right one, but the user of an IoT fleet experiences the silence as much as the bad reading, and the framework has no native way to see silence coming.
This lands on the same unglamorous foundations that decide every IoT outcome. Radio coverage, antenna quality, bearer diversity and honest RF telemetry are not the exciting part of a deployment, and they are exactly what keeps a fleet observable when the spectrum comes under pressure. As interference spreads from the map's edges into everyday airspace and everyday bands, the operators who fare best will be the ones who planned for the quiet: who alert on absence, diversify the path, and let the edge carry on when the network cannot. The most important question in industrial IoT is no longer only whether the data looks healthy. It is whether you will know, and keep running, when the thing goes quiet.
Frequently asked questions
What is the difference between jamming and interference?
Jamming is deliberate: a transmitter is used to overpower a wanted signal and deny the link. Interference is the broader term and includes accidental cases, such as spectrum congestion, co-channel clashes in shared bands, or faulty nearby equipment. Both produce the same practical result, a degraded or lost radio link, which is why a resilience plan needs to account for accidents as well as attacks.
Is cellular IoT safe from jamming because it uses licensed spectrum?
Safer, not immune. A licensed operator owns and monitors the spectrum and has legal recourse, which deters casual disruption. But the radio link itself remains physically deniable at close range, which is precisely why using a jammer is a criminal offence rather than simply discouraged. Licensing raises the barrier; it does not remove the exposure.
Why is LoRaWAN more exposed than cellular?
LoRaWAN runs in the unlicensed 868 MHz band in the UK and EU, shared with anything else entitled to use it, with no exclusivity and no operator watching the band for you. Peer-reviewed studies have shown it can be disrupted with inexpensive software-defined radios, and ordinary congestion degrades it without any malice. For mission-critical monitoring, that shared, contended nature is a design constraint to plan around.
Why do standard monitoring tools miss a jammed device?
Symptom-based alerting fires on evidence a struggling system emits: error rates, latency, failed requests. A jammed device emits nothing, so there is no symptom to page on. Its silence is also ambiguous, because a healthy low-power device is often silent by design. Distinguishing expected quiet from a real denial needs an explicit heartbeat and RF-layer telemetry, not just application metrics.
How do you build resilience against RF denial?
Design below the application. Alert on missed check-ins, not just bad data. Monitor signal quality and jamming flags from the modem as first-class metrics. Diversify the bearer with dual-modem and, where it matters, a satellite or NTN fallback rather than two SIMs on the same band. Make the edge autonomous with store-and-forward and safe local fail-states, and treat availability as part of the security threat model.
