Category: wolfBoot

In today’s regulatory environment, implementing a secure bootloader is no longer just a best practice – it’s becoming a compliance mandate. Recent cybersecurity regulations across the globe (from the EU to the US and beyond) explicitly call for measures like secure boot and firmware authenticity verification as requirements for connected devices. In this updated post (building on our earlier discussion of adding wolfBoot to legacy bootloaders), we highlight how upcoming frameworks make secure boot a must-have for compliance, and how wolfBoot’s features directly address these new regulatory requirements.

Table of Contents

• Introduction – Secure Boot as a Compliance Mandate
• EU Cyber Resilience Act: “Secure by Design” with Verified Boot
• U.S. Executive Order 14028 & Federal Initiatives
• UN R155 (Automotive): Cybersecurity and Boot Integrity
• Industrial Controls – IEC 62443 Requirements
• Medical Devices – FDA Cybersecurity Guidance
• Consumer IoT – ETSI EN 303 645 and Other Standards
• wolfBoot Capabilities Mapped to Compliance Needs
• Conclusion – Future-Proofing Legacy Systems

Introduction – Secure Boot as a Compliance Mandate

Just a few years ago, retrofitting a legacy system with a secure bootloader was mainly about proactive security. Now, it’s also about meeting regulations. Laws and standards are emerging which require devices to boot only authenticated firmware and maintain a trusted update process. For example, the EU Cyber Resilience Act (CRA) will mandate that connected products “implement secure boot processes verifying the integrity of software before execution”. Similarly, many U.S. initiatives (from Executive Order 14028 to federal IoT security guidelines) emphasize device integrity through measures like cryptographic signing and secure boot. In short, secure bootloader compliance is becoming essential.

Retrofitting your existing bootloader with a solution like wolfBoot can thus serve a dual purpose: elevating security and ensuring regulatory compliance. Below, we break down major cybersecurity frameworks across industries – each highlighting secure boot or firmware verification – and discuss how wolfBoot helps you conform to these firmware verification regulations.

EU Cyber Resilience Act: “Secure by Design” with Verified Boot

One of the most impactful new regulations is the European Union’s Cyber Resilience Act (CRA). The CRA is a broad law (expected to take effect in 2025–2026) that will require “products with digital elements” sold in the EU to meet stringent cybersecurity criteria. Crucially, secure boot is explicitly mentioned as part of being “secure by design.” The CRA mandates that manufacturers “implement secure boot processes verifying the integrity of software before execution.” This ensures that only trusted, untampered firmware runs on the device. In practice, devices must cryptographically authenticate their firmware at startup – exactly the capability that a secure bootloader like wolfBoot provides.

Other core tenets of the CRA include requiring secure software updates, vulnerability disclosure processes, and default secure configurations. Notably, the Act will enforce “secure by default” settings and the ability to apply updates/patches throughout a product’s lifecycle. Secure boot is the foundation for these measures – without a root of trust at boot, other protections can be bypassed. Manufacturers who fail to implement such controls risk non-compliance once the CRA is in effect.

How wolfBoot helps: wolfBoot was designed to ensure only authenticated firmware can run, aligning perfectly with the CRA’s secure boot requirement. On each boot, wolfBoot uses cryptographic signature verification to check the firmware’s integrity and authenticity before handing over execution. This means your device will “refuse to boot if the integrity checks fail,” as the guidelines demand. Additionally, wolfBoot’s built-in support for secure OTA firmware updates (with signing and version enforcement) satisfies the CRA’s calls for secure update mechanisms. By retrofitting wolfBoot into legacy devices, manufacturers can demonstrate compliance with EU CRA secure boot provisions without a complete redesign of their hardware.

U.S. Executive Order 14028 & Federal Initiatives

In the United States, while there isn’t a single omnibus law for IoT security yet, Executive Order 14028 (2021) – “Improving the Nation’s Cybersecurity” – has set the tone for higher security standards in software and devices. This Executive Order prompted federal agencies and critical infrastructure providers to adopt practices like zero-trust architecture and secure software development. One outcome has been the push for software supply chain integrity, where devices are expected to verify that only approved code runs on them. For example, federal IoT security guidelines (driven by the IoT Cybersecurity Improvement Act of 2020 and NIST recommendations) recommend secure boot functionality to ensure firmware integrity and authenticity. In other words, if you’re selling to U.S. government or critical sectors, features like secure boot and firmware signing are quickly becoming non-negotiable.

While EO 14028 itself focuses on government IT networks, it has cascading effects on IoT and embedded device requirements. The U.S. government is developing an IoT security labeling program (Cyber Trust Mark) and new FAR regulations for federal procurement, which are expected to include device integrity safeguards. Anticipating these, many U.S. device makers are now asking: “Where do we need secure boot, firmware signing, or mutual authentication?” as they navigate growing compliance complexity. In short, firmware verification regulations in the U.S. are largely policy-driven but converging on the same principle: untrusted code must be kept off devices.

How wolfBoot helps: By integrating wolfBoot, device manufacturers can proactively meet the emerging U.S. criteria for secure bootloader compliance. wolfBoot establishes a cryptographic chain of trust from reset vector onward – exactly the kind of defense that U.S. guidelines call for to counter supply chain attacks and firmware tampering. wolfBoot’s minimal footprint and FIPS 140-2 certified cryptography (via wolfCrypt) also ease the path for government use. Essentially, wolfBoot provides out-of-the-box firmware authenticity verification (digital signatures, hashing) that aligns with NIST’s core IoT baseline recommendations and the spirit of EO 14028. So if upcoming rules require attesting that your device “boots only trusted software,” wolfBoot gives you a clear affirmative.

UN R155 (Automotive): Cybersecurity and Boot Integrity

In the automotive world, cybersecurity requirements have been formalized in UNECE UN R155, a regulation that mandates a Cyber Security Management System for vehicle type approval (effective in EU, Japan, etc. from mid-2024). While UN R155 is process-oriented, it is accompanied by UN R156 (for Software Update Management) and heavily informed by the ISO/SAE 21434 standard. Together, these frameworks require automakers to ensure vehicles are protected from software tampering – which inherently includes ensuring only authenticated software can run on ECUs.

Specifically, UN R155 requires manufacturers to implement measures against unauthorized software changes and to verify software updates via cryptography. This means that every Electronic Control Unit in a car should reject code that isn’t properly signed or validated. Secure boot is a key part of meeting this requirement: by establishing a hardware-based root of trust and checking signatures at each stage of the boot chain, the vehicle can guarantee the integrity of its control software. Industry practice now views secure boot and runtime integrity as fundamental for automotive cybersecurity compliance. In fact, ISO 21434 (which UN R155 references) explicitly highlights “establishing trust anchors (Secure Boot) to ensure the integrity of initial boot software” as a best practice for protecting over-the-air updates and in-vehicle networks.

How wolfBoot helps: wolfBoot is well suited to automotive needs, where a verified boot chain and hardware trust integration are paramount. It supports leveraging a TPM 2.0 or HSM as the hardware root of trust, extending device identity into the boot process. For instance, wolfBoot can utilize a TPM’s secure key storage and PCR measurements to implement measured boot on automotive microcontrollers – aligning with UNECE’s expectations for “integrity of software throughout its operational lifecycle”. wolfBoot’s cryptographic verification at each boot stage and features like rollback protection directly address automotive threat scenarios. (UN R155 expects that if an attacker tries to downgrade firmware or inject malicious code, the system will detect it – wolfBoot enforces version checks and will refuse to load unauthorized or downgraded firmware.) Additionally, wolfBoot’s certifiability is a major plus in automotive: it’s designed with MISRA-C compliance in mind and can be delivered in a DO-178C certifiable format for aerospace/avionics use, indicating a rigor that automotive OEMs can leverage for ISO 21434 compliance. In short, retrofitting legacy ECUs with wolfBoot can help meet the stringent UN R155 secure boot expectations without waiting for the next vehicle generation.

Industrial Controls – IEC 62443 Requirements

Industrial and OT (Operational Technology) systems have their own cybersecurity standard: IEC 62443. Within this framework, IEC 62443-4-2 defines security capabilities for embedded devices used in industrial control systems. It explicitly calls for mechanisms to ensure the integrity of firmware and software, especially at boot time. One of the defined requirements is that “Embedded devices shall verify the integrity of the firmware, software, and configuration data needed for the component’s boot and runtime processes prior to use.” This essentially is a mandate for secure boot and secure firmware updates in the industrial context. Another related control in 62443 is to prevent the execution of unauthorized software on the device – again, a direct reference to having a whitelist of signed code.

For an operator of a power plant, factory, or critical infrastructure, this means that PLCs, RTUs, and controllers need cryptographic boot verification to achieve Security Level 2 or higher compliance. We see industry guidance urging use of secure boot in industrial gateways and PLCs as a way to meet 62443 malicious code protection requirements. In practical terms, if you’re upgrading or deploying industrial equipment, adhering to IEC 62443 likely means implementing a chain-of-trust from power-on reset through application launch.

How wolfBoot helps: wolfBoot’s core function – only allowing a trusted firmware image to run – directly satisfies the integrity verification requirement of IEC 62443-4-2. By integrating wolfBoot into a legacy PLC’s boot sequence, you equip it to “verify firmware integrity during boot and block execution if checks fail,” which is exactly what auditors will look for. wolfBoot’s support for a wide range of cryptographic algorithms (ECC, RSA, Ed25519, etc.) is important in industrial settings too, as it can match the algorithm policies of different organizations. Moreover, wolfBoot’s design is OS-agnostic and minimal, meaning it can run on bare-metal controllers with minimal overhead – a crucial factor for real-time industrial devices. It also offers features like dual-bank firmware updates with fail-safe rollback, which help maintain high availability (a failed update can automatically revert to the last known-good image). All these capabilities make it much easier to fulfill the IEC 62443 secure boot and update requirements on legacy industrial systems, bringing them up to par with modern security without a complete redesign.

Medical Devices – FDA Cybersecurity Guidance

Medical devices are another area where regulators are tightening requirements. The U.S. FDA in particular has issued guidance documents (most recently finalized in September 2023) that outline cybersecurity expectations for device makers. The FDA’s “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” guidance calls out the need for authenticity and integrity protections in devices. Manufacturers are expected to implement measures so that only trusted software can run on the device hardware. In fact, the FDA guidance explicitly recommends secure boot mechanisms: devices should “use secure boot mechanisms to ensure that only trusted and authenticated firmware/software is loaded and executed on the device”. It even says the device should validate the integrity of firmware during the boot process and refuse to boot if the check fails. This is a clear endorsement of secure boot as a baseline control for medical device cybersecurity.

Additionally, new U.S. legislation (the PATCH Act provisions in the 2023 omnibus) now requires that medical device premarket submissions include cybersecurity plans. This includes having the capability to “ensure secure and trusted updates and patches” throughout the device life. The FDA expects robust access control, logging, encryption of data, and secure update delivery, but all of those can be undermined if the device’s boot process is insecure. Hence, secure boot and a chain of trust (potentially anchored in hardware) are considered foundational to protect devices that could impact patient safety.

How wolfBoot helps: For medical device manufacturers updating legacy platforms, wolfBoot provides an immediate path to implement the FDA’s recommendations around boot integrity (“secure boot medical device” compliance). wolfBoot can be integrated into the device’s bootloader stage to perform cryptographic signature checks on the firmware image every time the device powers on. This ensures that any tampering (malicious or accidental) is detected and the device won’t run unverified code, addressing the exact use case described in FDA guidance. wolfBoot also supports encrypted firmware images, meaning even if a device’s update package is intercepted, an attacker cannot easily modify it in a way that would still pass signature checks. Another advantage is wolfBoot’s small footprint and minimal attack surface – it doesn’t rely on an OS or heavy runtime, which is ideal for constrained medical implants or devices where additional complexity itself can introduce vulnerabilities. By using wolfBoot’s secure boot and update features, a medical device maker can largely fulfill the FDA’s premarket cybersecurity expectations around software authenticity, and document that the device has a cryptographically verified boot chain from hardware up to the application.

Consumer IoT – ETSI EN 303 645 and Other Standards

For consumer IoT products (smart home, wearables, etc.), one key standard gaining worldwide adoption is ETSI EN 303 645. This European IoT security standard (which influences UK, Australia, and IoT labeling schemes) lays out baseline requirements for consumer devices. Among its provisions, ETSI 303 645 states that “The consumer IoT device should verify its software using secure boot mechanisms.”. It further notes that if an unauthorized change is detected, the device should alert the user and refrain from normal operation. This makes secure boot a recommended practice in the baseline, to ensure that even if malware somehow gets onto a device, it cannot persist after a reboot if it’s not properly signed. While ETSI 303 645 is phrased as “should” (best practice), regulators in the UK (through the Product Security and Telecommunications Infrastructure Act) and others are moving to make such provisions enforceable. In essence, consumer IoT devices are expected to have a mechanism to cryptographically validate firmware – including on initial boot and on updates.

Other industry-specific standards echo this theme. For example, ISO/SAE 21434 (automotive, as discussed) and even some IEEE/UL IoT standards emphasize secure boot. Globally, we see consensus in guidelines like NISTIR 8259 (U.S.) and the Global Semiconductor Alliance (GSA) IoT Security framework: devices must ensure code integrity. Manufacturers who implement secure boot are often able to meet multiple standards at once. As one IoT security report succinctly put it, “Secure boot and rollback protection [are] features [that] some regulations might require… to prevent malicious firmware installs or [firmware] manipulation”. This captures the idea that whether it’s a smart thermostat being certified for IoT security labeling or a new drone needing compliance, secure boot is a common requirement.

How wolfBoot helps: wolfBoot is highly portable and can be used even on small IoT SoCs, making it a practical choice to meet consumer IoT security requirements without heavy overhead. For instance, if you need to comply with ETSI 303 645’s secure boot recommendation, wolfBoot provides the functionality out-of-the-box: it will verify the firmware image’s signature at boot and can be configured to either halt or load a safe fallback image if verification fails. wolfBoot also supports anti-rollback via version numbers – which is a compliance advantage, ensuring that a device can’t be tricked into running an older, vulnerable firmware (this addresses the CRA’s “secure by default” rollback requirement and is generally good for any IoT standard calling for resilience). Additionally, because wolfBoot uses strong cryptography (and even offers post-quantum signature options), manufacturers can confidently claim adherence to “state-of-the-art” crypto practices as required by regulations. Whether it’s a smart camera needing to follow ETSI guidelines or a consumer router aligning to IoT Security Foundation recommendations, wolfBoot’s secure bootloader framework helps tick those compliance boxes. It essentially future-proofs legacy IoT products against the wave of new security standards.

wolfBoot Capabilities Mapped to Compliance Needs

Across all these domains – enterprise, automotive, industrial, medical, consumer – certain secure bootloader capabilities come up repeatedly as necessary for compliance. Here’s how wolfBoot addresses each of these critical requirements:

• Verified Boot Chain & Firmware Authentication: wolfBoot ensures that “only a trusted firmware image can run on the target device,” by using cryptographic signature verification on the firmware at every boot. This directly fulfills regulations demanding firmware integrity validation (CRA, IEC 62443, FDA, etc.). The chain-of-trust can start from a hardware root (e.g., a ROMed public key or TPM) and extends through wolfBoot to your application, providing end-to-end assurance.
• Cryptographic Signing (Modern Algorithms): wolfBoot leverages the wolfCrypt engine, supporting a wide range of algorithms for digital signatures – from ECDSA (secp256r1) and RSA-4096 to ed25519/ed448, and even post-quantum schemes like LMS/XMSS and ML-DSA. This means you can comply with whatever algorithm policies or certificate schemes your industry standard requires (e.g., FIPS-approved algorithms for government, or quantum-resistant keys for long-lived industrial devices). All firmware images are verified using these strong cryptographic checks on every update and boot.
• Anti-Rollback Protection: Many regulations (e.g., CRA and UN R156) require that devices cannot be rolled back to vulnerable firmware without authorization. wolfBoot implements version-based rollback protection – it will reject any firmware image with an older version number than what’s currently installed. This ensures attackers can’t slip a device back to an earlier insecure state. At the same time, wolfBoot offers controlled rollback in case of update failure: it keeps a backup of the last known-good firmware and can restore it if a newly updated firmware isn’t confirmed to be working. This gives the best of both worlds: security against malicious downgrade, and resilience for legitimate recovery.
• Secure Update Mechanisms (OTA support): Virtually all frameworks insist on secure firmware update processes. wolfBoot includes a highly reliable, transport-agnostic update mechanism. It supports firmware encryption in transit and at rest, and can work with various transports (UART, SPI, CAN, network, etc.) to retrieve updates securely. Whether your compliance need is to encrypt updates over-the-air or to use signed update bundles, wolfBoot has built-in tools to accomplish that. This directly maps to requirements in CRA, FDA guidance, and UN R156 that updates be delivered and applied in a secure manner.
• Hardware Root of Trust (TPM/HSM integration): Many regulations and standards favor or require using hardware security to anchor trust (e.g., TPM for secure boot is mentioned in automotive best practices). wolfBoot can integrate with hardware Secure Elements, TPM 2.0 chips, or MCU security features (Arm TrustZone-M, etc.). It supports using a TPM’s keys and PCR registers to validate the boot process, and can offload crypto operations to hardware accelerators. This means wolfBoot can meet certification requirements for a hardware-based root-of-trust, increasing assurance. For example, in an IIoT device you can store the wolfBoot verification public key in OTP or a TPM, and wolfBoot will use that to verify firmware – even if the main flash is compromised, the device won’t boot untrusted code.
• Minimal Attack Surface & High Assurance Implementation: wolfBoot is designed to be simple, compact, and safe. Its codebase is minimalist (focused purely on bootloading and crypto), which reduces potential vulnerabilities (crucial for meeting regulatory expectations of “secure by design”). It does not rely on an OS and has a tiny hardware abstraction layer. This lean design helps in formal certification and audit. In safety-critical industries, wolfBoot can be provided in a DO-178C level certifiable kit (for avionics), indicating the rigor of its development process. For industrial and automotive, its MISRA compliance and static analysis pedigree means it’s easier to validate against standards like ISO 26262 or IEC 61508 if needed. In short, wolfBoot can be described as a “certifiable” secure bootloader solution – as noted in our avionics partnerships, it’s a portable, certifiable bootloader and firmware update solution. This gives confidence when you need to show regulators evidence of software quality and trustworthiness.

By mapping wolfBoot’s features to the requirements set by these various cybersecurity frameworks, it’s clear that a lot of the heavy lifting for compliance is handled. Rather than writing a custom bootloader to meet each new standard, using wolfBoot allows you to leverage a proven secure bootloader that already aligns with best practices in multiple sectors.

Conclusion – Future-Proofing Embedded Systems

The writing is on the wall: secure boot and firmware verification are becoming mandatory across the board – from EU CRA secure boot requirements for consumer products, to automotive type approvals, to medical device approvals and more. What used to be considered a high-end security feature will soon be a baseline expectation under the law. For organizations with large installed bases of legacy devices, this could sound like a daunting challenge: do you need to scrap your existing bootloader or hardware to comply? Thankfully, the answer is no – with solutions like wolfBoot, you can retrofit secure bootloader compliance, even into your legacy systems relatively easily.

In our previous post, we demonstrated how wolfBoot can be used as a library or drop-in component to augment an existing bootloader with cryptographic verification (so you keep your custom update logic or hardware tweaks, but add the security layer). This approach of “retrofitting legacy bootloaders” is now not just about extending device life – it’s about ensuring those devices remain legal to use and sell in the coming years of stricter cybersecurity regulations. wolfBoot’s flexibility (OS-agnostic, multi-platform) means it can be applied to diverse legacy architectures, bringing them up to a compliance level roughly equivalent to a brand new design.

In summary, upcoming regulations are making secure boot not just a good security practice but a compliance checklist item. Implementing wolfBoot in your device can help you check that box with confidence. It provides the verified boot chain, robustness, and even documentation support (test evidence, etc.) to satisfy auditors and regulators. By choosing a trusted secure boot solution like wolfBoot now, you are future-proofing your legacy devices against evolving cybersecurity laws and protecting your customers from the risks of firmware attacks.

Compliance, security, and innovation can go hand-in-hand – retrofitting your legacy bootloaders with wolfBoot is a smart strategy to achieve all three. Feel free to reach out to the wolfSSL team to learn more about wolfBoot’s features (such as TPM integration, post-quantum signing, and safety certifications) and how they map to specific regulations in your industry. As always, we’re here to help ensure that your devices boot securely and comply with the latest cybersecurity requirements.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

We are pleased to announce the release of wolfBoot 2.5.0, the newest version of our universal secure bootloader. This release marks another milestone in the continued evolution of wolfBoot, reinforcing its relevance as a cutting-edge secure boot solution for embedded systems. WolfBoot 2.5.0 brings expanded hardware support, major new features, and a host of improvements to performance and security, all while maintaining the simplicity and robustness our users expect.

New hardware targets and platform enhancements

wolfBoot 2.5.0 expands its hardware compatibility, adding support for several new platforms and improving existing targets. Notable additions and enhancements include:

• New target support: wolfBoot now supports the Raspberry Pi RP2350 microcontroller, NXP’s MCX family (including the MCXA153 and MCXW716 series), and the STMicroelectronics STM32F1 series. These additions extend wolfBoot’s reach from the latest Pi Pico 2 board to NXP’s advanced Cortex-M33 based MCUs and even legacy STM32F1 devices (like the popular “blue-pill” board), demonstrating once again our team’s commitment to maximize device coverage.
• Enhanced support: Existing platform ports have been refined for better stability and performance, notably for the Xilinx UltraScale+ MPSoC (ZynqMP), Renesas RX family, and Infineon AURIX TriCore TC3xx microcontrollers. Developers using ZynqMP devices will benefit from smoother integration (e.g. improved standalone boot support and exception level handling), while updates to the Renesas RX and AURIX TC3xx ports include more efficient flash management and boot-time reliability improvements. These platform enhancements make it easier and more efficient to deploy wolfBoot on a wider range of hardware.

Major new features and enhancements

Version 2.5.0 introduces several important features aimed at both simplifying the developer experience and strengthening security:

• Non-contiguous ELF section support: wolfBoot can now load and verify firmware images with non-contiguous (scattered) ELF sections. In practical terms, this means the bootloader handles images that are split across multiple memory regions, accommodating complex memory maps and multi-part firmware layouts. This feature adds flexibility for projects that utilize segmented flash or RAM areas for their application code and data.
• Streamlined PQC integration: Post-Quantum Cryptography support in wolfBoot has been simplified and updated. WolfBoot 2.5.0 includes the latest PQC algorithm support from wolfCrypt (such as the recently standardized ML-DSA) and makes it easier to configure PQC-based signature verification. By refining the integration of PQC algorithms, we continue to help users prepare for a post-quantum future without sacrificing ease of use.
• Static library build option: In addition to the traditional standalone bootloader binary, wolfBoot can now be built as a static library (libwolfboot.a). This gives developers the flexibility to integrate wolfBoot’s secure boot functionality directly into their applications or custom boot frameworks. The static-lib build simplifies certain use cases — for example, linking wolfBoot into a monolithic firmware image or using wolfBoot features in an RTOS environment — by allowing wolfBoot to be called like a library rather than a separate bootloader image.
• Glitch attack mitigation (IAR toolchain): Security against hardware fault-injection attacks (glitches) has been further hardened in this release. We’ve extended our glitch mitigation techniques to better support the IAR Embedded Workbench toolchain, ensuring that builds compiled with IAR include additional countermeasures against timing and voltage glitch attacks. These low-level improvements make the secure boot process even more resilient to physical attack attempts, protecting the integrity of the firmware verification steps.

Build system and documentation improvements

wolfBoot 2.5.0 comes with numerous build system refinements and documentation updates to streamline development. We have refactored the CMake build system to improve cross-platform support and clarity, making it easier to compile wolfBoot for various targets and toolchains. This includes cleaner integration for IAR and other compilers, as well as a more organized project structure for out-of-the-box builds. Additionally, our documentation has been improved across the board – from updated user manuals and API references to new examples and guides – to help both new and experienced users get the most out of wolfBoot. Whether you’re configuring a multi-slot update scheme or integrating wolfBoot with a TPM, the clearer documentation will guide you through the process more smoothly. (As always, detailed change logs and usage instructions can be found in the README and docs accompanying the release.)

Bug fixes and updated modules

As with every release, wolfBoot 2.5.0 includes key bug fixes that enhance stability and reliability. Various minor issues identified in the previous version have been addressed, resulting in a more robust bootloader across all supported platforms. In particular, fixes were applied to edge cases in flash memory handling and update workflows to ensure consistent behavior in all update scenarios.

Moreover, the cryptographic and secure hardware modules underlying wolfBoot have been updated to their latest versions. wolfBoot 2.5.0 is powered by wolfSSL 5.8.0 – bringing in the newest optimizations and post-quantum enhancements from the wolfCrypt engine – and it can integrate with wolfTPM 3.9.0 for TPM-based secure boot use cases. By using the latest wolfSSL v5.8.0 and wolfTPM v3.9.0 releases, wolfBoot ensures compatibility with the most up-to-date security features and fixes from those libraries. This means developers get improved performance, up-to-date cryptographic algorithms, and continued FIPS 140-3 readiness through wolfCrypt.

wolfBoot’s security is, as always, built on wolfCrypt, which allows the boot process to leverage FIPS-certified crypto and even meet safety standards like DO-178C when required. Upgrading to wolfBoot 2.5.0 brings all these benefits into your secure boot process.

Getting wolfBoot 2.5.0 and support

wolfBoot 2.5.0 is available for download now, and we encourage everyone to try out the new features and improvements. You can find the source code and release package on our GitHub repository and the wolfSSL download page. Documentation for this release, including an updated user manual and examples, is available on our website to help you get started quickly.

If you have any questions about wolfBoot 2.5.0 or need help with integration, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247. The wolfSSL team offers commercial support and consulting services for those who require dedicated assistance or custom features. Whether you are upgrading an existing project or designing a new device with wolfBoot, our team is here to ensure your secure boot implementation is successful.

Download wolfSSL Now

wolfSSL is excited to announce that wolfBoot, our secure bootloader, now supports NXP’s MCX A and MCX W microcontroller families. This means developers can bring wolfBoot’s robust secure boot and firmware update capabilities to NXP’s latest low-power and wireless-enabled chips. The MCX A and MCX W series are NXP’s next-generation Arm Cortex-M33 based MCUs, designed for edge and IoT applications. Some topics we will explore today include:

• Secure boot and firmware authentication
• MCX A and MCX W series support in wolfBoot
• TrustZone-M support: supervising security
• Quantum-resistant cryptography
• Hybrid Dual-signature authentication

The MCX A series delivers a cost-effective, small-footprint MCU solution with autonomous, low-power peripherals for a wide range of industrial and IoT uses?.

The MCX W series, on the other hand, builds on that foundation by adding integrated wireless connectivity – a unified, pin-compatible platform supporting standards like Matter, Thread, Zigbee, and Bluetooth LE.?

Notably, the MCX W devices also incorporate NXP’s EdgeLock secure enclave technology, providing a built-in hardware security core (a hardware root-of-trust) for key storage and cryptography.?

These new MCUs combine efficient performance, ultra-low power operation, and advanced security features, making them an ideal match for wolfBoot’s secure boot capabilities.

With wolfBoot now running on MCX A and MCX W devices, manufacturers and developers using these chips can ensure that only authenticated, trusted firmware runs on their hardware. wolfBoot performs cryptographic signature verification of firmware at boot time, preventing unauthorized or malicious code from taking control of the device. This addition expands wolfBoot’s platform support and underscores our commitment to securing even the most resource-constrained embedded systems.

Coming soon, WolfSSL will further integrate wolfBoot with the TrustZone-M and hardware security features of the MCX family. In practical terms, this upcoming enhancement will allow wolfBoot to act as the TrustZone-M secure supervisor on these microcontrollers – running in the isolated secure world while the main application runs in the non-secure domain. By leveraging TrustZone, wolfBoot can maintain control over critical security resources: for example, cryptographic keys and operations can be confined to the secure domain. wolfBoot uses this isolation to implement a kind of lightweight hypervisor, meaning applications in the non-secure domain can invoke cryptographic functions without ever directly accessing the secret keys?.

This architecture greatly enhances security – even if an application or network-exposed code is compromised, the attacker cannot extract or misuse the most sensitive assets. Additionally, wolfBoot will make use of the MCX hardware root-of-trust capabilities (such as the EdgeLock secure enclave on the MCX W series) to anchor the boot process in silicon. This hardware-based trust anchor will let wolfBoot verify firmware authenticity using keys stored in tamper-resistant memory and even interface with secure key management services?.

The result is an extremely robust secure boot chain that takes full advantage of the MCX series’ built-in security features.

Another key advantage of wolfBoot on NXP MCX is its forward-looking cryptography, which is increasingly important for longevity in IoT products. wolfBoot already supports several post-quantum cryptography (PQC) signature algorithms – the kinds of digital signatures designed to withstand attacks by quantum computers. This includes hash-based signature schemes like LMS (Leighton-Micali Signature) and XMSSML-DSA, the newly standardized module-lattice-based signature algorithm (derived from the CRYSTALS-Dilithium PQC scheme)?.

These algorithms are quantum-resistant, meaning that unlike RSA or ECC, they are not known to be breakable by quantum computing. This is a critical consideration for future-proofing devices: experts warn that a sufficiently powerful quantum computer could one day defeat classical cryptography by solving the mathematical problems underpinning RSA/ECC much faster than a classical computer?.

By adopting PQC signatures, wolfBoot ensures that devices can remain secure even in a post-quantum future where older algorithms might be vulnerable.

What’s more, wolfBoot supports a hybrid dual-signature approach to firmware authentication.

In hybrid mode, each firmware image can be signed with both a traditional algorithm (e.g. ECDSA or RSA) and a post-quantum algorithm (like LMS or Dilithium). wolfBoot will verify both signatures, and it only boots the new firmware if both cryptographic checks pass. This dual-signing strategy provides defense-in-depth during the transition to PQC. Even if one of the signature algorithms were to be compromised (for instance, a future quantum breakthrough against ECC, or an unforeseen weakness in a new PQC scheme), the second signature still stands as a guardrail. Hybrid signatures also help with adoption: they allow new devices to be compatible with existing classical cryptography infrastructure while gradually introducing PQC, offering a graceful migration path?. wolfBoot’s support for hybrid authentication means developers don’t have to choose between today’s standards and tomorrow’s security – they can have both, ensuring firmware updates are secure against both conventional and quantum threats.

By extending wolfBoot to the NXP MCX A and MCX W families, WolfSSL is empowering developers to build the next generation of connected devices with strong confidence in their boot security. These MCUs are built to drive innovation in smart home gadgets, industrial sensors, wearables, and more – and with wolfBoot, each of those devices can boot up safely, verify its software integrity, and even perform field updates securely with minimal overhead. The combination of NXP’s silicon (with its low-power efficiency, wireless connectivity, and built-in security) and wolfBoot’s advanced secure boot features (from TrustZone supervision to post-quantum signatures) offers a powerful platform for long-term, resilient IoT deployments. As support for TrustZone-M and hardware root-of-trust on MCX devices rolls out, wolfBoot will fully harness the security architecture of these chips – essentially acting as a guardian in the secure world that oversees and protects the entire system from reset to runtime. With optional post-quantum and hybrid signature verification, wolfBoot on MCX is not only securing today’s devices but also future-proofing them for the cryptographic challenges of the years ahead.

WolfSSL’s focus remains on providing easy-to-use, strong security solutions for embedded developers. If you are developing on NXP’s MCX microcontrollers or are interested in bolstering your device’s boot security (with features like TrustZone isolation or quantum-resistant crypto), now is a great time to explore wolfBoot. Feel free to reach out to us at facts@wolfSSL.com to learn more, get sample projects for MCX A/W, or discuss how wolfBoot can help secure your next project. We’re excited to see what innovations the community will build on these new NXP platforms – and even more excited that wolfBoot will be there to keep those devices secure from the moment they power on.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

We regularly receive inquiries regarding µITRON support in wolfSSL products—and understandably so.

As a specification for real-time operating systems (RTOS), ITRON has led to a wide variety of implementations. These include open-source projects such as TOPPERS/ASP, as well as commercial RTOS offerings like eT-Kernel (by eSOL), µC3 (by eForce), and NORTi (by MISPO), among many others. In addition, many companies have developed and deployed their own in-house RTOS implementations based on the µITRON specification.

As a result, although these systems are often described as “µITRON-compliant,” in practice they tend to include proprietary extensions or slight modifications. This has given rise to a diverse ecosystem of µITRON derivatives, each with its own unique features.

wolfSSL products are designed to support µITRON, including these many derivative implementations. This includes products such as wolfBoot, which typically require a higher degree of platform-specific integration. The high portability of wolfSSL—including wolfBoot—is the result of extensive experience supporting a broad range of RTOS and general-purpose operating systems, along with carefully localized platform-dependent code.

With commercial-grade technical support backed by wolfSSL’s proven portability technology, customers can confidently integrate wolfSSL products into their µITRON-based systems—regardless of the variant—ensuring robust, secure, and reliable operation.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

We’re thrilled to announce that wolfBoot now supports the powerful Nordic nRF5340 dual-core SoC, bringing enterprise-grade security to your IoT applications. This cutting-edge microcontroller combines robust security features with high performance, making it an ideal choice for modern IoT deployments.

Key Features

• Dual-Core Architecture
  • Application Core:
    • Cortex-M33 at 128MHz with TrustZone
    • 1MB Flash and 512KB RAM
  • Network Core:
    • Cortex-M33 at 64MHz
    • 256KB Flash and 64KB RAM
• wolfBoot Signature Options
  • RSA (2048/3072/4096)
  • ECC (256/384/521)
  • ED25519/ED448
  • PQC: ML-DSA/LMS/XMSS
  • Hybrid PQC schemes
• Hardware based root of trust

Implementation Details

Our reference implementation uses the Nordic nRF5340-DK development kit with external QSPI flash for secure update storage. We’ve also enabled delta (differential) updates to optimize bandwidth usage on constrained networks. Simply enable this feature with DELTA_UPDATES=1.

Communication Setup

The DK board features two virtual COM ports for debugging:

• Application Core: UART0=P0.20
• Network Core: UART0=P1.01

The application core manages network core updates through IPC and shared memory, ensuring seamless coordination between both cores.

Getting Started

For detailed build instructions and example output from an update, visit our documentation.

Important Notes

• Network core updates must be signed with –id 2 and placed in the application core update partition
• Coming soon: Hardware-based root of trust using the UICR key storage region

Testing Tools

We’ve provided helpful testing scripts in our GitHub repository. The build_flash.sh script automates the process of:

• Creating internal and external flash images
• Signing each with version 2
• Placing updates in external flash
• Triggering updates (equivalent to calling wolfBoot_update_trigger())

Support

For questions or assistance, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

With the release of WolfBoot version v2.4.0, we have made significant improvements to our secure boot support for Xilinx UltraScale+ MPSoC systems. This major update brings several key enhancements that make it easier and more efficient to deploy wolfBoot on this target.

UltraScale+ enhancements in wolfBoot v2.4.0

To see the complete list of improvements see wolfBoot PR #499.

1. Standalone build

   The latest release adds support for building without any dependencies from the Vitis/Xilinx SDK. This shift allows developers to bypass traditional SDK-based workflows, making it easier to integrate secure boot into their projects.

2. Expanded Exception Level (EL) Support

   We now support all ARMv8-A exception levels, enhancing security, virtualization, and OS management:

   • Exception Level 3 (EL3) – Trusted Firmware
   • Exception Level 2 (EL2) – Hypervisor
   • Exception Level 1 (EL1) – Operating System
3. Flattened Image Tree (FIT) Format

   We have also introduced support for the FIT format, which combines a Flattened Device Tree (FDT) with embedded binaries. FIT images are widely used in embedded Linux systems, providing a flexible and efficient way to package and deploy software.

4. Enhanced QSPI Bare-Metal Driver

   The latest release includes significant improvements to the QSPI bare-metal driver, enhancing its capabilities for DMA and clock speed configuration. For example using DMA vs IO mode reduced the read of 154MB from 18,228ms to 2,607ms.

5. ARMv8 Crypto Extensions

   wolfBoot now supports the wolfCrypt ARM crypto assembly speedups for SHA2 and SHA3, which greatly improves hashing performance on the integrity checking during boot.

AMD/Xilinx UltraScale+ MPSoC (ZCU102) Features

The AMD/Xilinx Zynq UltraScale+ MPSoC ZCU102 is a powerful evaluation board that provides a platform for system designers to develop and prototype applications:

• Processing System (PS):
  • Quad-core ARM Cortex-A53 (Application Processing Unit – APU)
  • Dual-core ARM Cortex-R5 (Real-time Processing Unit – RPU)
  • ARM Mali-400 MP2 GPU for graphics acceleration
• Programmable Logic (PL):
  • Integrated UltraScale+ FPGA fabric for custom hardware acceleration
  • Supports Partial Reconfiguration (PR)
  • High-performance DSP slices for signal processing applications
• Configuration Security Unit (CSU):
  • The CSU is responsible for secure boot and system configuration.
  • It ensures secure key storage, authentication, and decryption for secure boot processes.
  • Supports Root of Trust (RoT) for secure application execution.
  • Manages bit-stream authentication and encryption for FPGA security.
• Platform Management Unit (PMU):
  • The PMU is a triple-redundant MicroBlaze processor system, ensuring high reliability and fault tolerance.
  • Handles power sequencing, system monitoring, and fault detection.
  • Manages dynamic power and thermal control, optimizing energy efficiency.
  • Provides error handling and recovery mechanisms for mission-critical applications.

Note: The wolfBoot support for using the CSU and hardware based Root of Trust is in development now. You can follow the progress here.

Getting Started

To get started with wolfBoot on your Xilinx UltraScale+ MPSoC system, please refer to the official documentation docs/Targets.md.

The Xilinx hardware uses a First Stage BootLoader (FSBL) and requires assembly of a BOOT.BIN image using bootgen and .bif file. Detailed instructions can be found in IDE/XilinxSDK.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfBoot supports a wide range of NXP QorlQ platforms. In this post, we will highlight supported platforms, key features, and how wolfBoot ensures security and reliability for PowerPC-based embedded systems.

Why wolfBoot for NXP QorIQ?

wolfBoot is a highly suitable secure boot solution for modern embedded systems. wolfBoot is a U-Boot replacement to improve security. wolfBoot supports features like TPM, encrypted updates, external flash partitions, differential updates, and side channel hardening (armored mode). Production support, commercial grade product, safety critical certified DO178 and FIPS 140-3. Its lightweight design, independence from specific platforms, and ease of integration make it a one-stop solution for developers aiming to improve firmware security.

Key advantages:

• Efficient and Lightweight: Perfect for resource-constrained environments.
• Broad Compatibility: Supports PowerPC and Arm-based platforms.
• Flexible Integration: Simplifies secure firmware updates and key management.

Supported NXP QorIQ PPC Platforms

LS1028A

• Overview: ARMv8-A architecture with dual Cortex-A72 cores for industrial and networking applications.
• Features: Integrated TSN (Time-Sensitive Networking), high-speed I/O, and robust peripheral support.
• Tested Environment: LS1028ARDB Reference Board.

T1024

• Overview: Dual-core 64-bit PowerPC processor based on the e5500 core, designed for embedded control and communication.
• Features: Virtualization, encryption acceleration, and advanced networking capabilities.
• Applications: Secure gateways, industrial automation, and telecom systems.
• Tested Environment: T1024RDB with NOR flash using IFC.

T2080

• Overview: High-performance quad-core 64-bit processor using the e6500 core with AltiVec technology for vector processing.
• Features: Exceptional performance for data-intensive workloads and advanced signal processing.
• Tested Environment: NAII 68PPC2 hardware.

P1021

• Overview: A dual-core PPC e500v2 processor.
• Features: Optimized for secure boot from NAND flash via eLBC (Enhanced Local Bus Controller).
• Boot Details: Supports first-stage boot loader and execution of wolfBoot for secure firmware validation and application loading.
• Applications: Ideal for industrial controllers and embedded systems requiring high reliability.
• Tested Environment: P1021RDB with NAND boot source using eLBC

How wolfBoot Secures NXP QorIQ Systems

wolfBoot ensures safe and trusted execution of firmware with:

• Secure Boot: Prevents unauthorized firmware from running.
• Signed Updates: Employs ECC/RSA cryptography for firmware authenticity.
• Customizable Configurations: Provides example setups for easier implementation across platforms.

Conclusion

Whether you’re working on NXP QorIQ PowerPC platforms or other architectures, wolfBoot is designed to deliver the best security and support. Its compatibility with wide ranges of different processors makes it essential for secure embedded systems development.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfBoot 2.3.0 has finally been released! The universal secure bootloader extends its support to new platforms, improves existing ports, and introduces new groundbreaking features that set the pace to defining secure-boot for the next generation of embedded systems.

A New Era of Secure Boot with ML-DSA and Hybrid Authentication

The introduction of quantum resistant algorithms in the latest releases of wolfSSL has accelerated the integration of asymmetric cryptography in our secure boot solution. In 2023, wolfBoot v2.0.0 expanded its signature verification algorithms to include the hash-based stateful signatures LMS (+HSS) and XMSS (^MT). wolfBoot v2.3.0 further extends these options by introducing ML-DSA, as specified in FIPS-204, for verifying the authenticity of firmware and other critical components. Support for ML-DSA in wolfBoot is currently available in three variants: ML-DSA-44, ML-DSA-65 and ML-DSA-87, corresponding to NIST security category 2, 3 and 5, respectively.

Hybrid Authentication: Post-Quantum Meets Classic Cryptography

One of the most anticipated features in WolfBoot 2.3.0 is its support for hybrid authentication, a method that combines Post-Quantum Cryptography (PQC) algorithms with traditional cryptographic techniques like ECC and RSA. This hybrid approach strengthens security by combining the resilience of PQC, which resists quantum attacks, with the well-established reliability of classic algorithms. Pairing PQC algorithms with ECC521 offers a path toward CNSA 2.0 compliance, a set of guidelines for systems demanding the highest levels of security.

Hybrid authentication in WolfBoot secures the boot process by signing and validating boot images with a combination of PQC and traditional cryptography. This dual-layer protection approach ensures that even if one algorithm becomes vulnerable, the other remains resilient, offering a future-proof strategy for embedded systems as quantum computing capabilities grow.

Boot time optimization and performance monitoring

Thanks to the newly introduced assembly optimization for ARM in wolfCrypt, image verification times have been dramatically reduced. These ARM optimizations are now enabled by default on all Cortex-M devices.
New benchmark tools have been added to our continuous integration environment, to ensure that we can constantly monitor boot time, footprint size, runtime memory usage and other performance indicators.

Improved keystore and keyvault management

Starting with wolfBoot 2.3.0, it is now possible to store public keys of different sizes in the same trust anchor. This is a crucial feature to allow double signature verification in hybrid mode, or when integrating heterogeneous components in the boot chain, involving more than one cipher at a time.

PKCS11 key vault storage drivers have also been improved, and can now reliably store keys in non-volatile memories, ensuring compatibility with wolfPKCS11.

Hardware support

In this version, the following new targets have been added to the list of hardware platforms we support:

• Infineon AURIX TriCore TC3xx
• Microchip AT-SAMA5D3
• Nordic nRF5340

Moreover, the support for some of the existing ports has been improved and stabilized. During the development of wolfBoot v. 2.3.0 we mostly worked on the following targets:

• NXP i.MX-RT family: the capabilities have been extended, including the support for built-in High-Assurance Boot (HAB) mechanism, provided by the manufacturer. Flash interaction has improved, and DCACHE invalidation has been fine-tuned to increase performance
• Renesas RX: improvements introduced for this family of microcontrollers include the introduction of a full-flash erase operation, a more efficient flash management and support for boot-time IRQ.
• Raspberry Pi: added UART driver

Find out more about wolfBoot

Join our webinar “What’s new in wolfBoot” on November 21, 2024 to discover more details about wolfBoot 2.3.0 and our real-life scenarios for post-quantum cryptography adoption.

If you want to share your secure-boot experience with us or ask us anything on this topic, reach out via email at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now