In the panorama of Internet of ThingsThe trend toward edge computing is changing the game: devices are processing data locally, reducing reliance on the cloud, and must operate reliably, predictably, and with limited resources. In this context, Zephyr RTOS has become a very strong option thanks to its modular design, real-time focus, and truly extensive connectivity support.
Beyond marketing, what's interesting is how zephyr It addresses real-world problems: deterministic scheduling, fine-tuning memory usage, a modern network stack, a consistent controller model, built-in security mechanisms (including MPU and secure boot), and an active community that promotes standards and best practices. If you're looking for an IoT platform that won't let you down in production, it's worth taking a closer look.
Why Zephyr fits into the edge IoT
One of the key requirements of Edge is the real time execution with predictable latencies. Zephyr incorporates preemptive scheduling based on priorities and time allocation among threads of equal priority, making it a perfect fit for industrial automation, automotive, or medical devices, where every millisecond counts.
This deterministic approach is enhanced by integrating with device management platforms such as Clea Edgehogwhich allow you to observe behavior in the field, set time windows for critical tasks, and orchestrate updates without losing control over application deadlines.
Footprint and resource management: modularity well understood
Zephyr's architecture is highly configurableso you only compile what you need. The project promotes a SASOS (single address space) and generates a monolithic image tailored to the application: all system resources are defined at compile time, reducing code size and improving performance.
Thanks to this modularity, the same device tree and Kconfig allow you to trim drivers, services, and network stacks to make it work from minimal sensors up to gateways powerful. In smart city deployments, for example, you can maintain compact images for low-power nodes while simultaneously enabling advanced features on hub nodes.
When data orchestration comes into play, the combination with Clea Astarte It helps move telemetry and commands efficiently between edge and cloud, without wasting memory or CPU cycles on the device.
Comprehensive connectivity: from BLE to MQTT, including Thread and CoAP
Zephyr comes standard with a modern mains battery with support for Bluetooth (BLE and 5.0)Thread, 6LoWPAN, CoAP, MQTT, IPv4/IPv6, Wi-Fi, Ethernet, CANbus, and USB/USB-C, plus options like Zigbee or LoRa depending on the platform. This diversity allows you to choose the right standard without changing your RTOS.
In practice, you can assemble anything from simple sensor networks to complex industrial systems, by combining MQTT For telemetry, CoAP in restricted environments or BLE for local pairing. Interoperability facilitates integration with existing infrastructures and accelerates time-to-market.
- IoT protocols: CoAP, LwM2M, MQTT, OpenThread, 6LoWPAN.
- Transportation/Means: Bluetooth 5.0/BLE, Wi-Fi, Ethernet, CANbus, USB/USB-C.
Hardware and driver abstraction layer
Zephyr's HAL abstracts the silicon details so that the same application code can work on different architectures such as ARM Cortex-M, Intel x86, RISC-V (For example, security hardware such as Tilitis TKey) or ARC. The driver model and Board Support Packages help incorporate new peripherals without rewriting the application.
The community provides ongoing support for boards, sensors, and driversThis translates into less friction when porting your project to a new microcontroller or adding capabilities, while keeping maintenance under control.
Basic security: MPU, isolation, and verified boot
In IoT, it's not enough to just function; you have to do it in a way that allows you to do so. safeZephyr includes support for MPUs (Memory Protection Units), thread isolation, and secure boot mechanisms—such as those provided by Opentitan— to ensure that only authenticated firmware is run.
The project operates with a “security by design” mindset: testing fuzzyStatic analysis, pentesting, code review, backdoor analysis, and threat modeling are part of the development process, complemented by a vulnerability response team and responsible disclosure practices.
In terms of protocols, the following are considered: TLS/DTLS to protect communication and cryptographic libraries for encryption and key managementThis is crucial when telemetry crosses unreliable networks or the device is deployed in exposed environments.
Audits and known vulnerabilities: what you need to know
Transparency in security is essential. An audit of NCC Group It listed 25 vulnerabilities in Zephyr and 1 in MCUboot, with the following distribution: 6 in the network stack, 4 in the kernel, 2 in the shell, 5 in system call drivers, 5 in USB, and 3 in the firmware update mechanism.
Two problems were classified as critics (impacting IPv4 and the MQTT parser), two as high, nine moderate, nine low, and four "to be aware of." At the time of disclosure, fixes had been prepared for the 15 most critical ones, with others pending resolution to prevent denial-of-service conditions or improve kernel defenses.
Among the most relevant findings: a remotely exploitable vulnerability in IPv4 that caused memory corruption when processing manipulated ICMP packets, and a bug in the MQTT parser due to a lack of length validation that could lead to remote code execution. Less severe DoS vulnerabilities were also identified in IPv6 and in the implementation of CoAP.
At the local level, several vulnerabilities allowed DoS attacks or kernel-privileged execution due to insufficient argument validation in system calls (including a case of a negative syscall number that caused integer overflow). Weaknesses were also noted in the implementation of ASLR and in the use of battery-operated canaries, reducing their effectiveness.
The USB subsystem presented several problems: in USB mass storage, it was possible to buffer overflow and kernel code execution when connecting the device to a malicious host; in USB DFU, modified firmware could be uploaded to the flash memory without encryption, bypassing secure boot mode with signature verificationIn MCUboot, a non-critical buffer overflow was detected when using SMP over UART.
In addition, a specific issue was documented in BLE: a malicious device could cause a Overflow sending a malformed adware package, with the potential impact of DoS or RCE on the victim device running Zephyr. These lessons underscore the need to keep versions up to date, strengthen validations, and proactively activate mitigation measures.
Integration with Clea (SECO): fleet orchestration and management
SECO has released SDKs that connect Zephyr with its Clea suite: Astarte Device SDK for data orchestration and Edgehog Device Component for device management. This integration offers secure pairing, data synchronization, MQTT-based communication, interface definition generation, and edge analytics.
In the management section, Edgehog enables reports on the status of the OS and hardware, OTA updatesHealth monitoring and remote control facilitate operations at scale. Compatibility with a wide range of platforms reduces time-to-market and allows even less resource-intensive devices to connect seamlessly.
SECO's strategy involves open collaboration and contributing to the Zephyr ecosystem. The company emphasizes that these components expand the range of supported applications and open the door to new ones. use cases in edge AI/ML, data orchestration and fleet management.
Quality, compliance and certification: the role of Parasoft
Project Zephyr works to raise the bar for code security and quality. In this vein, Parasoft joined the committee of to maximise security and your enjoyment. of the project to promote test automation and support security certification.
Their tools cover static analysis, unit testing, and structural coverage, with support for standards such as MISRA C:2012 and CERT. In addition, they provide deliverables that help with SIL 3 (SC3) certification according to IEC 61508 and analysis panels for continuous monitoring, supporting releases with long-term support (LTR).
Parasoft's experience in critical environments aligns with the project's objective: a codebase trustworthywith repeatable processes, clear metrics, and evidence of compliance that facilitates audits and deployments in regulated domains.
System architecture and layers
Zephyr is structured in layers to keep responsibilities separate. At the center is the kernel in real time, providing scheduling, interrupts, and synchronization. Above this are system services (memory management, I/O, libraries), the network subsystem, and the driver layer for peripherals.
Security layers provide isolation and cryptography, while partial compliance with POSIX It facilitates the portability of certain components. Although the final binary is monolithic and application-specific, some describe the design as "micro-kernel" due to the functional separation of services and its modularity.
Use cases and supported hardware
Zephyr is designed for devices with limited resources: sensorsWearables, home automation, and industrial environments. Its low power consumption and real-time response make it ideal for production sensors, factory gateways, or medical devices with stringent requirements.
Public examples of products based on Zephyr include Proglove, Ruuvi Tag, PHYTEC Distancer, Keeb.io BDN9, Hati-ACE, Oticon More, Adhoc Smart Waste or GNARBOX 2.0 SSD, demonstrating its adoption in very diverse areas.
Compatibility covers ARM Cortex-M, Intel x86, RISC-VARC and other architectures are supported, and the development environment can be set up on Windows, Linux, or macOS. The Getting Started guide and official documentation detail step-by-step how to prepare toolchains, SDKs, and build/flash workflows.
Resources for developers and the community
The community maintains extensive documentation, tutorials, and a forum Active with recipes ranging from the first "blinky" to sensor integration, energy savings, and advanced connectivity. This support reduces the learning curve for Kconfig, Device Tree, and the threading/ISR model.
A typical workflow includes installing the Zephyr SDK, cloning the repository, and configuring the hardware with Device Tree and Kconfig, compile and flash. This chain is consistent across multiple platforms, simplifying things when managing several boards or architectures in parallel.
RTOS context and market
RTOSs were born in the 60s-70s for urgent applications in defense and aerospaceIn the 80s and 90s, commercial solutions like VxWorks and QNX became established, with standardization via real-time POSIX. In the 2000s, the IoT explosion spurred lightweight options like FreeRTOS and, later, Zephyr.
Today, many RTOS incorporate AI/ML to anticipate failures and optimize planning depending on system conditions. The RTOS market was estimated at $5,97 billion in 2024 and is projected to grow from $6,41 billion in 2025 to $12,21 billion in 2034, with a CAGR of 7,41% during 2025-2034.
Compared to other alternatives, Zephyr stands out for its modularityIts strengths lie in security, protocol breadth, and cross-platform compatibility. Its challenges lie in the initial setup curve, inherent limitations of the target hardware, and the availability of certain highly specific drivers.
Looking at the whole picture, Zephyr provides a robust foundation for building connected devices with predictable timings, tight power consumption, and defenses integrated. If you add data orchestration (Astarte) and fleet management (Edgehog), you can deploy everything from pilots to massive operations with secure telemetry, reliable OTAs, and end-to-end operational visibility.
