The wolfSSL team is pleased to announce the release of wolfBoot 2.7.0, the latest version of our portable secure bootloader for embedded systems. This release focuses on three main areas:
Expanding hardware coverage to radiation-hardened platforms
Unifying and hardening TrustZone-M and dual-bank update flows
Making update state tracking and integration easier with filesystem and MTD-backed helpers
As always, the full changelog is available in the wolfBoot repository and on the github v2.7.0 release page.
_________________________________________________________________________________________________________
New Platform Support
Vorago VA416x0: Secure Boot in Radiation-Hardened Systems
See also our recent blog post about it
wolfBoot 2.7.0 adds full support for Vorago’s VA416x0 series (VA41620 / VA41630), bringing our secure boot and firmware update flow to radiation-hardened Cortex-M4 microcontrollers.
The new port includes:
A dedicated HAL implementation (hal/va416x0.c) integrated with the Vorago SDK
Example configuration (config/examples/vorago_va416x0.config) with ECC384/SHA384 as the default signing and hashing combination
Test application and factory image helpers that build wolfBoot, the test firmware, sign it, and assemble a flashable image for VA416x0 boards
On these devices, wolfBoot leverages the external SPI FRAM configuration and the board’s radiation-tolerant design to provide a robust secure boot chain for space and high-reliability applications, where authenticated updates and rollback-safe behavior are essential.
Nordic nRF5340 with TrustZone-M
Support for the Nordic nRF5340 dual-core SoC was introduced in earlier wolfBoot releases; version 2.7.0 extends this further with a dedicated TrustZone build and configuration for the application core.
Highlights include:
TrustZone-aware build options for the nRF5340 application core (Cortex-M33 with TrustZone)
Improved configuration for pairing secure and non-secure firmware images in a wolfBoot managed update flow
Combined with wolfBoot’s existing support for ML-DSA, LMS/XMSS, and hybrid authentication, this makes the nRF5340 a strong platform for post-quantum aware secure boot in IoT and wireless devices.
_________________________________________________________________________________________________________
Unified TrustZone-M and Dual-Bank Behavior
In 2.7.0, we’ve taken another step in making TrustZone-M support consistent across all ARMv8-M targets:
Unified TrustZone-M handling across supported ARMv8-M platforms, so you get the same high-level behavior on devices like STM32H5, RP2350, nRF5340, and others.
A TrustZone-aware dual-bank configuration, where redundant-slot updates respect secure/non-secure boundaries and provide better isolation between the running image and the candidate update.
For STM32H5 specifically, wolfBoot 2.7.0 brings:
An improved SPI driver path
Integration of TPM-based secure storage with updated TrustZone Non-Secure Callable (NSC) APIs
Multiple fixes for dual-bank and TPM-enabled builds to make them more predictable and robust during updates
The simulator target has also been updated with dual-bank flow and a new bank-swap test script, so you can validate redundant-slot update scenarios and rollback logic without touching hardware. Adding features to the simulated platform allows us to test more scenarios in CI.
On the RP2350 (Raspberry Pi Pico 2), wolfBoot now uses a RAM cache for flash writes, increasing robustness against partial writes and power faults during updates.
For Infineon AURIX TC3xx, we’ve moved away from an IDE-centric example to a cleaner HAL module integration, fixing UART and boot-flag handling along the way. This brings the TriCore port in line with other wolfBoot HAL-based targets.
_________________________________________________________________________________________________________
Filesystem-Backed and MTD-Backed Update State Management
A key theme in 2.7.0 is better visibility and control over boot partition state, especially when integrating wolfBoot into larger systems and CI pipelines.
library_fs target and CLI tools
wolfBoot now exposes filesystem-backed partition state access via the new library_fs target and a companion CLI application often referred to as lib-fs.
With this setup, you can:
Build libwolfboot as a library with a backend that maps partitions onto regular files
Use the CLI to query boot partitions, inspect active/inactive slots, and track which image is pending or confirmed
Trigger update operations and simulate swaps without hardware, which is ideal for automated testing and offline integration flows
This is particularly useful when you want to exercise wolfBoot’s state machine and update logic in a host-driven environment, for example, in a CI job that signs images and verifies that rollback and confirmation flows behave as expected.
MTD-backed update status in libwolfboot
For systems that use libwolfboot inside an OS and rely on raw flash / MTD devices, 2.7.0 introduces MTD-backed tracking of update status.
At a high level, this allows libwolfboot to:
Store update state directly on MTD-backed partitions, so progress and status survive resets
Integrate with standard MTD layers often found in Linux and RTOS-based designs (e.g. raw NOR/NAND layouts)
This makes it easier to build robust OTA flows where the application or an update agent interacts with libwolfboot to coordinate staged images and confirmation logic on raw flash devices.
_________________________________________________________________________________________________________
Build System, Tools, and Configuration Improvements
CMake presets and out-of-tree builds
Continuing the build system work from previous releases, wolfBoot 2.7.0 adds CMake presets, improves list handling, and further stabilizes out-of-tree builds, particularly for multi-target configurations.
The goal here is straightforward: make it easier for teams to:
Maintain a single CMake-based project that targets multiple boards or SoCs
Keep a clean source tree by building in separate directories
Automate builds in CI with reproducible preset configurations
Key tools and post-quantum test coverage
The key generation and signing tools have also been refined:
keygen --no-overwrite lets you protect existing key material by refusing to overwrite files, a small but important safety feature in production build pipelines.
Stricter checks on image header and sector size help catch misconfigurations earlier in the build process instead of at boot time.
Expanded ML-DSA test configurations improve coverage for post-quantum signatures, building on the PQC support introduced in earlier wolfBoot releases (ML-DSA, LMS, XMSS, and hybrids).
WOLFBOOT_RESTORE_CLOCK configuration
A new configuration option, WOLFBOOT_RESTORE_CLOCK, gives integrators more fine-grained control over clock behavior around the boot process. When enabled, the HAL can explicitly restore or adjust system clocks as part of its wake-up/exit path, improving compatibility with platforms that expect a particular clock tree configuration before the application starts.
This is especially useful on STM32 and Nordic devices where the clock configuration during boot ROM execution might differ from what the application expects.
_________________________________________________________________________________________________________
Security and Reliability Fixes
As usual, 2.7.0 includes important hardening and bug fixes across the code base:
Encrypted and delta updates
Additional protection against IV reuse in encrypted update flows
Fallback and regression fixes
Expanded unit test coverage around encrypted and delta path handling
Flash and STM32 improvements
Fixed SPI flash protocol edge cases and strengthened write verification
Corrected STM32 internal flash page erase masks
Multiple fixes in STM32H5 update paths, including dual-bank and TPM-enabled builds
PowerPC / NXP P1021
Resolved stage1 and MMU build issues to keep the PowerPC port aligned with modern toolchains
Warning cleanup and quality-of-life improvements
Cleanup of compiler warnings across several targets, including STM32WB55 PKA and non-TrustZone nRF5340 builds
These changes improve reliability across a wide range of configurations and reduce friction when enabling more advanced features like dual-bank updates, encrypted delivery, and TPM-based boot flows.
_________________________________________________________________________________________________________
Updated Module Versions
wolfBoot 2.7.0 aligns with the latest wolfSSL ecosystem components, pulling in updated versions of the underlying crypto and HSM libraries:
wolfSSL: v5.8.4-stable (59f4fa568)
wolfTPM: v2.4.0-594-g6d5df60
wolfPKCS11: v2.0.0-stable-33-g81af264
wolfHSM: v1.3.0 (8ac56d7)
By being in sync with the latest version of the components, wolfBoot benefits from the latest performance optimizations, algorithm updates, and security fixes shipped in the wolfSSL family.
_________________________________________________________________________________________________________
Getting wolfBoot 2.7.0 and Next Steps
wolfBoot 2.7.0 is available today:
Download the release package from the wolfSSL download page (select wolfBoot 2.7.0).
Clone the latest tag from the wolfBoot GitHub repository for direct source access and integration.
Refer to the updated documentation and docs/lib.md for details on the library/library_fs targets, libwolfboot integration, and example flows.
If you’d like help integrating wolfBoot 2.7.0 with your platform—whether it’s a Vorago VA416x0 design, a TrustZone-enabled MCU like nRF5340 or STM32H5, or an architecture such as PowerPC or x86—reach out to the wolfSSL team at facts@wolfssl.com. We’re happy to assist with design reviews, custom ports, and compliance-driven secure boot deployments.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call +1 425 245 8247.
Download wolfSSL Now