9 best IoT operating systems for 2026

You can reprioritize a software feature next sprint. Changing the operating system underneath thousands of deployed devices is a different kind of decision entirely.

A connected device looks simple from the outside. Underneath, it has to read sensors, manage power, handle network interruptions, protect credentials, and recover from updates that fail halfway through. The IoT operating systems market reflects how seriously teams treat this choice: DataIntelo estimated it at $5.5 billion in 2025, with projections to nearly $16 billion by 2034.

The wrong OS choice can force a hardware redesign, add months to an update program, or make a fleet nearly impossible to support at scale. "Best" depends on device class, timing requirements, memory budget, connectivity stack, security controls, and the lifecycle your team can realistically staff.

So which operating system fits the device you are building?

What's inside

This guide is for product managers, embedded product managers, and engineering leads evaluating the foundation for a connected product. Items were selected based on:

• Current project activity and long-term maintenance posture
• Fit across device classes: Constrained sensor nodes, real-time controllers, gateways, and edge appliances
• Security model, OTA update architecture, and driver ecosystem
• Licensing terms and lifetime ownership cost

Pricing and G2 ratings are noted per tool. Most platforms here are open source, so the meaningful costs are board support, driver work, CI infrastructure, and support staffing.

TL;DR

• Best RTOS for broad MCU support: FreeRTOS, with verified support for more than 40 processor architectures
• Best for modular connected devices: Zephyr RTOS, with over 1,000 supported boards and security-focused kernel design
• Best for low-power mesh networking: RIOT or Contiki-NG, depending on whether your stack is IP-first or simulation-dependent
• Best for embedded routers and network appliances: OpenWrt, with full package management and writable filesystem
• Best for managed edge gateways: Ubuntu Core, with transactional OTA updates and fleet management
• Best for custom Linux image ownership: Yocto Project, when your team needs to control every layer of the distribution

What are IoT operating systems?

An IoT operating system is software that manages a device's hardware resources, scheduling, connectivity, memory use, and security services so application firmware can run predictably on constrained hardware.

Why IoT devices need specialized operating systems

IoT devices operate under constraints that desktop and server operating systems were never designed to meet. Memory budgets are often measured in kilobytes, not gigabytes. CPU cycles are limited, battery reserves must last months or years, connectivity is intermittent, and timing requirements may be hard real-time. A general-purpose OS carries overhead those devices cannot absorb.

Bare metal, RTOS, and embedded Linux are different choices

The first architectural decision is not which RTOS to pick. It is which category of software your device class actually needs.

Approach	Typical hardware	Strength	Product implication
Bare-metal firmware	Very constrained MCU	Minimal footprint	Highest engineering ownership, no OS abstractions
RTOS	MCU and real-time controller	Deterministic task scheduling	Good fit for sensors, control loops, connected appliances
Constrained-device IoT OS	Low-power networked node	Lightweight networking and energy focus	Good fit for mesh and standards-driven endpoint deployments
Embedded Linux	MPU, gateway, router, edge computer	Rich application environment	Good fit for local compute, containers, and fleet services

Core capabilities to evaluate

• Deterministic scheduling and task isolation
• Device drivers and board support package maturity
• Wireless, wired, and IP networking stack support
• Cryptography, secure boot, and identity management
• Power management and sleep behavior
• OTA update architecture and rollback
• Build tooling, debugging, and test automation
• Licensing terms and long-term maintainer activity

Note on terminology: MQTT and CoAP are application protocols. Wi-Fi, Bluetooth LE, Zigbee, Ethernet, and LoRaWAN are connectivity technologies. They all influence OS selection but are not operating systems themselves.

When to use an IoT operating system

Build a battery-powered endpoint

Sensor nodes, asset trackers, utility meters, and remote monitors need tight control over RAM, flash, sleep states, and radio stack behavior. Before shortlisting platforms, set explicit budgets for each resource. Power profiling on the target board is not optional; it is a product requirement. An OS that looks right on paper can drain a battery in days when the sleep-mode implementation does not match expectations.

Run time-sensitive control logic

Industrial controllers, medical device subsystems, building automation equipment, and motor control workflows require deterministic interrupt handling. A missed deadline in a control loop is not a UX problem. It is a product failure. Evaluate driver maturity, worst-case interrupt latency, and task preemption behavior on the actual hardware before committing.

Ship a gateway or edge appliance

Gateways, protocol translators, routers, and local analytics appliances operate on more capable hardware and need services that lightweight RTOSs cannot provide: Package management, storage, rich networking, container support, or local ML inference. Linux-based options fit when the product behaves more like a managed appliance than a simple endpoint.

IoT operating system comparison

This comparison separates lightweight RTOS platforms from Linux-based systems because the right choice starts with hardware class and runtime requirements. All nine platforms are open source or free to use; the cost differences appear in board support, engineering, CI, and long-term maintenance.

#	Product	Best for	Key differentiator	Pricing	G2 rating
1	FreeRTOS	Real-time MCU products	Small kernel with 40+ architecture support	Free, MIT license	4.1/5
2	Zephyr RTOS	Modular connected embedded devices	1,000+ boards, security-focused kernel	Free, Apache 2.0	N/A
3	RIOT	Low-power networked endpoints	Tiny footprint, multithreading, full IP stack	Free, open source	5.0/5
4	Contiki-NG	IPv6 and low-power mesh deployments	Low-power IPv6, RPL, CoAP, Cooja simulation	Free, BSD 3-Clause	N/A
5	TinyOS	Research-oriented sensor networks	Event-driven architecture, highly constrained devices	Free, open source	N/A
6	Apache NuttX	POSIX-oriented MCU projects	RTOS with POSIX-style interfaces	Free, Apache 2.0	N/A
7	OpenWrt	Routers and network appliances	Embedded Linux with writable filesystem and package management	Free, GPLv2	N/A
8	Ubuntu Core	Managed edge gateways and appliances	Transactional OTA updates, fleet management via Landscape	Free to evaluate; services from $25,000	4.5/5
9	Yocto Project	Custom embedded Linux distributions	Build framework for tailored Linux images	Free, open source	N/A

Licensing and project details verified from official project documentation, October 2026. G2 ratings reflect live listings where verified; N/A indicates no confirmed listing for this embedded project.

Best IoT operating systems for 2026

Rankings reflect device fit, ecosystem maturity, current project activity, networking capability, security model, and lifetime maintenance implications.

1. FreeRTOS

FreeRTOS is a real-time operating system kernel for microcontrollers and small microprocessors. It provides deterministic task scheduling, inter-task communication primitives, and optional libraries for networking and security. The kernel is not a full Linux-like environment; it is a focused RTOS with a well-understood footprint that teams can extend with purpose-selected components.

Best for: Product teams building real-time firmware on microcontrollers where silicon-vendor SDK support and portability across MCU families are priorities.

Key features

• Preemptive and cooperative task scheduling
• Tasks, queues, semaphores, and software timers
• TCP/IP stack with IPv6 support
• Support for 40-plus processor architectures and 15-plus toolchains
• Long-term support releases with security updates for two years

Why choose FreeRTOS: It is the default starting point for many MCU-based products because the ecosystem is broad, silicon vendors maintain ports, and the MIT license creates no downstream obligation. Validate vendor SDK support and whether required networking, security, and OTA components fit your shipping architecture before committing.

FreeRTOS pricing: The kernel and libraries are free under the MIT open-source license. Commercial licensing and support options exist through ecosystem partners.

G2 rating: 4.1/5 (listed as Amazon FreeRTOS on G2).

2. Zephyr RTOS

Zephyr RTOS is a configurable, small-footprint operating system for connected and resource-constrained devices. It covers a broad architecture set, including ARC, ARM, RISC-V, and x86, with a structured build system, device tree hardware descriptions, and a security-focused kernel. The project documents support for more than 1,000 boards and shields and publishes long-term support releases.

Best for: Product teams shipping connected devices across multiple board variants, chip families, or future hardware revisions where portability is a strategic requirement.

Key features

• Configurable small-footprint kernel with Kconfig system
• Device tree hardware abstraction
• Thread isolation and memory protection
• Bluetooth 5.3 and Bluetooth LE support
• POSIX API subset for application portability

Why choose Zephyr RTOS: Choose it when the hardware roadmap is uncertain or spans multiple chip vendors. The large supported-board catalog reduces porting risk as the product evolves. Run a proof of concept on the exact radio, sensor, and power-management combination before treating a broad board list as a guarantee.

Zephyr RTOS pricing: Free under the Apache 2.0 license. Commercial implementation support is available through ecosystem partners.

G2 rating: N/A. No verified G2 listing for Zephyr RTOS was confirmed at time of publication.

3. RIOT

RIOT is a free, open-source operating system designed for low-power IoT and embedded devices. Its kernel footprint runs on the order of a few kilobytes, and it supports 8-bit, 16-bit, and 32-bit microcontroller platforms. The networking stack covers IPv6, 6LoWPAN, RPL, TCP, UDP, QUIC, MQTT-SN, CoAP, and CBOR, giving teams a full IP stack without sacrificing the tight resource budget that endpoint devices demand.

Best for: Teams building low-power connected endpoints that need multithreading, inter-process communication, and a comprehensive networking stack with C or C++ development.

Key features

• Low-footprint, energy-efficient, real-time-capable kernel
• Multithreading with mutexes, semaphores, and IPC
• IPv6, 6LoWPAN, RPL, CoAP, MQTT-SN, and QUIC networking
• 8-bit, 16-bit, and 32-bit MCU platform support
• Crypto libraries and shell tools

Why choose RIOT: It suits teams that need low-power networking but want familiar threading abstractions rather than an event-driven model. Validate the target radio stack and board port early; for a connected-device roadmap, networking support is a product dependency with real release-cadence implications.

RIOT pricing: Free and open source. Confirm current license details on the project repository before publishing.

G2 rating: 5.0/5 (based on a single verified review).

4. Contiki-NG

Contiki-NG is an open-source operating system for resource-constrained IoT devices, designed around low-power IPv6 networking and standards-based protocol support. Its code footprint runs around 100 kB, with memory configurations as low as 10 kB. The platform includes the Cooja simulation environment, which lets teams test network behavior before field deployment. Protocol support covers RPL, CoAP, LwM2M, TSCH, and 6TiSCH.

Best for: Product and research teams developing low-power mesh devices that rely on IPv6, standards-based networking, and repeatable simulation workflows before hardware pilots.

Key features

• Low-power IPv6 networking stack
• RPL, CoAP, LwM2M, TSCH, and 6TiSCH support
• Cooja simulation environment for network testing
• Multiple hardware platform ports
• Configurable memory use down to approximately 10 kB

Why choose Contiki-NG: It is strongest when the product depends on standards-based mesh networking and the team needs to validate network behavior before committing to field hardware. Ask whether the product needs a border router and repeatable simulation before adding it to your shortlist.

Contiki-NG pricing: Free under the BSD 3-Clause license.

G2 rating: N/A. No verified G2 listing was confirmed.

5. TinyOS

TinyOS is an open-source, event-driven operating system with deep roots in wireless sensor-network research. It uses a component-based application model written in nesC, a C dialect designed for the event-driven concurrency model TinyOS enforces. The platform targets highly constrained sensor hardware and carries a low resource overhead suited to battery-powered, single-purpose devices.

Best for: Research programs, academic teams, and specialized sensor-network products with established TinyOS expertise and existing codebase investment.

Key features

• Event-driven concurrency model
• Component-based application design in nesC
• Low resource overhead for constrained sensor platforms
• Wireless sensor network focus
• Active open-source community in academic research contexts

Why choose TinyOS: It fits teams with a sensor-network research background or a legacy codebase that already runs on TinyOS. For new commercial products, make available engineering expertise a hard requirement on the shortlist. A tight memory footprint does not offset the hiring and maintenance cost of a niche stack.

TinyOS pricing: Free and open source. Verify current project maintenance status and board compatibility before finalizing.

6. Apache NuttX

Apache NuttX is a standards-compliant real-time operating system that scales from 8-bit to 64-bit microcontrollers. It targets teams that value POSIX and ANSI API conformance, offering preemptive scheduling with FIFO and round-robin support, a configurable filesystem, device-driver framework, and BSD-compatible networking with IPv4, IPv6, TCP/IP, UDP, and DNS.

Best for: MCU-based products that need hard real-time behavior while keeping the application code close to familiar POSIX-oriented development practices.

Key features

• POSIX and ANSI standards compliance
• Preemptive real-time scheduling with FIFO and round-robin modes
• Configurable filesystem and device-driver subsystems
• IPv4, IPv6, TCP/IP, UDP, and DNS networking
• 8-bit to 64-bit microcontroller architecture support

Why choose Apache NuttX: Consider it when reducing friction between embedded code and POSIX-oriented development practices matters to the team. POSIX familiarity has real value only when it lowers implementation risk on the target hardware. Validate exact modules, driver maturity, and toolchain compatibility before the architecture sign-off meeting.

Apache NuttX pricing: Free under the Apache 2.0 license.

7. OpenWrt

OpenWrt is not an RTOS. It is a highly extensible GNU/Linux distribution for embedded devices, primarily wireless routers and network appliances. It provides a writable filesystem, a full package management system, and a web interface through LuCI. The platform supports routing, firewalling, QoS, VLANs, VLAN bridging, VPNs including OpenVPN and WireGuard, and bandwidth monitoring.

Best for: Connected products that are fundamentally network appliances: Gateways, routers, protocol translators, or local connectivity hubs.

Key features

• Embedded Linux distribution with writable filesystem
• Package management for extending functionality post-flash
• LuCI web interface and CLI configuration
• VPN support: OpenVPN and WireGuard
• VLAN tagging, bridging, and trunking

Why choose OpenWrt: Use it when network services, routing, firewalling, and package customization are central to the product definition. It is a categorically different choice from a microcontroller RTOS. Define who owns security updates and package maintenance after launch before committing; that is a staffing question, not a technical one.

OpenWrt pricing: The software is free under GPLv2. Hardware vendors typically incur engineering cost for custom image builds, package maintenance, and security response.

8. Ubuntu Core

Ubuntu Core is a minimal, strictly confined, and immutable embedded Linux operating system from Canonical, built for IoT, edge devices, and embedded systems. It uses a transactional update model with rollback protection, supports secure boot and full-disk encryption, and manages fleet devices through Landscape. It targets hardware with enough compute and storage for Linux workloads, including ARM and Intel platforms.

Best for: Product teams shipping gateways, industrial edge devices, kiosks, or appliances where managed software delivery, update reliability, and a long device lifetime are product requirements.

Key features

• Strict confinement and immutable OS architecture
• Secure boot and full-disk encryption
• Transactional OTA updates with rollback protection
• Fleet and device management through Landscape
• Real-time kernel support option

Why choose Ubuntu Core: It fits product lines where devices behave more like managed appliances than simple endpoints. The update and rollback experience should be a product requirement from day one. Test interrupted updates, offline recovery, and release promotion before architecture commitment.

Ubuntu Core pricing: The software is free to evaluate. Canonical's device services start at $25,000 for SmartStart, with additional options for snap creation, store services, deployment, and consulting at separate rates. Contact Canonical directly for fleet-scale commitments.

G2 rating: 4.5/5 (listed as Ubuntu on G2; confirm applicability to Core specifically).

9. Yocto Project

Yocto Project is not a ready-to-flash operating system. It is an open-source build framework for creating custom Linux-based images for embedded products. It uses BitBake and OpenEmbedded-Core as its build system, with a layer-based architecture that lets teams control package selection, board support, and reproducible build pipelines. It also includes an extensible SDK and automated support for license compliance, security analysis, and software bill of materials generation.

Best for: Teams that need to own a tailored Linux image, package selection, board support layer, and reproducible build pipeline for a product with specific component or certification requirements.

Key features

• Custom Linux image generation for embedded systems
• Layer-based build configuration and reuse
• BitBake and OpenEmbedded-Core build system
• Board Support Package integration and multi-architecture support
• Automated license compliance, SBOM, and reproducible build support

Why choose Yocto Project: Choose it when the product requires a controlled distribution rather than a general-purpose image, and when the organization can support build infrastructure across the product's lifetime. Yocto delivers precise control; that control comes with ongoing operational responsibility for every release cycle.

Yocto Project pricing: The build framework is free and open source. Organizational membership fees range from free (Associate, for eligible nonprofits and academic institutions) to $5,000 to $20,000 annually (Silver, scaled by employee count) and up to $100,000 annually (Platinum). The main engineering cost is CI infrastructure, board integration, and long-term image maintenance.

Considerations when choosing IoT operating systems

Start with hardware constraints

Set a concrete target hardware matrix before any platform conversation. Define minimum and peak RAM, flash budget, CPU architecture, radio chipset, battery profile, and available debugging interfaces. A platform decision made before those numbers exist is a guess dressed as an architecture choice. Make the firmware team provide the matrix, not an estimate.

Match the timing model to the product workflow

Separate hard real-time, soft real-time, and general edge-compute requirements before shortlisting. A gateway running local analytics has different scheduling needs than a sensor that must wake, sample, transmit, and return to deep sleep within a precise window. The device class drives the OS category, and the OS category narrows the shortlist faster than any feature comparison.

Validate connectivity before feature work

Check the full stack your product needs: Specific radios, IP protocols, application-layer protocols, and transport security. The OS must support the required combination on the chosen hardware, not just in theory, but with working drivers and tested board ports. Networking support is a product dependency with its own release-cadence implications.

Treat security and OTA updates as release requirements

Secure boot, key storage, signed firmware, encrypted communication, and OTA rollback are not features to add later. Evaluate each platform's update architecture, CVE response history, and rollback behavior before the hardware is locked. An update that fails halfway through in the field is a support crisis, not a firmware bug.

Price the lifetime cost, not the license

All nine platforms on this list are open source or free to use. The meaningful cost is board support work, custom drivers, CI infrastructure, test hardware procurement, security patching cadence, and the engineering headcount to sustain it across the product's lifetime. Size that investment before comparing platforms on features.

How to choose the right IoT operating system for your team

If you are building a constrained sensor or actuator, start with FreeRTOS or Zephyr RTOS for the broadest ecosystem coverage. Let RAM budget, required radio stack, deadline sensitivity, and silicon-vendor SDK support decide the final shortlist. Apache NuttX is worth evaluating when POSIX compatibility reduces implementation risk on your target hardware.

If you are building a low-power mesh network, prioritize Contiki-NG or RIOT. Contiki-NG is stronger when standards-based IPv6 networking, protocol simulation, and field-network validation are central to the product risk. RIOT suits teams that want threading abstractions alongside a comprehensive IP stack and prefer C or C++ development without a specialized language requirement.

If you are shipping a router, gateway, or local edge appliance, evaluate OpenWrt, Ubuntu Core, and Yocto Project. OpenWrt fits products where network services and package extensibility define the product. Ubuntu Core fits when managed update delivery and fleet observability are product requirements. Yocto Project fits when the team needs complete image-level control and can staff a reproducible build pipeline across the product's lifetime.

If your hardware is still changing, Zephyr RTOS's large supported-board catalog and documented porting workflow make it a strong early evaluation. Portability is a strategic hedge when the chip vendor or board design is not yet locked. Run a 30-day proof of concept on the candidate board: Build on target, validate required drivers and connectivity, measure RAM and flash usage, test secure update and rollback, and complete a supportability review before roadmap commitment.

Conclusion

No single IoT operating system fits every device class. The decision starts with the hardware, not the feature list.

FreeRTOS and Zephyr RTOS are the most common starting points for real-time MCU products, with FreeRTOS offering the broadest silicon-vendor coverage and Zephyr offering the largest board catalog and a more structured build system. RIOT and Contiki-NG serve low-power, networking-heavy endpoint deployments, with Contiki-NG adding simulation capability that matters when field-network behavior is a product risk. OpenWrt, Ubuntu Core, and Yocto Project address gateway and Linux-class device needs, each with a different posture toward network extensibility, managed updates, and build-level control.

Validate the shortlist against real hardware, connectivity requirements, update workflow, security model, and team capacity before any roadmap commitment. A focused proof of concept on the target board is the most reliable signal available.

When you are ready to show stakeholders, customers, or partners how a connected product actually works, Guideflow helps technical product teams create interactive product education that communicates device experience without requiring a live environment.

Start your journey with Guideflow today!

FAQs