75 Billion IoT Devices and Counting—But Who’s Watching Them?

A Look into IoT Management Challenges and How eBPF Could Help

Apr 14, 2025

While much of the recent attention has been on AI, MCP or LLMs—the Internet of Things (IoT) is another domain where demand is rapidly growing.

Just over the past five years, the number of IoT devices has increased by more than 145.53%, now reaching over 75 billion devices deployed worldwide.

Their use cases range from smart homes and cost-effective hardware replacements to industrial process monitoring and environmental sensing—such as tracking humidity in aquariums.

Despite this growth, many of these IoT devices continue to face challenges with long-term reliability, largely due to their susceptibility to cyberattacks.

There are several factors why IoT devices are often so vulnerable - just to name a few:

Not Secure by Design: Many IoT manufacturers prioritize low production costs over expensive security features. As a result, protections like data encryption at rest or secure boot are often omitted.
Lack of Regular Updates: Especially in large deployments, devices often run unpatched for long periods, leaving known vulnerabilities exposed.
Insecure Communication Channels: Some IoT devices transmit data without encryption or proper authentication, exposing sensitive information or allowing attackers to intercept and manipulate traffic.

Another common trait among IoT devices is that they typically have limited compute power, constrained battery life, and often operate in less-than-ideal environments—such as exposure to heat, rain, or physical interference.

For these reasons, it’s important to continuously observe and monitor how IoT devices operate.

This helps teams detect and troubleshoot issues early—whether it’s a system crash, a network slowdown, or a potential security risk—and enables them to answer questions like:

Where is data getting delayed or dropped?
How frequently do errors or anomalies occur?
Are the same issues happening repeatedly?
Which devices are most prone to connectivity issues?

So why choose eBPF over other observability tools? And why do we even need a different solution from what's already working in the cloud?

eBPF on IoT

Compared to cloud servers that can handle millions of packets per second (beside significantly more compute power), IoT sensor networks typically operate at just 100–1000 kbit/s.

And especially with such low data rates, it’s incredibly important to minimize time and CPU cycles spent on tasks like network and data processing, to avoid impacting network throughput or compute resources on devices that are already resource-constrained.

Just consider an Industrial IoT edge device, for instance, that processes sensor data for predictive maintenance, requiring computational time, while simultaneously needing to filter potentially malicious or malformed network traffic in real-time to ensure operational security and efficiency.

Or take a smart agriculture deployment, for example—battery-powered soil sensors send moisture data every few minutes and must conserve energy while validating commands to prevent hijacking. A single malicious packet could drain batteries or corrupt data, affecting crop yields and irrigation.

And it's not just about wasting resources on malicious or malformed traffic; it's also about how the deployed threat detection tool impacts the overall CPU and throughput of valid application traffic, like sensor data or user requests.

Take, for example, a threat detection tool that inspects network traffic and decides whether a packet — or, if you prefer, a user request — should be allowed or blocked.

While this sounds like a must-have, the reality is that many existing tools aren’t a good fit for IoT devices. They often consume too much CPU, degrading the device’s overall performance, or they reduce network throughput to the point where (valid) clients experience significant response delays.

This is where I see tremendous potential for eBPF.

Not only it runs directly in the kernel, offering significant performance advantages over many user-space tools, but also provides fine-grained, programmable control over traffic filtering and observability — all with minimal overhead, making it ideal for constrained devices.

To support these claims (at least to some extent—see note below), I wanted to perform a small experiment by monitoring TCP/UDP network connections and measuring their latencies using eBPF on a Raspberry Pi 4B+, as well as evaluating its side effects on the device itself.

⚠️ For a proper benchmark comparison, the ideal approach would be to fully re-implement an existing tool in eBPF — but still, here goes the results.

Experiment

For this experiment, I used a tool called flat to monitor the 5-tuple (source IP, destination IP, source port, destination port, and protocol) along with the associated connection latency.

I actually had to make a few tweaks to get it running on the Raspberry Pi, so check out my fork if you’re interested in trying it yourself.

The graph below illustrates the impact on throughput and CPU usage. The left side shows the maximum throughput over an isolated Ethernet connection (with no other network traffic), while the right side shows the throughput when network traffic is also captured and inspected by flat (eBPF programs) on the receiving end.

Measured using iperf3. Devices were directly connected (no hops)

The graph illustrates an average ~2.5% decrease in network throughput observed while running flat (i.e., the associated eBPF programs).

To take things further, I ran a simple Python HTTP server on the Raspberry Pi and generated 30 requests per second to it.

This resulted in only ~0.5% CPU usage attributed solely to the eBPF programs attached by flat (excluding the user-space HTTP server), with negligible impact on response latency.

💡 To be fair, there was a slight increase in response latency, but in this case the execution time of the eBPF programs was in the microsecond range — which is effectively the level of noise my measurements were susceptible to.

Now we could easily extend this setup to drop specific network packets, but the primary goal was to understand how much overhead this added functionality introduces in terms of network throughput and CPU usage.

One key benefit of this observability approach is also that it operates completely independently of your application. You can reconfigure or redeploy it without needing to restart the application or the device itself.

Note, that I'm not trying to say eBPF should completely replace your observability or security setup right away.

Instead, I like to think of it as an in-place feature replacement—one that enhances your current setup and replaces functionalities it can perform more efficiently than your existing threat inspection tool.

Potential Other Use Cases

One use case would be to rate-limit the number of network packets received on a specific destination port or per client source IP. You could even monitor packet retransmissions, which might indicate network failures or instability.

You could also track payload sizes and detect sudden application data spikes, blocking them before they cause device performance degradation.

Or monitor domain name resolutions—what domains are devices querying? Are they reaching out to known malicious domains?

Beyond network observability, eBPF can also support features like:

Performance optimization: Identifying bottlenecks in data transfer or processing to improve overall efficiency.
Energy consumption monitoring: Tracking power usage at a process level to optimize energy efficiency.
Compliance and auditing: Ensuring that data transmission complies with regulations and is logged for auditing purposes.
Anomaly detection: Identifying unusual traffic patterns that could indicate system malfunctions or security breaches.

I genuinely believe that once people start exploring what eBPF can do on IoT devices, they'll uncover a whole range of practical use cases, opening up new possibilities for performance, security, and observability that we haven't fully tapped into yet.

⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case: