Zephyr vs FreeRTOS in 2026: Choosing Without Repainting Your Firmware in 18 Months

The decision in one table

If your situation appears in two rows, the tie-breaker is the migration section at the end of this article.

What each one actually is in 2026

Zephyr is a Linux Foundation hosted project under Apache 2.0. Version 4.4.0 was released in April 2026, adding 121 boards and 31 shields plus OpenRISC architecture support, and the project has moved to a fixed six-month release cadence in April and October. Long-term support releases come every two and a half to three years and are maintained for around five; LTS 3.7.0 dates from July 2024. The project states support for more than 1,000 boards and more than ten million deployed devices, and its repository holds over 151,000 commits.

FreeRTOS is MIT licensed and maintained by AWS. It supports more than 40 processor architectures and 15 toolchains. Its LTS branches receive security and critical fixes for two years, and AWS offers an extended maintenance plan of up to ten years.

The structural difference matters more than any feature list. FreeRTOS is a kernel: a preemptive scheduler, queues, semaphores, timers. Everything else (drivers, BSP, networking, update mechanism) you or your silicon vendor provide. Zephyr is an operating system with a kernel inside it: a driver model, devicetree hardware description, Kconfig configuration, in-tree networking, and MCUboot for signed updates. That is why the comparison is not about scheduling performance. Both schedule fine. It is about which parts of the system somebody else maintains.

Footprint, with the feature set that produces it

The kernel-only footprint numbers both projects publish are close to meaningless for a real product. Nobody ships a bare kernel. What determines flash and RAM is which subsystems you enable, and that is a configuration question, not a kernel question.

Approximate figures for a typical Cortex-M4 class build (nRF52840, GCC at -Os): FreeRTOS with NimBLE, coreMQTT and mbedTLS against Zephyr 4.x. Your configuration will move them; the ratios hold better than the absolute numbers.

Two structural notes that hold regardless of the numbers. Zephyr's configurability is genuine (Kconfig lets you strip almost everything), but the defaults are generous, and a first build is usually larger than a hand-rolled FreeRTOS equivalent until someone spends a day on configuration. And an OTA update slot changes the arithmetic more than the RTOS choice does: A/B partitions cost roughly half your flash, which decides your part selection long before your kernel does.

On raw scheduling performance, the only independent measurement of this pair remains a 2022 study from UL Solutions, which reported context switch around 223 cycles on FreeRTOS against around 524 on Zephyr, and interrupt latency around 101 against 143 cycles, on an STM32 F4 part. Treat those as four-year-old figures on one part: both kernels have changed, and unless your deadlines are in the tens of microseconds this is not the axis your decision turns on. The academic literature on RTOS latency for IoT-class devices reaches the same practical conclusion: differences exist and are rarely the binding constraint (Belleza and Freitas, IET Software, reference).

If your system genuinely has hard deadlines, the analysis you need is not a benchmark but schedulability: rate-monotonic scheduling theory, formalised by Liu and Layland in the Journal of the ACM in 1973 (reference), tells you whether your task set can meet its deadlines at all. Both kernels implement fixed-priority preemptive scheduling, so the theory applies to both.

Drivers, boards and what portability is worth

This is where the two diverge most, and where the money is.

On Zephyr, a peripheral is described in devicetree and driven through a subsystem API. Move to a different chip with the same peripheral class and your application code is largely unchanged: the driver model absorbs the difference. That is the entire value proposition, and it is why 121 new boards in a single release matters: somebody else did the board bring-up you would have done.

On FreeRTOS, the kernel does not know what a sensor is. Drivers come from the silicon vendor's HAL, which means your code is coupled to that vendor's API. Change chip family and the porting work is real, even within the same manufacturer.

The honest counter-case: if you will only ever ship one SoC, portability is insurance you do not need, and you pay for it in learning curve. Plenty of shipped products are one-chip products forever.

Onboarding: the learning curve, concretely

Everyone says Zephyr has a learning curve. Here is what it actually consists of.

FreeRTOS configuration is one header you edit:

/* FreeRTOSConfig.h */
#define configUSE_PREEMPTION            1
#define configTICK_RATE_HZ              1000
#define configMINIMAL_STACK_SIZE        128
#define configTOTAL_HEAP_SIZE           10240
#define configUSE_TIMERS                1

Zephyr splits the same decisions across Kconfig and devicetree, built with west and CMake:

# prj.conf
CONFIG_MAIN_STACK_SIZE=2048
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_LOG=y

// board overlay: app.overlay
&i2c0 {
    status = "okay";
    sensor@48 {
        compatible = "ti,tmp102";
        reg = <0x48>;
    };
};

That is the trade in six lines against ten: FreeRTOS gives you one file and full responsibility for the hardware; Zephyr gives you a hardware description language, a configuration system and a build tool to learn, and in exchange the sensor above is driven by an in-tree driver you did not write.

The cost is paid once per team, not once per project, and it is front-loaded, which is exactly why it feels expensive during the first project and invisible by the third. On our team, an engineer new to Zephyr took about three weeks to merge useful work, and under a week on their second project.

One cost that is real and rarely mentioned: toolchain churn. Zephyr SDK versions and west manifests move, and a version bump can cost an afternoon.

Vendor reality: which one your silicon actually supports

This often settles the decision before any of the above matters.

The ESP-IDF detail is the one most articles get wrong, and it matters for portability estimates: code written against Espressif's fork is not automatically portable to upstream FreeRTOS, so "we use FreeRTOS" can mean two different things on two projects.

Licensing and safety certification

Zephyr is Apache 2.0; FreeRTOS is MIT. For most commercial firmware both are permissive enough that the choice is not legal but procedural: Apache 2.0 carries an explicit patent grant and an attribution requirement, and your legal team will want the notices right. MIT is shorter and imposes less. Neither obliges you to publish your application code.

Safety certification is where the internet is misleading, and correcting it is the most useful paragraph in this article. Zephyr's Zephyr Safety Committee is pursuing IEC 61508 SIL 3 / SC 3 certification for a limited scope of the source tree. As of 2026 that work is in progress, with no published completion date. Zephyr is not a certified safety kernel today. If you need a certified kernel now, the options are commercial: SafeRTOS, or a certified variant from a vendor, with the artefacts to match. Plan accordingly, and do not let a vendor blog persuade you otherwise.

The standard itself is worth reading rather than paraphrasing: IEC 61508:2010 defines the SIL levels and the software lifecycle requirements behind them.

One adjacent point that now affects both: the EU Cyber Resilience Act has applied vulnerability-reporting obligations since 11 September 2026, with main obligations from 11 December 2027. That makes a maintained update path and an SBOM part of the product, and it is easier to satisfy on a stack whose components have a documented provenance and release cadence.

The migration cost nobody budgets

This is the section the title promises, and no competing article attempts it.

What carries over when you switch:

• Application logic that is already isolated from hardware (state machines, protocol parsing, business rules)
• Protocol implementations you wrote yourself
• Test vectors and, with effort, unit tests

What does not:

• Device drivers written against a vendor HAL. On Zephyr they become devicetree nodes and subsystem calls; the work is a rewrite, not a port
• The build system, entirely: FreeRTOSConfig.h and a vendor IDE project become Kconfig, devicetree and west
• Assumptions about static allocation, stack sizing and heap behaviour, which differ enough to require re-tuning
• Your OTA update mechanism, if it was vendor-specific, becomes MCUboot with signed images
• Certification artefacts, if you had them, which is the expensive one

A rough shape of the cost:

The general principle is older than either project. Effort in software scales with size and with a set of cost drivers, of which team familiarity with the platform is among the strongest: Boehm's Software Engineering Economics (reference) put numbers on that in 1984, and it is why the same migration costs one team a month and another a quarter.

The practical decision rule: if there is a realistic chance of a second SoC within two years, the migration you avoid is worth more than the learning curve you pay. If there is not, it is not.

Our own numbers

Engineer-hours to reach each milestone on our projects, FreeRTOS against Zephyr:

Figures from ByteNana projects, 3 boards (nRF52840 DK and ESP32-DevKitC, reference designs available, engineers experienced on FreeRTOS and new to Zephyr), 2024-2026. Hours are engineer-hours, not elapsed days.

One pattern worth stating plainly: our first Zephyr bring-up took about twice as long as our third. The learning curve is real, and it is paid once.

Frequently asked questions

Does Zephyr replace FreeRTOS?

No. FreeRTOS is a kernel; Zephyr is an operating system that includes a kernel plus a driver model, devicetree, configuration through Kconfig and in-tree networking. They overlap in scheduling and diverge in everything else.

Can I migrate FreeRTOS code to Zephyr, and what carries over?

Application logic isolated from hardware carries over. Device drivers written against a vendor HAL do not: they become devicetree nodes and subsystem calls, which is a rewrite. The build system is replaced entirely, and if you hold certification artefacts, re-certification is usually the largest single cost.

Is Zephyr production ready in 2026?

Yes. The project publishes a stable release every six months, states support for more than 1,000 boards and more than ten million deployed devices, and is the foundation of Nordic Semiconductor's nRF Connect SDK. Production readiness and safety certification are different questions.

Is Zephyr certified for safety-critical use?

Not as of 2026. The Zephyr Safety Committee is working towards IEC 61508 SIL 3 / SC 3 for a limited scope of the source, with no published completion date. If you need a certified kernel today, look at commercial options such as SafeRTOS.

Which RTOS does my chip vendor support, and does that settle it?

Often, yes. nRF Connect SDK is Zephyr; ESP-IDF ships Espressif's own FreeRTOS fork; STM32Cube integrates FreeRTOS while Zephyr supports STM32 in-tree. Following the vendor is the cheapest path for a single-chip product, and the expensive one if you later change vendor.

Does the Apache 2.0 versus MIT difference matter?

Rarely for the engineering, sometimes for legal review. Apache 2.0 adds an explicit patent grant and an attribution requirement; MIT is shorter. Neither requires you to open your application code.

The short version

• The decision turns on expected silicon churn and certification scope, not on scheduling performance.
• Bare-kernel footprint figures are marketing; what matters is flash and RAM with your feature set enabled.
• Zephyr's cost is west, Kconfig and devicetree, paid once per team and front-loaded.
• Zephyr is not safety-certified in 2026: the work is in progress on a limited scope.
• If a second SoC inside two years is realistic, the migration you avoid outweighs the learning curve. If not, FreeRTOS is the honest answer.