By the end of 2025 there were roughly 21 billion connected IoT devices in the world, with more than 39 billion projected by 2030. But the size of the market is no longer the interesting metric. A far more useful question is: what does this scale actually demand from the people designing and deploying connected systems?

For most of the last decade, the dominant pattern was collect-and-send: gather data on the device → ship it to the cloud → analyze → send a command back down. It made sense while cloud compute was cheap and volumes were manageable. In 2026, both conditions have changed. On-device compute has become cheap enough to run ML models on microcontrollers that cost a few dollars. And the data volumes from industrial, healthcare, and logistics deployments have grown to a point where routing everything through a central server first introduces latency that is operationally unacceptable.

Hence a structural shift: intelligence is moving to the device, and the cloud is being repositioned from decision-maker to coordinator. That single change is the thread running through nearly all of the IoT trends worth paying attention to in 2026 — so let's walk through where it leads.

1. AIoT: the model now lives on the device

Picture a pump bearing that starts failing at 2 a.m. on a Saturday. In the old architecture, the sensor ships data to the cloud, the cloud runs a model, spots the anomaly, and sends an alert back. Under congested or unreliable connectivity, that round-trip can stretch just long enough to turn a planned maintenance window into an unplanned production halt.

In an AIoT architecture, the model runs directly on the controller or on the sensor node itself. Inference happens in milliseconds, locally, without touching the network. The device triggers a shutdown or an alert on its own. The cloud's role shifts: it collects logs across the entire fleet, retrains the model on aggregate patterns, and periodically pushes updated weights back down.

The key enabler at the "micro" end of the spectrum is TinyML: ML models running on devices with 256 KB of RAM. Classifying a vibration pattern, flagging a sensor anomaly, running computer vision on a production-line camera — all without a single frame leaving the device.

What this means for engineers: the entire weight of the shift lands on firmware. An embedded system that now has to carry model artifacts, handle OTA model updates, and run inference within its power budget is considerably more complex than one that just collects and transmits. And it has to be written in a way that doesn't introduce memory vulnerabilities — which is exactly why the Rust conversation is inseparable from the AIoT one (see trend #4).

2. Digital Twins: from monitoring to simulation

For a few years, "digital twin" was a showcase technology — a slick 3D model rotating slowly on a screen, updated in real time from sensor feeds. Impressive, but not particularly actionable for most organizations.

In 2026 the interesting part isn't in the visualization layer at all. The asset twin (a virtual representation of a single machine) is now well established. The new movement is toward what Gartner calls a Digital Twin of an Organization (DTO): a dynamic model of how an entire business process executes, not just how one machine performs.

The difference is significant. Knowing that a specific press is running 3% below spec is useful. Understanding what that slowdown means for order fulfillment by the end of the week, and which downstream processes it affects — before anyone physically inspects the equipment — is an entirely different category of capability.

The core value of a twin in 2026 is simulation, not monitoring: analyzing data from the physical system before you commit to changing anything in it. And it rests on the convergence of three things: real-time sensor data, edge AI (so the twin reflects machine state in near real time), and a cloud simulation layer. Remove any one and the value of the others degrades.

3. EU Cyber Resilience Act: regulation that's already shaping procurement

For years, IoT security was left to the market. In Europe, that's no longer the case.

The CRA entered into force on December 10, 2024, and its effects on procurement are already visible. The intermediate deadlines are creating commercial consequences right now:

Compliance requires a minimum 5-year vulnerability support period, 10-year security update availability, an end-of-support date specified in month and year at point of sale, mandatory risk assessment, and vulnerability disclosure. Penalties reach up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

In practice, European buyers are already requiring CRA compliance documentation as a qualification criterion. A vendor who can't produce a documented 10-year update commitment simply doesn't make it into the bid — no matter how technically strong the product is.

4. Firmware-level security and the rise of Rust

This is the most technical trend on the list — and the most relevant one for developers.

Roughly 70% of high-severity vulnerabilities in C/C++ software are memory safety errors: buffer overflows, use-after-free bugs, null pointer dereferences. Chromium's security team documented the figure from its own codebase, and both CISA and NSA cite it in formal advisories recommending memory-safe languages.

This matters for IoT because embedded systems — sensors, controllers, edge nodes, gateways — are overwhelmingly written in C or C++. The firmware on an industrial controller. The code on a medical wearable tracking cardiac arrhythmia. The software on an ADAS module making steering decisions. Which means ~70% of the critical vulnerabilities in those systems are, in principle, preventable with a language change.

Rust is what made that argument practical rather than theoretical. Performance competitive with C, but a compiler that rejects code which would produce a buffer overflow or a use-after-free. No garbage collector, no runtime overhead — just a compiler enforcing the safety constraints a C programmer has to enforce by hand (and frequently doesn't).

By 2026, Rust is in production in safety-critical domains: mobile robotics, medical devices, and ADAS firmware at OEMs and Tier 1 suppliers.

The pragmatic take for teams: migrating large existing C codebases is a genuine engineering investment, and the CRA doesn't mandate a specific language (it mandates documented security outcomes). But for new firmware projects, especially in regulated domains, starting in Rust rather than C is increasingly the default among teams that have done the analysis.

5. 5G and Connectivity 2.0: no single technology fits all

Choosing connectivity for each device category is one of the most consequential architecture decisions you'll make. And in 2026 there is no single right answer. Mature deployments run several technologies in parallel, matching each to its requirements (latency, power, coverage, data volume):

• Private 5G — for high-density factory environments. The IMT-2020 standard specifies up to one million devices per km² and latencies as low as 1 ms. Critical when coordinating AGVs, safety interlocks, and QC cameras within a single facility.

• 5G RedCap (3GPP Release 17) — the underappreciated middle of the market. For devices that need more than NB-IoT but can't afford a full 5G modem's power draw: industrial wearables, asset trackers, environmental monitors.

• LPWAN (LoRaWAN, NB-IoT) — still the default for massive IoT. NB-IoT + LTE-M have already passed 1 billion connections, with field-proven battery life of 10–15 years. That's why cold-chain sensors, smart meters, and agricultural monitors are built on LPWAN rather than cellular.

• Satellite IoT — from novelty to practical option. Deutsche Telekom launched a multi-orbit IoT roaming service (terrestrial NB-IoT + GEO/LEO backhaul). For a container ship crossing the Pacific or a mining asset 200 km from the nearest tower, dead zones are no longer an acceptable given.

RedCap doesn't replace LPWAN — it fills the gap between low-power WAN and full 5G. If a device sends small amounts of data infrequently, LPWAN still almost always wins on cost and battery life.

6. Green IoT and energy harvesting

IoT-enabled building management systems have demonstrated energy consumption reductions of up to 30% (more conservative estimates put it at 10–20%). In agriculture, precision irrigation with real-time soil-moisture sensors cuts water use by 40–50% compared to fixed-schedule irrigation.

The architecturally interesting piece is energy harvesting: powering a sensor from ambient light, vibration, RF signals, or thermal differentials — no battery, no wired power. This fundamentally changes the economics of dense sensor deployment. Logistics pallets, ATEX-rated hazardous-zone sensors, field agricultural monitors, structural-health-monitoring nodes — all can run for years without maintenance.

The historical bottleneck for large-scale deployments has been the cost of replacing batteries across thousands of geographically distributed devices. Energy harvesting removes that constraint entirely.

Pro tip: match the harvesting method to the deployment environment from day one. Vibration harvesting on rotating equipment, solar on outdoor or well-lit assets, RF near high-power transmitters. It's the design decision most often left too late in a project.

7. Zero Trust for OT/IoT environments

If the CRA defines what a manufacturer commits to over a product's lifetime, Zero Trust defines how networks should be architected once those devices are deployed.

The practical mechanism is microsegmentation. The logic is containment: if a device is compromised, it should have no path to systems outside its segment. A compromised smart sensor in a building-management system shouldn't be able to reach the ERP. A breached network camera in a logistics facility shouldn't reach industrial controllers on the same site. These aren't hypothetical chains — real-world incidents document low-value IoT devices becoming entry points into high-value systems.

Implementing Zero Trust in a brownfield OT environment is much harder than in a greenfield one. Legacy devices often can't support modern authentication, so the segmentation has to compensate for what the device itself can't enforce. Plan for this early: retrofitting network architecture around device limitations is a major source of scope creep in OT security.

For industrial buyers with IEC 62443 requirements, segmentation is shifting from an "advanced hardening" option to a baseline procurement expectation.

8. AI-powered threat detection

AI is changing the attacker side too. Threat-intel teams forecast that in 2026 AI will accelerate the attacker-defender dynamic, compressing the window between vulnerability discovery and exploitation. Reconnaissance, vulnerability scanning, and initial payload development are becoming partially automated. Defenders running on periodic review cycles rather than continuous monitoring are increasingly exposed.

For IoT, AI-powered detection solves a scale problem that has no human solution. No security team can establish behavioral baselines for 50,000 devices and monitor for meaningful deviations in real time. Anomaly-detection systems that model normal device behavior and flag deviations automatically are the practical answer. Automated response playbooks that isolate a compromised device faster than an analyst can open the alert are becoming standard components.

Pro tip: prioritize behavioral baselining per device category over generic network-level anomaly detection. A smart meter and a SCADA controller have entirely different normal traffic patterns. A platform that baselines them identically will drown in false positives.

What the trends add up to

Every one of these trends points to the same underlying tension: IoT technology has matured faster than the security and governance layer built around it. Devices are cheaper, smarter, and more connected than they were five years ago. The infrastructure for scale — connectivity, edge compute, digital-twin platforms — has crossed from experimental to commercial. What hasn't kept pace, until regulatory pressure forced the issue, is the security lifecycle management and architectural discipline required to run billions of connected devices where a compromise has real consequences.

If you're making IoT decisions in 2026, three questions deserve the most attention:

1. What is your update-lifecycle commitment for every device category you ship?

2. Where does each device category sit in your network segmentation architecture?

3. What is your firmware development practice for the next generation of on-device AI?

These are harder questions than connectivity selection or platform evaluation. But they're the ones whose answers will determine both regulatory compliance and operational resilience over the next five years.

If you work with embedded, edge AI, or firmware security, I'd love to hear in the comments which trend has already hit your projects.