As of 2026, Zephyr RTOS has moved from a small RTOS initiative to widespread production use. The Linux Foundation Research found that 70% of surveyed organizations in the US and Canada, as well as 62% in Europe, already use Zephyr in commercial products.
This guide is for CTOs, heads of embedded engineering departments, and hardware product leads considering Zephyr for a new connected product or weighing a migration from FreeRTOS.
What is Zephyr RTOS?
Zephyr RTOS is an open-source real-time operating system released under the Apache 2.0 license and hosted by the Linux Foundation. Zephyr is built for resource-constrained devices, from small microcontrollers to multi-core systems. Unlike a bare kernel, Zephyr ships with drivers, networking and Bluetooth support, security features, and its own build tooling.
Zephyr originated from Virtuoso, an RTOS for digital signal processors, whose developer was acquired by Wind River Systems in 2001. The OS was rebranded as Rocket kernel in 2015. The following year, Rocket changed its name to Zephyr and became a Linux Foundation project.
Today, Zephyr supports over 1,000 boards and has grown from about 100 contributors at launch to over 3,000 around the world.
Zephyr RTOS overview: How is Zephyr built?
Zephyr combines a configurable kernel with Device Tree to describe hardware, Kconfig to select features, and the west tool for build orchestration and repository management. The RTOS kernel uses priority-based scheduling, supporting preemptive and cooperative threads, as well as symmetric multiprocessing (SMP) on supported multicore platforms.
Beyond the kernel, Zephyr includes networking, Bluetooth, Wi-Fi support, USB, a shell, logging, tracing, and device firmware upgrade capabilities. Zephyr’s native_sim target compiles the Zephyr kernel and application into a native executable, allowing teams to run applications and integration tests without target hardware.
According to the Zephyr Project, supported architectures include ARM, RISC-V, Intel x86, Tensilica Xtensa, ARC, MIPS, SPARC, and OpenRISC. Major releases are delivered twice a year. As of 2026, Zephyr 4.5.0 is the latest stable release, while Zephyr 3.7.0 (LTS3) receives long-term support until July 27, 2029.
Zephyr RTOS vs FreeRTOS: What is the difference?
The main difference between Zephyr RTOS vs FreeRTOS is scope. Here is an explanation: FreeRTOS is a small kernel you extend with the libraries you choose, while Zephyr is a full platform with drivers, stacks, and tooling included. FreeRTOS is simpler to start with. Zephyr does more from day one but takes longer to learn.
| Zephyr RTOS | FreeRTOS | |
|---|---|---|
| Scope | Full platform: kernel, drivers, stacks, tooling | Kernel plus a growing set of libraries |
| License | Apache 2.0 | MIT |
| Governance | Linux Foundation | AWS |
| Hardware configuration | Device Tree + Kconfig | Vendor HAL + FreeRTOSConfig.h |
| Connectivity stacks | TCP/IP, MQTT, CoAP, LwM2M; BLE host & controller support; Wi-Fi & cellular through supported drivers & integrations; Thread via OpenThread | FreeRTOS-Plus-TCP (IPv4/IPv6), coreMQTT, coreHTTP, Cellular Interface; no Bluetooth or Wi-Fi library in LTS |
| OTA approach | MCUboot + MCUmgr, cloud-agnostic | Modular AWS IoT OTA libraries |
| Long-term support | LTS about 5 years (next LTS planned: 4.6, April 2027); up to 15 years via paid third-party support | LTS 2 years; extended maintenance plan available |
| Safety certification path | Working toward IEC 61508 SIL 3 certification for a limited scope | SAFERTOS: separate pre-certified kernel based on the FreeRTOS functional model |
| Learning curve | Steeper | Gentler |
| Best for | Multi-protocol devices, several hardware targets, long support | Single-MCU devices, small teams, AWS IoT products |
How do you choose between Zephyr RTOS and FreeRTOS?
We recommend choosing an operating system based on the product, not on the RTOS everyone is talking about. What matters is your hardware roadmap, connectivity, security obligations, update strategy, support window, and the team you have.
Architecture and hardware portability
If you expect board revisions or a second-source chip, Zephyr is more flexible. Device Tree keeps the hardware description separate from application code, so switching to a board Zephyr already supports is mostly a configuration change. According to the 2026 Linux Foundation research report, Zephyr Turns 10, 49% of organizations named easier hardware portability as the biggest impact of adopting Zephyr. With FreeRTOS, drivers usually come from the vendor HAL, so a chip change often means reworking. A Bluetooth Low Energy (BLE) sensor planned for two MCU vendors to reduce supply risk is a typical Zephyr case.
Ecosystem maturity
Check your chip vendor’s SDK first, because it often makes the decision for you. Nordic’s nRF Connect SDK is based on Zephyr, and NXP is a founding platinum member of the Zephyr Project. Espressif takes a different approach: ESP-IDF integrates FreeRTOS, which underpins its applications and many components. Zephyr adoption is still rising, and 69% of surveyed organizations plan to use it more.
When choosing a tech vendor, look for one that has hands-on experience with the ecosystems of leading semiconductor providers, including NXP, Nordic Semiconductor, Espressif Systems, etc.
Connectivity
For a device that combines several protocols, Zephyr can be a strong fit. It provides configurable networking and connectivity components, such as IPv4/IPv6, TCP/IP, MQTT, CoAP, HTTP, and BLE. These capabilities make Zephyr a good choice for connected products that require stable wireless communication. Here is an example. As part of our IoT development services, we built Zephyr RTOS-based firmware for our client’s ID card solution. The process included implementing BLE using the nRF5340 chip to provide reliable connectivity, which was crucial for the project.
Thread support comes through OpenThread. Wi-Fi, cellular, and LoRaWAN capabilities depend on supported drivers, modules, and hardware. Note that Zephyr 4.4 includes WireGuard VPN and Wi-Fi Direct support. In October 2026, Zephyr 4.5.0 was released with a few updates.
With FreeRTOS, networking comes from libraries outside the kernel: a TCP/IP stack such as FreeRTOS-Plus-TCP or lwIP, application-protocol libraries such as coreMQTT and coreHTTP, and the chip vendor’s Bluetooth and Wi-Fi stacks.
Security
Whichever RTOS you pick, compliance is ultimately the manufacturer’s responsibility. Zephyr has a Product Security Incident Response Team (PSIRT) and has been a CVE Numbering Authority since 2017, so the project can assign CVE identifiers to vulnerabilities within its scope. It can also generate a software bill of materials (SBOM) from a build. The Zephyr Project is working toward IEC 61508 SIL 3 / SC 3 certification for a limited scope centered on the kernel and its interfaces.
FreeRTOS long-term support releases receive security updates and critical bug fixes for at least two years. This helps teams incorporate fixes throughout development and deployment. For products covered by the EU Cyber Resilience Act (CRA), vulnerability and incident reporting obligations have applied since September 11, 2026, with the broader CRA obligations applying from December 11, 2027. If you need a CRA gap analysis, compliance roadmap, and effective implementation of compliance measures for your project, then CRA consulting is the way to go.
OTA updates
On Zephyr, MCUboot verifies signed firmware images and, depending on its configuration, supports rollback to the previous image. Updates can be delivered through MCUmgr over BLE or UDP, HTTP-based firmware download, LwM2M, or platforms such as Golioth, hawkBit, and Memfault.
On FreeRTOS, AWS states that its original OTA library remains available but will not be developed further, with support focused on modular OTA libraries. Your team then integrates them into its update workflow and uses a suitable bootloader.
AWS IoT provides managed fleet deployments; outside a managed platform, either RTOS requires image hosting, update orchestration, and deployment reporting to be provided or integrated.
Long-term maintainability
Canonical's Zephyr 26.04 LTS goes beyond upstream Zephyr’s standard 5-year support, providing up to 15 years of security maintenance. Frequent upstream releases can require ongoing migration and testing efforts, while an LTS release provides a stable foundation with fewer upgrade cycles. According to the Zephyr Turns 10 report, 52% of organizations state that they support Zephyr-based products for five to ten years or longer.
FreeRTOS LTS releases are supported for at least 2 years. If your project requires more, the FreeRTOS Extended Maintenance Plan is a great choice. It provides security patches and critical bug fixes for a chosen LTS version for up to 10 years additionally, subject to the plan terms.
Team expertise and learning curve
Budget learning time if your team comes from FreeRTOS. Zephyr’s workflow relies on Device Tree, Kconfig, west, and CMake, which are unfamiliar to many engineers from bare-metal or proprietary RTOS backgrounds. The Zephyr Turns 10 report states that only 20% of respondents noted an improvement in Zephyr’s learning curve.
Practitioners on Reddit highlighted Zephyr’s extensive driver support, well-designed abstracted APIs, and the fact that it’s well-maintained. However, some said FreeRTOS is easy to get started with, while Zephyr is harder to learn.
Migration cost
Moving from FreeRTOS to Zephyr is not a simple API swap: expect changes to the build system, configuration, driver model, and command-line interface. Zephyr’s CMSIS-RTOS v2 and POSIX compatibility layers can reduce porting effort for code already written against those APIs. Boston Engineering’s Porting from FreeRTOS to Zephyr whitepaper states that the team moved from FreeRTOS+CLI to the Zephyr Shell and chose Zephyr partly for a more developed CANopen integration process.
When should you use Zephyr RTOS instead of FreeRTOS?
Zephyr makes the most sense for connected devices that use several protocols, will go through planned hardware revisions, need long-term support, or must meet EU market requirements. Here’s a typical case: a BLE and Wi-Fi gateway that is expected to run on two board revisions over eight years. Device Tree cuts down the rework for each new board, and the team can plan one LTS migration or paid extended support.
FreeRTOS is often the cheaper choice for a single-MCU device built on a mature vendor SDK, a small team with FreeRTOS experience, or a product centered on AWS IoT. Zephyr’s portability and built-in stacks add learning time without paying back.
If your product needs a rich UI, heavy networking, or more memory than a microcontroller offers, it may have outgrown an RTOS altogether. See our guide to embedded Linux.
Conclusion
As of 2026, Zephyr is a production-grade RTOS with long-term support options and a growing commercial user base. The choice between Zephyr and FreeRTOS depends more on your product’s connectivity, security, update, and support requirements than on which RTOS is more popular. Our embedded engineering team is ready to help if you need assistance with RTOS selection, porting from FreeRTOS, or firmware for a Zephyr-based device.
