In my view, moving a development team to Zephyr makes a lot of sense, for two main reasons.
This post goes through both with the evidence behind them, then what else comes with the move, and finally the costs you should plan for, because there are some.
1. Zephyr is spreading fast#
Zephyr is now a Linux Foundation project. Major microcontroller and chip vendors such as Nordic, ST, Intel and NXP have built in-house teams to support it. If you do not want to fall behind the industry in the long run, this trend is hard to ignore.
The project started under the Linux Foundation in 2016, and the membership list says more than any adoption chart. As of October 2026 the platinum members include Analog Devices, Antmicro, CARIAD, Google, Infineon, Intel, Meta, Nordic Semiconductor, NXP, Qualcomm, Renesas, Silicon Labs, Texas Instruments, Wind River and ZEISS. Texas Instruments and Infineon moved up to that tier that very month.
The mix matters more than the length. It is not only chip vendors making sure their parts are supported. CARIAD is the Volkswagen Group’s software company, and Google has built the embedded controller firmware of new Chromebook designs on Zephyr since around 2021: the chip that handles power sequencing, battery charging, the keyboard and USB Power Delivery. These are companies that ship products on it.
The vendors’ own SDKs point the same way. Nordic moved its new development to the nRF Connect SDK, which is built on Zephyr, and put the older nRF5 SDK into maintenance mode in 2021. When the vendor of your radio builds its SDK on an RTOS, that RTOS is where its newest features land first.
For planning, the release process matters as much as the momentum. From 2026, Zephyr releases every six months. Every few years one release is designated Long Term Support and maintained for at least five years: the current LTS, 3.7, is supported until July 2029, and the next one, 4.6, is planned for April 2027. A product team can pin an LTS and know how long it will receive fixes.
2. Hardware dependence is now a strategic risk#
We have all lived through it in recent years: sudden price rises, parts that could not be found at any price, supply chains turned upside down. Zephyr’s hardware abstraction, and the way it separates the application layer, reduce that risk considerably. Moving from one microcontroller to another does not mean rewriting the application.
It helps to see what a board actually is in Zephyr. The complete port of ST’s Nucleo F401RE board is nine files and 386 lines:
| File | Lines | What it holds |
|---|---|---|
nucleo_f401re.dts |
206 | The devicetree: clocks, pins, LEDs, buttons, UARTs, I2C, SPI |
st_morpho_connector.dtsi, arduino_r3_connector.dtsi |
108 | The header pinouts, so shields can be described too |
nucleo_f401re.yaml |
22 | Metadata for the test runner |
nucleo_f401re_defconfig |
16 | Default Kconfig values |
Kconfig.nucleo_f401re, Kconfig.defconfig |
18 | Which SoC the board uses, and board-specific defaults |
board.cmake |
10 | How to flash and debug it |
board.yml |
6 | The board’s name, vendor and SoC |
None of those files is C. A board port is a description, not code, and your own PCB gets the same treatment. It can live in your own repository, next to your application, rather than in a fork of Zephyr.
That is why the application survives a part change. The same main.c can
drive an LED through three completely different GPIO drivers, picked by the
devicetree without the code ever naming them; the
post on why I use Zephyr walks through exactly that.
It is worth being precise about the limit, though. Moving within a family, say from one STM32F4 to another, is mostly a devicetree change. Moving to another vendor’s chip means the drivers for every peripheral you use must exist for the new SoC. Check that before you need it, not in the middle of a shortage.
On top of that#
So much comes ready-made that development time shrinks. MCUboot, crypto libraries, the network stack, the BLE stack: instead of writing or integrating them from scratch, you build on top of them. The list keeps going: USB device support, file systems, persistent settings storage, logging, an interactive shell, and a test framework. Each of those is a component your team does not have to own.
Zephyr pushes the team to write modular code. That can feel heavy at first, but in the long run it leaves you with a codebase that is easy to maintain and easy to test.
And with an active community and regular releases, long-term support is one less thing to worry about.
Security, and the Cyber Resilience Act#
For anyone selling connected products in the EU, there is now a third reason, and it has dates attached. The Cyber Resilience Act entered into force in December 2024. Its vulnerability and incident reporting obligations have applied since 11 September 2026, and the full regulation applies from 11 December 2027. Among other things, manufacturers must handle vulnerabilities over a support period of at least five years, and exercise due diligence over the third-party components they ship, open source included.
An RTOS cannot make a product compliant. What it can do is make the job smaller, and Zephyr brings several of the pieces with it:
- A security response process. Zephyr runs its own PSIRT with published targets: feedback to the reporter within 7 days, a fix and a notification to manufacturers within 30, public disclosure after an embargo of at most 90. Product makers can apply to the project’s vulnerability registry to hear about embargoed issues before they become public.
- A list of fixed CVEs in every release, so you can tell whether an update matters to you.
- Long Term Support releases maintained for at least five years, which lines up with the support period the regulation expects.
- SBOM generation built in.
west spdxwrites a software bill of materials for your actual build, in SPDX format.
The Zephyr documentation has its own page on the CRA, covering both what it means for manufacturers and the project’s own obligations as an “open-source software steward”. It is a good starting point, and, as that page says itself, not legal advice.
What it costs#
Moving a team is an investment, and it is better to plan for the costs than to discover them.
The learning curve. Engineers coming from bare metal or FreeRTOS meet Device Tree, Kconfig, the driver model and the build system all at once. Count it in months, not weeks. The first post in this series is about exactly that wall.
Upstream keeps moving. APIs change between releases. Each release ships a migration guide, and they are good, but upgrading is still work. Pin the version, and upgrade deliberately rather than whenever someone runs an update.
Vendor SDKs lag upstream. If you build on a vendor’s Zephyr-based SDK, you get their extra features and their support, but you run a version behind upstream. Decide early which one you follow.
Someone has to own the build. West, CMake, Kconfig and CI are part of the product now. A team needs at least one person who is comfortable there.
How to start#
- Pilot on something that is not on the critical path, on a well-supported board close to your target hardware.
- Pin the Zephyr version in a west manifest from the first day, and pick an LTS for anything that will ship and be maintained.
- Set up CI before the first board arrives. With native_sim and Twister, the tests run on every commit with no hardware at all.
- Keep your boards and your application in your own repository, out of tree, rather than in a fork of Zephyr. Upgrades stay a version bump instead of a merge.
- Train the team before the deadline, not during it.
Done in that order, the costs land at the start, where they are cheapest, and the benefits keep coming for as long as the product lives.