Why Zephyr is becoming the go-to for MCU development

Is Zephyr the Future of MCUs?

The world of MCU software development is evolving rapidly. With the rise of connected devices, regulatory compliance, and increasing software complexity, developers and decision-makers face an overwhelming number of choices when selecting an RTOS.

Should you go bare-metal, Zephyr, FreeRTOS, Thread X or use a Silicon Vendors SDK as a base?

Making the wrong choice can lead to:

Which is why Witekio is providing this guide to help you navigate these risks, analyze if Zephyr is the right OS for your device, and learn from our experts on the best way to implement it.

DIY vs Outsourcing: Whatʼs the Right Move?

Before we get into WHY Zephyr could be the best choice for you, we first need to take a step back and see if Open Source is the best option for you all together.

When it comes to embedded development, the choice between using vendor-specific SDKs and open-source frameworks often hinges on three key considerations: hardware flexibility, customization to your use case, and whoʼs doing the development—your team or a partner. Vendor-specific SDKs can help you get started quickly with hardware- accelerated features and tightly integrated tooling. But that convenience often comes at the cost of long-term flexibility. Migrating to new hardware can mean rewriting large parts of your codebase, especially if youʼre locked into a proprietary stack.Open-source frameworks—like Zephyr or others—offer greater portability and long-term sustainability. Theyʼre not tied to a single vendor, which gives you more freedom to pivot hardware as your product evolves. They also allow for deeper customization tailored to your specific application needs. But they demand the right expertise to build, optimize, and maintain effectively.At the end of the day, itʼs a question of ownership: are you planning to build and maintain everything in-house, or will you rely on a partner with the know-how to design, integrate, and support your stack over time?

Thatʼs why we recommend an approach we call Open Source +.

Going fully DIY with open source will often mean hiring in-house resources or dedicating one of your team solely to tasks like maintenance, security and updates.

For us, the most effective approach would combine the flexibility of open source with dedicated software support to ensure a secure, scalable, and production-ready solution, while your team can work on the business- critical projects.

The Cost of Getting It Wrong

Making the wrong choice in MCU software development can have long-term financial and operational consequences.

• Slower Time-to-Market – Traditional MCU development often lacks modern CI/CD integration and a scalable software architecture, leading to delays in deployment and feature updates.
• Security Risks & Compliance Failures – Many proprietary vendor SDKs are poorly maintained and lag behind in security patches. As regulations like the EU Cyber Resilience Act take effect, compliance failures can lead to fines, recalls, and reputational damage.
• Hardware Migration Headaches – Switching MCUs with a traditional RTOS often requires a complete software rewrite, delaying product updates and increasing engineering costs.

The Challenges of Modern MCU Development

With advances in hardware, MCUs can now handle applications that once required embedded Linux, offering lower cost and power consumption.

However, this shift brings new challenges:

• Security is non-negotiable – IoT growth and regulations like the EU Cyber Resilience Act demand built-in security and updatable firmware.
• Complexity is increasing – MCUs now need to support multiple hardware interfaces, communication protocols, and real-time processing, making bare-metal development impractical.
• Software must be adaptable – Traditional MCU development tied applications to specific hardware, forcing costly rewrites when migrating to a new platform.
• Fragmented toolchains slow development – Vendor-specific SDKs, outdated third-party code, and manual build processes make CI/CD integration difficult and hinder scalability.
• A modern MCU development approach must be secure, scalable, and hardware-agnostic—which is exactly why developers are turning to Zephyr.

Why Developers are Choosing Zephyr

Scalability and Hardware Support

One of the major differences between Zephyr and other competing RTOS ecosystems is the hardware abstraction capability. Some of the following problems will likely seem familiar to anyone involved in the development of embedded systems:

• Software development must wait for the productʼs custom hardware to be available.
• Multiple hardware revisions are needed, each needing custom modifications to the software.
• At some point in the lifecycle of a product, the software out-grows the hardware platform and requires migration to something with more memory or processing power.
• Hardware becomes obsolete or has supply shortages, so the software needs to be migrated to a new platform.

Zephyrʼs hardware abstraction model makes it easy to develop most of the software on one of almost 650 supported boards, usually available off-the-shelf, and migrate to your custom hardware later.

Often no changes to the C code at all are required to move to a different board, only some modifications to the devicetree and board-level configuration.

Taking this to the extreme, Zephyrʼs “native simulator” board allows running applications on your host PC, with full support of the kernel, networking stack, serial input/output and a variety of emulated hardware peripherals.Zephyrʼs hardware model was designed with different board variants and revisions in mind.

Need to change the clock source to the processor? Set some GPIO pins on startup to enable other components on your board? Even switching an I2C sensor device to a completely different model?

All of this can be done in the same code-base with a devicetree overlay file describing the changes, and building software targeting each revision is as simple as changing the revision in your build command.

Migrating your design to an entirely new MCU can in many cases be just as easy. Application calls to device drivers go through a consistent API, with the differences between hardware managed in the driver itself.

At an application level, writing to an I2C bus is identical whether the underlying MCU comes from ST, NXP, or any other vendor. An enormous range of drivers is included in the Zephyr tree itself, contributed by both vendors and the community.

Built-in Security

With the rise of IoT and connected devices, security is now a top priority for device makers, as high-profile breaches continue to make headlines.

Creating a secure device has several key parts which Zephyr can help to achieve.

• Cryptographic Security – Uses mbedTLS, a trusted, audited library, with algorithms easily configured via Kconfig.
• Secure Networking – TLS is seamlessly integrated, allowing certificate -based secure sockets with minimal setup.
• Trusted Execution – On supported hardware, TrustedFirmware-M isolates sensitive data, preventing access even in case of bugs.
• Firmware Updates & Integrity – MCUboot bootloader ensures secure, authenticated updates to patch vulnerabilities.

Rich Ecosystem

With the increasing complexity of embedded software running on MCU, along with tight timelines for development, it is nearly inevitable that some 3rd party library code will need to be integrated. This could be anything from vendor device drivers to a networking stack or filesystem.

Zephyr includes a huge variety of drivers, subsystems and libraries. Some particular highlights are:

• Extensive Device Drivers – Supports MCU peripherals (UART, I2C, SPI), displays, and cellular modems, plus hundreds of sensor drivers.
• Bluetooth Stack – Includes controller and host layers for single-chip or external Bluetooth solutions.
• IP Networking – Supports Ethernet, Wi-Fi, IEEE 802.15.4, OpenThread, and IoT protocols like MQTT, HTTP, CoAP, and LwM2M with a POSIX-compatible API.
• Debugging & Logging – A flexible logging system and interactive shell enable real-time network, sensor, and system diagnostics.

Top Tip:

Choosing and configuring the software components to include in your application is the job of Kconfig, a tool borrowed from Linux. Much like Linux, there is an interactive menuconfig interface to browse the available options. Zephyrʼs active community and involvement from many of the largest vendors in the industry means that the features and hardware support available are growing continuously.

Streamlined Development

One of Zephyrʼs greatest advantages is the unified development environment. For any engineer developing across multiple product lines and hardware vendors, it is common to end up with a tangled web of obscure toolchains and vendor IDEs, each with their own quirks and bugs.

Zephyr provides a common environment to build and test your software across all supported hardware. Regardless of the underlying compiler, toolchain or debug probe being used, building and flashing software is all wrapped by the “West” command line tool.

All of the tooling being available from the command line makes it straight-forward to build and test your software in a continuous integration (CI) system in line with modern development best practices. To get started quickly with the tooling already set up, itʼs possible to simply pull the docker container used in the Zephyr projectʼs own CI on GitHub.

Good documentation is key for any software development framework. As well as the extensive online documentation, Zephyr has hundreds of sample applications included, showing how to use a variety of features, subsystems and modules in a practical way.

Comparison: Zephyr vs. Other RTOS Options

Zephyrʼs main open-source RTOS competitors are FreeRTOS and ThreadX.

FreeRTOS is a lightweight, easy-to-integrate option, ideal for minimal RTOS needs, but lacks the extensive built-in libraries found in Zephyr or ThreadX.

ThreadX offers more advanced features, including networking, USB, and a GUI framework, with strong safety certifications—though accessing these requires a paid license.

Zephyr stands out with its broad feature set, strong hardware support, and powerful hardware abstraction model, making applications modular and portable across MCUs. While its learning curve is steeper, particularly with devicetree and Kconfig, its growing community and vendor support ensure developers have access to extensive resources and ongoing improvements.