# What to expect in Zephyr 4.5

Zephyr 4.5 is due in the last week of October 2026, and it is the last release before the next LTS. What is new, what will need changes in your project, and how to get ready.

- Author: Michael Mikus (https://mikus.io/about/)
- Published: 2026-09-22
- Updated: 2026-09-30
- Category: Engineering
- Web page: https://mikus.io/blog/zephyr-4-5-what-to-expect/

> The idea: Zephyr 4.5 adds a new architecture, a video and multimedia stack and a native LoRaWAN backend, but its bigger job is being the last release before LTS4. Test against it now, while breakage is still cheap to find.

Zephyr 4.5 is scheduled for the week of 26 October 2026. Feature freeze is due in the week of 28 September, so the feature set is close to final. Everything below comes from the working drafts of the [release notes](https://docs.zephyrproject.org/latest/releases/release-notes-4.5.html) and [migration guide](https://docs.zephyrproject.org/latest/releases/migration-guide-4.5.html) in the Zephyr repository, as of 30 September. Details can still change before the release.

## When it lands, and why this one matters

| Milestone                      | Week of           |
| ------------------------------ | ----------------- |
| Feature freeze (RC1)           | 28 September 2026 |
| Second release candidate (RC2) | 12 October 2026   |
| Hard freeze (RC3)              | 19 October 2026   |
| Release                        | 26 October 2026   |

The dates come from the project's [release schedule](https://github.com/zephyrproject-rtos/zephyr/wiki/Release-Management) and are tentative.

Zephyr now ships on a fixed six-month cadence, in April and October. That makes 4.5 the last release before LTS4, planned as Zephyr 4.6 in April 2027. If you plan to move to the LTS, testing 4.5 now spreads the migration work over two releases instead of meeting all of it at once in April. It also matters if you are still on 4.3: its support ends on 15 October 2026, before 4.5 ships.

## What's new

- **A new architecture.** Zephyr now supports Infineon TriCore, the architecture behind Infineon's AURIX microcontrollers.
- **Video and multimedia.** Video gets a proper subsystem API, taking over the functions that used to live in the video drivers. Applications only need to change the include, to `<zephyr/video/video.h>`. A new Multimedia Pipeline lets an application describe a media flow as sources, transforms and sinks, instead of driving each audio, video or display device itself.
- **Clock monitoring.** A new Clock Monitor driver class observes clock frequency at run time.
- **An automotive bus and precision timing.** A new LIN driver class covers the Local Interconnect Network bus used in vehicles, and a new precision timing subsystem gives drivers shared helpers for checked time arithmetic, clock operations and PI (proportional-integral) control.
- **A native LoRaWAN stack.** A new backend implements LoRaWAN 1.0.x Class A directly on the LoRa radio driver, without the Semtech LoRaMac-node dependency. It supports only the EU868 region for now. If you try it, call runtime settings such as `lorawan_set_datarate()` and `lorawan_enable_adr()` after `lorawan_start()`; earlier calls are refused or dropped.
- **CPU affinity on every scheduler.** `CONFIG_SCHED_CPU_MASK` no longer requires `SCHED_SIMPLE`, so SMP projects can pin threads while using the scalable or multi-queue scheduler.
- **Device classes in devicetree.** A binding can declare a `class:`, and code can enumerate every enabled node of that class at build time with macros such as `DT_FOREACH_CLASS_STATUS_OKAY`. The ADC and I3C shells already use it, so they now find out-of-tree drivers too.
- **Security stack updates.** Mbed TLS moves to 4.1.1, TF-PSA-Crypto to 1.1.1 and TF-M to 2.3.1, which can now be built with LLVM. A new dispatch hook lets TF-PSA-Crypto route operations to a hardware accelerator, and MCUboot can embed several signing keys, so a development bootloader can boot both development- and production-signed images.

The draft also lists 130 new boards so far, and two CVEs addressed in this release, CVE-2026-8718 and CVE-2026-9263.

## What will need changes

The migration guide is long. These are the items most likely to reach an ordinary application:

- **CMake 3.28 is now the minimum.** Ubuntu 24.04 ships 3.28.3. On Ubuntu 22.04, get a newer CMake from the Kitware APT repository or with `pip install cmake`.
- **C17 is now the minimum C standard.** `CONFIG_STD_C11`, `CONFIG_STD_C99` and `CONFIG_STD_C90` were removed, so a project that pins one of them fails at build time. Remove the option and build with C17 or newer.
- **Generated headers need the `zephyr/` prefix.** Write `#include <zephyr/version.h>`, not `<version.h>`. The legacy include path that allowed the short form, `CONFIG_LEGACY_GENERATED_INCLUDE_PATH`, is deprecated and now off by default.
- **The ring buffer API changed.** The zero-copy claim and finish calls give way to `ring_buf_put_ptr()` and `ring_buf_get_ptr()`. Code still using the old calls or the item API fails to compile without a helpful message. Enabling `CONFIG_RING_BUFFER` brings the legacy API back while you migrate. Also, `ring_buf_get()` no longer takes a NULL buffer to throw data away, unless `CONFIG_RING_BUFFER` is enabled; use `ring_buf_consume()` for that.
- **`ninja flash` and friends are gone.** The CMake `flash`, `debug`, `debugserver`, `attach` and `rtt` targets were removed. Use the `west` equivalents. The `run` and `debugserver` targets for emulators such as QEMU still work.
- **Two kernel behaviours changed.** `k_sem_reset()` no longer wakes threads polling on the semaphore, and `CONFIG_SMP_BOOT_DELAY` is replaced by a per-CPU `zephyr,deferred-start` flag in devicetree.
- **Some Bluetooth callbacks run in another thread.** Some host callbacks, such as `disconnected()`, now run in the Bluetooth RX thread instead of the system workqueue. Check your locking and `CONFIG_BT_RX_STACK_SIZE`.
- **Old Mbed TLS options are gone.** Deprecated Kconfig names such as `CONFIG_MBEDTLS_TLS_VERSION_1_2` were removed. Use the names that match Mbed TLS's own settings, here `CONFIG_MBEDTLS_SSL_PROTO_TLS1_2`. Unlike the old ones, they do not enable their dependencies for you.
- **Espressif boards get signed, revertible images by default.** Sysbuild now builds MCUboot with swap using offset and RSA-2048 signatures, using MCUboot's development key unless you set your own. The new bootloader rejects unsigned images, so flash the bootloader and the application together when you move a device over. Swap using scratch is no longer available on boards that use Espressif's shared partition tables, unless a board overlay adds the scratch partition back.

Board maintainers should check three more things. Revision fragments named `<board>_<revision>.conf` are no longer read, so rename them to `<board>_<revision>_defconfig`. NXP's devicetree include files for LPC, Kinetis, MCX and i.MX RT have moved into per-series folders, which breaks out-of-tree board includes. And Espressif's per-module devicetree files are gone: an out-of-tree Espressif board now includes the plain SoC file and describes its own flash.

## How to get ready

Build your project against `main` now, or against RC1 once it is tagged, and read the deprecation warnings. Most of the changes above fail loudly: at build time or, for the Espressif bootloader, at first boot. Three do not: `k_sem_reset()` used together with `k_poll()`, `ring_buf_get()` called with a NULL buffer in the default build, and the Bluetooth callbacks that changed threads. Check those by hand.

Then read the migration guide for the subsystems you actually use. It is organised by area, so you rarely need the whole thing.

## Sources

- [Zephyr 4.5 release notes, working draft](https://docs.zephyrproject.org/latest/releases/release-notes-4.5.html)
- [Migration guide to Zephyr 4.5, working draft](https://docs.zephyrproject.org/latest/releases/migration-guide-4.5.html)
- [Zephyr release schedule](https://github.com/zephyrproject-rtos/zephyr/wiki/Release-Management)
- [Zephyr releases and LTS policy](https://docs.zephyrproject.org/latest/releases/index.html)

_Zephyr® is a registered trademark of The Linux Foundation. This post is independent and not endorsed by the Zephyr Project._
