Zephyr RTOS 4.4 adds WireGuard, Wi‑Fi Direct, and OpenRISC support

Zephyr RTOS 4.4 brings WireGuard, Wi-Fi Direct, OpenRISC support, and a shift to Zephyr SDK 1.0 and C17, extending the open-source RTOS further into secure networking, open hardware, and embedded vision work.


IN Brief:

  • Zephyr 4.4 adds native WireGuard, Wi-Fi Direct, and initial OpenRISC support.
  • The release also moves to Zephyr SDK 1.0, experimental Clang support, and C17 as the baseline.
  • Embedded Linux is not the only open platform broadening its reach into connected edge and vision workloads.

The Zephyr Project has released Zephyr RTOS 4.4, bringing a substantial set of updates that push the open-source real-time operating system further into secure connectivity, open hardware, and edge device integration. The headline additions include native WireGuard support, Wi-Fi Direct in the Wi-Fi management stack, and initial OpenRISC architecture support, alongside Zephyr SDK 1.0 and a move to C17 as the project’s minimum language baseline.

That is a useful mix of changes because it touches both application developers and platform maintainers. WireGuard support gives Zephyr-based devices a simpler route to secure, low-overhead tunnelling for remote access and encrypted data transport. Wi-Fi Direct widens the options for device-to-device setup and communication in environments where conventional infrastructure Wi-Fi is either unavailable or an unnecessary complication. OpenRISC support, while initially 32-bit only, broadens Zephyr’s footprint in FPGA-based designs, academic hardware, and custom silicon projects that sit outside the better-known Arm and RISC-V ecosystems.

There is also a tooling angle that matters just as much as the feature list. Zephyr 4.4 is the first release to ship with Zephyr SDK 1.0, including bundled OpenOCD and QEMU, and it introduces experimental Clang/LLVM support. The shift to C17 is another sign that the project is tightening its engineering foundations rather than simply adding drivers at the edges. In practice, these changes should make version planning, build portability, and long-term maintenance more predictable for teams already committed to Zephyr, and more attractive for those still deciding whether to standardise on it for product families rather than isolated programmes.

One of the more interesting aspects of the release is how the new networking and USB host additions can be combined. Zephyr 4.4 expands experimental USB host support and adds UVC camera support, while also bringing in new camera sensor drivers. Put together, that opens the door to small embedded systems that can ingest video, connect directly to peers, or tunnel traffic securely without jumping to a heavier Linux-class platform. That will not replace Linux in high-end gateways or application processors, but it does narrow the gap for constrained devices that need a more deterministic software stack with modern connectivity.

The wider significance is that RTOS development is no longer just about task scheduling, interrupt latency, and whether a kernel fits into limited memory. Embedded software is being dragged steadily into a world of secure provisioning, remote management, AI-adjacent edge processing, and mixed hardware architectures. Zephyr’s latest release reflects that reality. It is trying to be a serious software base for connected products that span industrial devices, wearables, gateways, research hardware, and low-power edge nodes, all while staying open, portable, and broad in silicon support.

That ambition carries real consequences for the market. Commercial RTOS vendors still have strong positions in safety-critical and deeply entrenched industrial sectors, but open-source platforms are steadily becoming harder to dismiss when they can offer credible security features, maturing tools, and broad board support. Zephyr 4.4 does not settle that argument, and it is not intended to. What it does show is that the project has moved well beyond being a hobbyist curiosity or a lightweight lab platform. It is increasingly shaped like infrastructure — the sort of software layer engineers can build real product roadmaps around, provided they are willing to live inside a faster-moving open-source development model.


Stories for you