Meeting Secure Boot Compliance Requirements

    • 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

    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