Every embedded device starts by executing software stored in non-volatile memory. Before the application, operation system or FPGA configuration can run, the system must answer one fundamental question:
For connected embedded products, this question has become important. The boot process is increasingly targeted by attackers because it provides an opportunity to replace legitimate firmware before higher-level security mechanisms become active. Once malicious software is executed, it can persist across reboots, bypass security controls, extract confidential data or install persistent malware.
Secure boot addresses this challenge by ensuring that every executable component is authenticated before execution begins. It establishes a cryptographic chain of trust that starts with immutable hardware and extends through the complete software stack.
For most modern embedded products, the answer is yes. Secure boot is widely regarded as the state-of-the-art technical solution for ensuring software integrity. It establishes trust from the very first instruction executed after power-up and prevents unauthorized firmware from running on the device.
Also from a regulatory perspective, the Cyber Resilience Act (CRA) requires manufacturers to protect software against unauthorized modification throughout the product lifecycle. Annex I specifically requires measures that preserve the integrity of software and prevent unauthorized manipulation. The BSI Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products (REC_ER 7.1) provides one important indication. It recommends software integrity verification particularly for products that store sensitive user or system data.
In practice, this leaves only a few narrow exceptions:
Firmware cannot be modified: If firmware is stored in immutable memory and cannot be modified after manufacturing, Secure boot provides little additional value. This is a rare scenario, as most FPGA and embedded systems require firmware or bitstream updates throughout their lifetime.
The product stores no sensitive data: Another possible exception applies to simple products that do not store sensitive data or security-critical assets and whose compromise would have only limited consequences.
Make sure only trusted firmware, FPGA bitstreams and updates run on your device. We help you to design and implement this chain of trust from reset to authenticated firmware deployment.
Secure boot ensures that an embedded system only executes trusted software. Before any firmware, bootloader or operating system is allowed to run, its authenticity and integrity are verified using cryptographic techniques. If verification fails, the boot process is halted or the device enters a secure recovery mode, preventing unauthorized code from executing. Many embedded platforms additionally support firmware or bitstream encryption to protect confidentiality.
Every Secure boot implementation starts with an immutable Hardware Root of Trust (HRoT). This is the first trusted component in the system and cannot be modified after manufacturing. Because it is immutable, the HRoT provides the foundation for all subsequent trust decisions. If this first stage cannot be trusted, the entire secure boot architecture becomes ineffective.
On many MCUs, the HRoT consists of a Boot ROM together with a public key or public key hash stored in protected hardware such as OTP memory or eFuses. FPGA and SoC FPGA platforms follow the same principle, although the Root of Trust may also involve secure configuration logic or dedicated security hardware.
Before firmware is released, it is digitally signed using the manufacturer's private signing key. The signature is distributed together with the firmware image, while the corresponding public key is securely provisioned onto the target device. During startup, the device verifies the signature using this public key before execution continues.
In many production systems, manufacturers use a hierarchy of signing keys. A long-term root key establishes the device's trust anchor, while operational signing keys are used to sign firmware releases. This architecture simplifies key rotation and allows compromised signing keys to be revoked without replacing the device's HRoT.
Signature verification confirms two essential security properties:
Unlike CRCs or simple hash comparisons, digital signatures protect against intentional manipulation because an attacker cannot generate a valid signature without the manufacturer's private signing key.
Once the first bootloader has been authenticated, it verifies the next software component before execution continues. Every verified stage becomes responsible for authenticating the following stage until the complete software stack has been validated. During firmware updates, the same verification process ensures that only authenticated software is installed, preventing unauthorized or malicious updates.
The chain of trust is only as strong as its weakest link. Every executable component capable of influencing system startup should therefore become part of the verification process.
Secure boot is often confused with firmware or bitstream encryption. Although both mechanisms are complementary, they solve different security problems.
Authentication ensures that software originates from a trusted source and has not been modified. Encryption protects the confidentiality of firmware and prevents attackers from reading proprietary code or sensitive algorithms.
Modern embedded platforms frequently support both mechanisms. However, authentication forms the foundation of Secure boot because encrypted software can still be malicious if its origin has not been verified.
While the exact implementation depends on the target platform, most secure boot architectures follow the same chain of trust.
This sequential verification process establishes the chain of trust, ensuring that every software component originates from a trusted source and has not been modified since it was signed.
Modern embedded platforms provide numerous security primitives, including Boot ROMs, OTP memory, cryptographic accelerators, secure key storage and, on many FPGA families, bitstream authentication and encryption. These hardware features establish the foundation of trust but they do not automatically create a complete secure boot implementation. A production-ready architecture combines these hardware capabilities into a complete chain of trust that protects the device throughout its entire lifecycle. Typical architectural building blocks include:
The exact implementation depends on the target platform, but the underlying security principles remain the same.
On MCU-based systems, the immutable Boot ROM typically serves as the HRoT. Developers then implement the bootloader hierarchy, firmware authentication, secure update mechanism and recovery strategy. On ARM-based devices, TrustZone can additionally isolate security-critical services and cryptographic keys from the main application.
On FPGA-based systems, the first step is protecting the hardware configuration itself. Bitstream authentication ensures that only trusted FPGA configurations are loaded, while bitstream encryption protects the design stored in external memory. These mechanisms only protect the FPGA configuration. If the design includes, for example, a soft processor or an embedded operating system, an additional secure boot chain is required to authenticate every software component before execution.
SoC FPGAs combine both worlds providing an integrated SoC processing system and programming logic. In addition to verifying the FPGA bitstream, developers must also establish a chain of trust for the bootloader, operating system and application software. Multi-stage bootloaders are commonly used because they separate the immutable Root of Trust from more flexible software components, allowing secure firmware updates while maintaining system integrity.
When implementing secure boot, several design pitfalls occur repeatedly:
Ultimately, a secure boot implementation is only as strong as its weakest link. Every executable component capable of influencing system startup should become part of the chain of trust.
The Efinix Titanium platform provides the flexibility to build application-specific Secure Boot architectures. Rather than delivering a fixed Secure Boot framework, it provides the foundation on which developers can implement their own chain of trust.
KiviCore extends these platform capabilities through a modular Secure Boot architecture based on KiviNanoBL and KiviBL. KiviNanoBL establishes the initial Root of Trust by verifying and decrypting the second-stage bootloader. KiviBL then authenticates and, if required, decrypts the application firmware before execution begins. The same verification process is applied during firmware updates, ensuring that only trusted software becomes part of the running system.
Depending on application requirements, the solution can be deployed as:
Building a Secure Boot architecture involves much more than enabling a security feature in your FPGA or MCU. It requires a complete chain of trust, from the Hardware Root of Trust and bootloader to firmware authentication, secure updates and rollback protection.
Explore how the KiviCore Secure Boot & Secure Updates Package helps embedded product teams design and implement production-ready Secure Boot architectures for FPGA, SoC FPGA, ASIC and MCU-based systems.