6 IoT Trends for 2026, Translated From Business-Speak Into Developer

Andrew Davies — Thu, 10 Sep 2026 02:27:02 +0000

Every January-through-April, the IoT trend reports drop — and they're all written for VPs. Market sizing, procurement gates, "strategic imperatives." Useful if you sign budgets; less useful if you write firmware.

So here's the developer's cut: the trends that will actually change what you build, debug, and get paged about, with the boardroom layer stripped out.

One number for context, because it drives everything below: about 21 billion IoT devices are online today, heading past 39 billion by 2030. The architecture that got us here — collect data on the device, ship it to the cloud, think there, send instructions back — is the thing quietly dying. Almost every trend on this list is a symptom of that death.

Inference is moving onto the device — and firmware just got harder

The collect-and-send pattern made sense when cloud compute was cheap and data volumes were small. Neither is true anymore. Meanwhile, MCU-class hardware got good enough to run task-specific ML models locally: TinyML frameworks now classify vibration patterns, flag sensor anomalies, and run basic vision on devices with 256 KB of RAM, no network round-trip involved.

The architectural consequence: the cloud is being demoted from decision-maker to coordinator. It aggregates fleet data, retrains models, and pushes updated weights down. The device decides.

What this means for you, concretely: firmware that used to be "read sensor, transmit, sleep" now has to carry model artifacts, handle over-the-air model updates (not just firmware updates), and run inference inside a power budget. That's a genuinely harder embedded program — more state, more failure modes, more attack surface. Which leads directly to the next two trends.

Rust in firmware stops being a curiosity

The stat that keeps showing up in government advisories: roughly 70% of high-severity vulnerabilities in C and C++ codebases are memory-safety bugs — buffer overflows, use-after-free, the classics. CISA and the NSA both cite it, and both now formally recommend memory-safe languages. Chromium's team documented the same ratio in their own code.

IoT firmware is overwhelmingly C/C++. Do the math: most critical vulnerabilities in the devices around you are, in principle, preventable with a language change.

Rust is where the industry landed because it's the only option that removes that bug class at compile time with zero runtime cost — no GC, no VM — which is what makes it viable on the same 256 KB microcontroller running your TinyML model. Certified toolchains (Ferrocene, qualified for automotive and medical standards) killed the "can't use it in regulated builds" objection, and automotive suppliers are already shipping Rust in ADAS firmware.

Nobody sane is rewriting a million lines of working C. The actual pattern: new firmware projects in regulated domains start in Rust by default, and existing codebases swap in Rust for the security-critical modules (comm stacks, credential handling, OTA verification) over FFI. If you write embedded code and haven't touched Rust yet, 2026 is the year that gap starts showing up in job requirements.

The EU Cyber Resilience Act is about to land in your backlog

Regulation sounds like someone else's problem until it materializes as tickets. The CRA — in force since December 2024 — is exactly that kind of regulation. The deadlines are close: conformity-assessment provisions kick in June 2026, vulnerability-reporting obligations in September 2026, full compliance by December 2027. Penalties go up to €15M or 2.5% of global turnover.

Translated into engineering work, "compliance" means somebody — plausibly you — builds:

a signed, verified, rollback-capable OTA pipeline that has to keep working for 10 years of security updates
an SBOM generated from your actual build, not a spreadsheet someone maintains by hand
a vulnerability intake and disclosure process wired into the dev workflow
security requirements documented as design inputs, with evidence, not added at the end

The full analysis of how these obligations reshape IoT architecture decisions is in the original trends breakdown this post is condensed from — the short version is that European buyers already treat CRA documentation as a qualification gate, so this work is coming to a sprint near you regardless of how anyone feels about it.

Connectivity is a portfolio now, not a picklist

"Which protocol should my device use" increasingly has the same answer as "which database should my app use": depends, and probably more than one. Mature 2026 deployments run several in parallel:

LPWAN (LoRaWAN, NB-IoT) is still the default for anything sending small payloads infrequently — field-proven 10–15 year battery life is why smart meters and cold-chain sensors live here. NB-IoT/LTE-M crossed a billion connections.
5G RedCap is the underrated middle tier: more capable than NB-IoT, way less power-hungry than a full 5G modem. Watch for it in asset trackers and industrial wearables the way NB-IoT showed up a few years back.
Private 5G is for the factory floor — sub-10ms latency and extreme device density for AGVs and robotics. Overkill for everything else.
Satellite IoT went from novelty to product: multi-orbit roaming (terrestrial NB-IoT + LEO/GEO backhaul) is commercially available, so "the container is crossing the Pacific" is no longer an excuse for a two-week data gap.

The developer takeaway: design the data layer protocol-agnostic from day one. Devices that assume one transport get expensive to evolve.

Zero trust reaches all the way down to your device

The attack chain that keeps repeating in incident reports: cheap IoT device gets popped, attacker moves laterally to the systems that actually matter. The network camera reaches the industrial controllers; the smart sensor reaches the ERP.

The response — microsegmentation — is becoming a baseline procurement requirement in industrial settings (IEC 62443 shows up in RFPs constantly now). For device developers this changes an assumption: your device will live in a network that treats it as already-compromised. Design accordingly — mutual auth on every connection, no implicit trust in "internal" traffic, and the humility to accept that your device is the threat model.

Batteries become optional

The fun one. Energy harvesting — powering sensors from ambient light, vibration, RF, or thermal differentials — has matured to where dense sensor deployments can skip batteries entirely. The engineering constraint that killed large sensor fleets was never the hardware cost; it was sending humans to swap batteries across ten thousand distributed devices. Harvesting deletes that constraint.

The design catch: the harvesting method has to match the environment from day one — vibration harvesting on rotating equipment, solar on outdoor assets, RF near strong transmitters. It's a firmware problem too: your power budget stops being a fixed number and becomes a function of the environment, which makes the duty-cycle logic some of the most interesting embedded code you'll write.

The thread through all of it

Notice what these six have in common: the center of gravity moved to the firmware. On-device inference makes firmware smarter, Rust makes it safer, the CRA makes it a regulated artifact with a decade-long support obligation, and zero trust assumes it's hostile. The cloud-first decade trained a lot of us to treat the device as a dumb peripheral. That framing is now officially obsolete.

If you're building in this space: which of these has actually hit your roadmap already? My bet is CRA prep is quietly eating more sprint capacity than the AI stuff everyone talks about — curious if the comments prove me wrong.

DEV Community: Andrew Davies

6 IoT Trends for 2026, Translated From Business-Speak Into Developer