FreeRTOS has been the default RTOS for microcontroller-based IoT devices for the better part of a decade. It’s lightweight, it runs on everything, and it’s well understood. But Zephyr — the Linux Foundation’s embedded operating system — has been quietly eating into that dominance. Not by accident, and not just in hobbyist projects.

In 2026, Zephyr has more commercial deployments than it had two years ago, better tooling, broader hardware support, and a contributor base that includes Intel, Nordic Semiconductor, NXP, Qualcomm, and others who are actively invested in it. If you’re choosing an RTOS for a new embedded IoT project, you should be evaluating it seriously.

Here’s an honest comparison.

What Zephyr actually is

Zephyr RTOS is a scalable real-time operating system designed for resource-constrained devices, from tiny microcontrollers with 4KB of RAM to more capable edge hardware running application processors. It supports over 500 development boards out of the box, has a first-class Bluetooth LE stack, and ships with a native networking stack that includes IPv4, IPv6, TCP/UDP, MQTT, CoAP, and more.

The key distinction from FreeRTOS is architectural scope. FreeRTOS is a minimal kernel — it gives you task scheduling, synchronisation primitives, and not much else. For everything beyond that (networking, Bluetooth, file systems, device drivers), you integrate separate libraries or vendor-provided middleware. Zephyr is a more complete platform: the networking stack, Bluetooth, filesystem, device driver framework, and security features are all part of the same project, built to work together.

That integration is both its strength and the reason for its higher resource requirements.

Zephyr vs FreeRTOS: where each wins

Zephyr’s advantages:

Integrated everything. If your device needs Bluetooth LE, MQTT over Wi-Fi, a file system, and OTA firmware updates, Zephyr’s approach of providing all of these as first-class components in a single, coherent platform means less integration work and fewer version compatibility headaches. With FreeRTOS, you’re stitching together components from different sources, which works but requires more maintenance.

Security posture. Zephyr has invested significantly in security features: hardware-backed memory protection (MPU/MMU), kernel-level isolation, a native Mbed TLS integration, and a security advisory process. The security architecture is documented and auditable. For devices that need to pass certification or handle sensitive data, Zephyr’s security model is more complete than vanilla FreeRTOS.

Devicetree and Kconfig. Zephyr uses the Linux-derived devicetree model for hardware configuration and Kconfig for build configuration. Both have a learning curve, but they’re established, well-documented systems that separate hardware description from application code. Porting an application to a different board is often a matter of selecting a different board target and adjusting the overlay file, rather than modifying application code.

West build system. Zephyr’s west meta-tool handles project initialisation, dependency management, building, and flashing. It’s opinionated and takes getting used to, but it solves real problems: dependency management for Zephyr projects is handled consistently, and the module system makes it practical to maintain a shared codebase across multiple products that differ only in their devicetree configuration.

FreeRTOS’s advantages:

Resource efficiency. FreeRTOS has a dramatically smaller memory footprint. A minimal FreeRTOS application can run in under 8KB of RAM. Zephyr’s minimum is higher — typically 20-32KB depending on which features are enabled. On the very smallest microcontrollers (Cortex-M0+, 8-bit AVR/PIC), FreeRTOS is often the only practical option.

Simplicity and familiarity. FreeRTOS’s API surface is small and learnable in a day or two. Tasks, queues, semaphores, timers — it’s a clean, minimal interface. Zephyr’s API is larger, and the devicetree/Kconfig build system has a real learning curve. For teams that don’t need the broader platform features, that complexity isn’t buying them much.

Vendor support and legacy code. FreeRTOS ships as the default RTOS in many vendor SDKs — Espressif’s ESP-IDF, ST’s STM32Cube, and others use it as the bundled RTOS. If your hardware vendor’s SDK is built around FreeRTOS, fighting against that is almost never worth it. Similarly, existing codebases on FreeRTOS have no reason to migrate just because Zephyr exists.

Where Zephyr has been gaining ground

Nordic Semiconductor is the clearest case. The nRF Connect SDK — Nordic’s development platform for nRF5x and nRF91x chips — is built on Zephyr. If you’re doing Bluetooth LE, Thread, Zigbee, or LTE-M/NB-IoT development on Nordic hardware (which covers a large chunk of IoT devices), you’re using Zephyr whether you’ve made a deliberate choice about RTOS or not.

This matters for the ecosystem. Zephyr’s Bluetooth stack is widely regarded as among the best available for embedded systems — it’s full-featured, well-maintained, and the Nordic community around it is active. If Bluetooth LE is central to your product, Zephyr is hard to beat.

Industrial IoT is another area where Zephyr’s security and networking features are driving adoption. The combination of MPU-backed memory isolation and a complete networking stack makes it more appropriate for devices that need to talk to cloud infrastructure securely, particularly in environments where security certification matters.

Getting started

Install the dependencies (West, CMake, the appropriate toolchain):

pip install west
west init myapp
west update

Zephyr has a “Hello World” example that runs on most boards:

west build -b <your_board> samples/hello_world
west flash

The board identifier for your hardware is in the Zephyr supported boards list. For nRF52840 DK: nrf52840dk_nrf52840. For STM32 Nucleo-F401RE: nucleo_f401re. The list is substantial.

The learning investment is real. Budget a few days to get comfortable with the build system, devicetree overlay syntax, and Kconfig before diving into application code. The Zephyr documentation is comprehensive, and the Discord community is active and responsive for questions.

Practical guidance: which to choose

Use FreeRTOS if:

  • Your hardware has less than 16KB RAM
  • You’re using a vendor SDK that ships with FreeRTOS
  • You’re porting existing FreeRTOS code
  • You need a minimal kernel and will provide your own middleware

Use Zephyr if:

  • You need Bluetooth LE (especially with Nordic hardware)
  • Your device needs a full networking stack (MQTT, CoAP, TLS)
  • You’re building a product family across multiple hardware variants
  • Security certification or auditable security model is a requirement
  • OTA firmware updates need to be part of the platform

The choice isn’t usually “which is better” in the abstract — it’s which one fits your hardware constraints, team expertise, and platform requirements. Both are production-ready. Zephyr has more momentum in the connected IoT space; FreeRTOS remains dominant on the lowest-resource microcontrollers and in legacy industrial environments.

If you’re starting a new connected IoT product with mid-range hardware (nRF52, STM32L4 series, or similar), Zephyr is worth a serious evaluation before defaulting to FreeRTOS.