Ten years after the Zephyr Project was launched, the open source real-time operating system (RTOS) is being used across a broad range of connected and embedded products from wearables, keyboards, hearing aids, and tracking devices to laptops, industrial systems, and satellites.
In an exclusive TFiR interview at Open Source Summit in Minneapolis, Swapnil Bhartiya spoke with Kate Stewart, Vice President of Dependable Embedded Systems at the Linux Foundation, about Zephyr’s evolution, its focus on safety and security, the project’s growing use across industries, and how artificial intelligence could shape both Zephyr development and edge computing.
The conversation also explored a central challenge for embedded systems teams: how to build secure, long-lived products while adapting to new regulatory requirements, changing hardware availability, and increasingly complex use cases.
More Than a Real-Time Operating System
Zephyr is an open source RTOS designed for connected, resource-constrained devices. However, it offers much more than a kernel. Its codebase includes communication stacks, peripheral support, drivers, and other components that developers can configure according to the needs of a product.
Rather than searching for and integrating separate libraries for capabilities such as Bluetooth or USB, teams can select the components they need within the Zephyr ecosystem. For developers familiar with embedded Linux, parts of Zephyr’s development model and tooling may also feel familiar.
The project now supports more than 1,000 boards in its repository and has approximately 9,000 repository forks. Its use has also expanded beyond its Internet of Things focus. During the interview, Kate pointed to trackers, keyboards, hearing aids, wearables, industrial devices, Chromebooks, and firmware inside laptops as examples. She also noted that some respondents to the project’s ten-year survey are already shipping tens of millions of units running Zephyr.
These examples show the range of environments in which Zephyr is being used. Many of these products must remain connected, secure, power-efficient, and maintainable for years, while also operating within tight resource constraints.
Safety and Security as Foundational Goals
When the Zephyr Project was being formed, its founders consulted open source developers to better understand why the ecosystem needed another RTOS. Two priorities emerged early: security and the ability to support safety-related systems.
Those priorities have guided the project from the beginning.
One important milestone came in 2017, when Zephyr became a CVE Numbering Authority (CNA). This allowed the project to assign and manage CVEs for vulnerabilities within its scope. Kate also recalled how an external security audit identified issues that the project then addressed. Zephyr has continued to adopt and apply security best practices as it has evolved.
Zephyr has also supported automatic Software Bill of Materials (SBOM) generation for several years. With command-line options, developers can generate an SPDX SBOM that describes the software included in a specific build. This is particularly valuable for embedded products, where the final image is often highly customized and manufacturers need a precise record of its contents.
These capabilities provide an important foundation as product manufacturers prepare for requirements such as the European Union’s Cyber Resilience Act (CRA). Kate said that Zephyr’s long-standing security practices have left the project well positioned for the CRA. She also explained that the project still needs to determine which organization it will work with in Europe as it completes its preparation.
Building a Path Toward Functional Safety
Zephyr is also progressing toward functional safety certification based on IEC 61508. The project has received concept approval for its planned approach. Kate was clear that Zephyr has not yet received the certification itself: concept approval means that the certification authority has agreed that the proposed approach can lead to certification if the project completes the work as described.
That work includes documenting requirements and linking them to the corresponding code and tests. The resulting traceability is needed to show what the software is expected to do, where the behavior is implemented, and how it is verified.
Kate emphasized that this effort can also become a community contribution model. The initial certification scope will cover a defined portion of Zephyr, but companies and developers using other drivers, subsystems, or communication stacks can perform the necessary analysis for those components and contribute it upstream. Maintainers can then review and confirm the requirements, allowing the wider community to benefit.
In this way, Zephyr’s safety scope could grow through collaboration in much the same way as its codebase: one reviewed upstream contribution at a time. Following IEC 61508, the project may also pursue work relevant to ISO 26262 for automotive systems.
From Low-Power Trackers to Satellites
The interview highlighted how Zephyr’s low-power capabilities are enabling products that must operate for long periods with limited energy and connectivity.
One example is a livestock-management device designed for cattle on large ranges. A solar-powered collar uses sensors and on-device AI to monitor factors such as movement and animal health. It can process data locally and periodically communicate through a satellite connection, without depending on conventional network infrastructure. For Kate, the ability to connect a small solar-powered device on an animal directly to a satellite demonstrates how far low-power embedded technology has advanced.
Similar design priorities apply to pet trackers, solar-powered container trackers, hearing aids, smart rings, open source watches, and sensors used in applications such as waste management. These devices need to collect or process useful information while keeping energy consumption low enough to extend battery life or operate through energy harvesting.
Zephyr is also being used in space. Kate explained that the technology from which Zephyr evolved began as a small operating system for satellite applications. After it was acquired and later used as a starting point for the project, Zephyr eventually returned to space and is now being used in a satellite.
Space applications illustrate an important advantage of an RTOS designed for constrained environments. A system can keep a small processor active for monitoring and control while leaving more power-intensive computing resources switched off until they are needed. Developers can determine how frequently sensors run, which components remain active, and when the system should wake additional processing resources.
Supporting Long-Lived Products and Hardware Flexibility
Embedded products often remain in use far longer than consumer software cycles might suggest. According to the survey discussed in the interview, many Zephyr-based products are expected to operate for more than five years, with five to ten years representing a significant product-lifetime range. Some use cases extend much longer.
Long product lifetimes increase the importance of maintainability and access to replacement hardware. A product team may invest years in firmware only to discover that a processor is no longer available or that supply chain conditions require a hardware redesign.
Kate explained that Zephyr can help reduce that risk through its broad hardware support and standardized interfaces. If a manufacturer cannot obtain its preferred component, it may be able to move to another supported processor while preserving much of its application work. This provides greater flexibility and supply chain resilience.
This flexibility allows manufacturers to concentrate on the applications and interfaces that distinguish their products while relying on shared upstream foundations for lower-level capabilities. Kate sees further opportunities for Zephyr in home appliances, printers, cameras, and other connected products, especially where energy efficiency and supply chain resilience are important.
Bringing More Embedded Developers Upstream
Zephyr’s growth is also changing how embedded companies participate in open source.
Many developers first adopt Zephyr because it supports their technical requirements or helps shorten development time, not necessarily because open source collaboration is already part of their workflow. Some teams continue to maintain their changes privately, but that becomes harder when upstream development moves forward and their internal changes must repeatedly be adapted.
This experience can encourage organizations to participate directly in the project. By contributing code, analysis, fixes, and requirements upstream, companies can reduce long-term maintenance work while improving the shared platform on which their products depend.
The project also creates opportunities for developers to build lasting careers around a shared technology. Kate has seen contributors remain active in the Zephyr community even as they move between employers, a pattern long familiar in other established open source communities.
Listening to developers has been central to sustaining that community. Zephyr has conducted regular developer surveys since approximately 2018, using the feedback to understand what is working, identify overlooked problems, improve communication, and guide project investments. Community-elected contributors also serve alongside representatives from member companies in the Technical Steering Committee, helping the project balance different perspectives.
That input supports practical decisions about where project resources are needed, including continuous integration infrastructure and Bluetooth testing, investments that are essential to maintaining quality as the codebase and contributor community expand.
AI in Zephyr and Zephyr at the Edge of AI
The interview concluded with two related questions: how AI can support Zephyr development, and how Zephyr can support AI-enabled embedded systems.
Within the project, AI agents are being evaluated as tools that can assist experienced developers and maintainers. Potential applications include identifying defects before code is merged, supporting code review, refactoring software, improving code quality, and helping teams understand requirements traceability.
Kate also highlighted an important challenge. AI tools can make it easier to generate code, but submissions from people who do not understand the architecture or the proposed changes can consume significant maintainer time. The goal, therefore, is not simply to produce more code. It is to give knowledgeable developers better tools while protecting maintainers from low-quality contributions and burnout.
On devices, Zephyr can support lightweight AI workloads that recognize patterns or detect trigger conditions. In a mixed-criticality or heterogeneous architecture, a low-power processor running Zephyr can continuously monitor inputs. When it detects an event that requires deeper analysis, it can activate a more powerful FPGA or Linux-based processor to perform the resource-intensive computation.
This “trigger and compute” pattern can help systems combine always-on responsiveness with efficient power use. Kate pointed to a satellite architecture as one example and expects the approach to appear in more edge AI systems.
The Next Chapter for Zephyr
After ten years, Zephyr has grown from a new open source RTOS into a widely adopted platform for connected, low-power, and increasingly dependable embedded systems. Its security processes, automatic SBOM generation, expanding functional safety work, broad hardware ecosystem, and upstream development model address many of the pressures facing modern product teams.
The next phase will require continued collaboration: completing the work needed for functional safety certification, preparing for evolving regulatory expectations, expanding requirements traceability, supporting more product categories, and using AI in ways that strengthen development without overwhelming maintainers.
From devices operating quietly inside laptops and appliances to solar-powered trackers and systems in orbit, Zephyr is demonstrating how a shared open source foundation can support embedded products at both extraordinary scale and in extraordinary places.
Watch the full TFiR interview with Swapnil Bhartiya and Kate Stewart to learn more about Zephyr’s first ten years and where the project is headed next.