Why FPGAs Demand a Different Trust Model

Field-programmable gate arrays power everything from advanced driver-assistance systems and satellite payloads to 5G infrastructure and industrial control loops. In these environments, a single rogue firmware image can corrupt safety functions, exfiltrate secrets, or turn a trusted node into a vector for lateral movement. The twin disciplines of secure boot and cryptographically validated firmware updates are no longer optional extras—they are the foundation of a trustworthy FPGA lifecycle. This article explores the architectural principles, threat models, and implementation patterns that engineers can apply to lock down FPGA bitstreams and keep devices resilient across their operational lives.

Unlike a hardened microcontroller, an FPGA does not execute instructions from a fixed ROM mask. It loads configuration data—often called a bitstream—that defines the hardware fabric itself. A tampered bitstream can instantiate covert logic, bypass memory protections, or subvert sensor readings without altering a single line of application code. Because the bitstream sits below the operating system layer, it enjoys a privileged position in the stack, making compromise exceptionally difficult to detect.

Several industry trends make robust bitstream protection critical. First, FPGA densities now exceed a million logic elements, running complex processor subsystems, encryption accelerators, and AI inference pipelines on the same die. Second, supply chain globalization means devices may be provisioned at contract manufacturers where physical access is uncontrolled. Third, after deployment, over-the-air update mechanisms turn every network interface into a potential attack surface. In this context, secure boot guarantees that the device starts from a known-good state, while authenticated updates prevent an adversary from seeding malicious firmware mid-lifecycle.

Threat Landscape for FPGA Devices

Understanding the adversary’s goals sharpens the design of countermeasures. Threats fall broadly into three categories: fabrication-time interference, pre-boot manipulation, and run-time substitution.

  • Supply chain injection: Adversaries replace or modify the flash memory that holds the boot bitstream, either during board assembly or while the device is in transit. A signed boot image thwarts this by failing authentication before the FPGA configures its logic.
  • Side-channel extraction: An attacker measures power or electromagnetic emanations to recover decryption keys. Modern FPGAs integrate physically unclonable functions (PUFs) and hardened key storage that never exposes plaintext keys to software, sharply reducing this attack surface.
  • Malware-induced reconfiguration: Once a processor running on the FPGA has been compromised, an attacker may attempt to push a new bitstream via the internal configuration port. Access controls and run-time bitstream authentication can lock down the configuration engine even when the processor itself has been breached.
  • Downgrade attacks: A valid but outdated firmware image with known vulnerabilities is re-flashed. Secure update protocols must track version metadata and enforce anti-rollback counters.
  • JTAG and debug interface abuse: Debug ports left active in production provide a direct path to read or overwrite configuration memory. Hardening these interfaces with fuse-controlled lock bits or requiring signed unlock sequences is essential.

A properly architected secure boot chain addresses each of these vectors by checking authenticity at every stage: first boot image, subsequent firmware volumes, and any late-load overlay or partial reconfiguration region.

Foundations of Secure Boot on FPGAs

Secure boot on an FPGA verifies that the configuration bitstream loaded at power-on originated from a trusted source and has not been altered. The verification chain rests on three pillars: cryptographic signatures, a hardware root of trust, and a tamper-evident boot flow.

1. Cryptographic Signatures and Key Hierarchy

A typical scheme uses public-key cryptography. The manufacturer or system integrator holds a private key that signs the golden bitstream. The corresponding public key, embedded in one-time programmable eFuses or battery-backed registers, acts as the root of trust. During boot, a hard IP core reads the signature appended to the bitstream, recomputes the hash, and verifies the signature against the stored public key. If the check fails, the FPGA can fall back to a known-good image, lock the configuration interface, or assert a system reset.

To limit damage from a key compromise, many designs adopt a two-tier key hierarchy: a primary root key that signs secondary keys, which in turn sign the actual application bitstreams. This allows rotating application keys without re-burning eFuses, an operation that is often one-time in nature. For fleets spanning multiple deployment sites, a tiered scheme also enables regional or customer-specific signing keys that limit the blast radius of a single key leak.

2. Hardware Root of Trust

A hardened security block inside the FPGA provides an immutable starting point. For example, Xilinx devices incorporate a Device DNA and eFuse area that can store a hash digest or public key hash. Intel Agilex and Stratix 10 families integrate an Secure Device Manager (SDM) that acts as a coprocessor for boot authentication. These hardened blocks read the external flash via an authenticated command sequence, so even if an attacker swaps the flash chip, the FPGA will not accept the bitstream.

When the FPGA lacks a full-featured security block, engineers can pair it with an external secure element—such as a Microchip ATECC608 or a TPM—that stores keys and performs signature verification. The external IC communicates over an I²C or SPI interface, and the FPGA configures itself only after receiving a “verified” signal. This approach adds component cost but is a common retrofit for earlier FPGA families. Newer devices from Lattice Semiconductor, such as the MachXO3D, embed a similar hardened security block that includes on-chip flash for key storage and PUF generation.

3. Tamper-Evident Boot Flow

The boot flow must be designed so that each stage authenticates the next before passing control. A minimal flow looks like this:

  1. Hardware self-test: The FPGA’s power-on reset circuitry stabilizes clocks and checks internal logic integrity. Many devices include a CRC check of the configuration memory itself.
  2. Root key load: The security block loads the public key from eFuses or a secure element. In some designs, this step also derives a session decryption key from the root key.
  3. Bitstream authentication: The boot loader block reads the candidate bitstream, computes a SHA-384 or SHA-256 hash, and verifies the ECDSA or RSA signature. If the bitstream is encrypted, the decryption engine uses a symmetric key unwrapped by the root key.
  4. Fallback and lockdown: On failure, the FPGA can retry from a designated golden image stored in a separate flash partition. If the golden image also fails, the device must enter a locked state with minimal functionality, emitting a secure boot failure indicator to a management plane. This state can be signaled via a dedicated GPIO or a message over an I²C bus to a system monitor.

Many FPGAs also support encrypted bitstreams. Encryption alone provides confidentiality but not integrity unless paired with an authenticated encryption mode such as AES-GCM. Without authentication, an attacker can flip bits in the ciphertext without knowing the key, potentially causing exploitable behavior. Therefore, best practice is to use encryption alongside signature verification or to rely on authenticated encryption primitives where silicon support exists.

Implementing Secure Boot: A Practical Walkthrough

Engineers approaching secure boot for the first time often grapple with toolchain integration. The following steps outline a typical implementation flow for a Xilinx UltraScale+ or Intel Agilex device, though the concepts generalize to Lattice, Microchip, and Gowin families with minor variations.

Step 1: Provision Keys Securely

Generate an ECDSA P-384 or RSA-3072 key pair in a hardware security module (HSM) held in a physically secure facility. Hash the public key and program the digest into the FPGA’s eFuses. Never expose the private key to the build server. Instead, signing is performed by the HSM, which receives the bitstream hash and returns a signature blob. This blob is then appended to the bitstream file. For fleets, consider using a cloud HSM service such as AWS CloudHSM or Azure Dedicated HSM to scale provisioning across multiple locations while keeping keys under hardware protection.

Step 2: Configure the Boot Image

The FPGA vendor’s tools allow you to specify authentication parameters during bitstream generation. You instruct the tool to reserve space for the signature, set the public key digest, and optionally enable encryption with an AES key wrapped by the root key. The resulting image is stored in an external quad-SPI or NAND flash accessible to the FPGA’s configuration controller. Pay attention to the flash layout: partition the memory into at least two banks—one for the active image and one for the golden fallback—to enable robust A/B update capability.

Step 3: Set Security Policies in Hardware

Burn the eFuses to lock the device into secure boot mode. Once set, the FPGA will reject any bitstream that lacks a valid signature, including vendor-provided default images. This irreversible step must be executed only after thorough lab validation. In production, ATE (automated test equipment) scripts apply the fuse settings as part of the end-of-line test. Some families also offer a "development" fuse mode that allows signed images from a test key to boot during bring-up, with the production key fused later.

Step 4: Test the Chain

Validate all real-world scenarios: power-on cold boot, warm reset, brownout recovery, and a deliberately corrupted bitstream. Measure boot latency—signature verification with hardware accelerators typically adds under 100 milliseconds, but this can vary. Confirm that the fallback golden image boots correctly and that failure indicators propagate to the system’s management controller. Include tests for JTAG locked status: an attacker should not be able to read or reconfigure the device through the debug interface after secure boot is enforced.

A well-known reference for such a flow is NIST’s Platform Firmware Resiliency Guidelines, which describe protection, detection, and recovery requirements applicable to any programmable device.

Secure Firmware Update Architecture

Even the most rigorously verified boot image will eventually need an update—whether to patch a vulnerability, add features, or align with a revised security policy. The update mechanism must provide end-to-end integrity, authenticity, and rollback protection while minimizing downtime.

Building a Trusted Update Pipeline

A secure update pipeline begins in the engineering infrastructure and ends inside the FPGA’s configuration logic. The key stages are:

  1. Image creation and signing: The build system produces a new bitstream. An HSM signs it with a currently active private key. The signature may be wrapped in a manifest that includes file hashes, version metadata, and a timestamp.
  2. Transport security: The signed image travels over TLS 1.3 to an update server and then to the device. Mutual authentication between the server and the device’s TLS endpoint prevents man-in-the-middle attacks. The device’s TLS certificate should be tied to its unique identity, such as the FPGA’s Device DNA.
  3. Staged storage: The device writes the incoming image to a dedicated flash partition, keeping the current bootable image intact. This “A/B” partition scheme guarantees that a failed update does not brick the unit. Some designs use three partitions: A (active), B (backup), and G (golden factory image) for maximum reliability.
  4. Pre-installation verification: The update agent—whether a software routine running on an embedded processor or the FPGA’s own configuration manager—validates the signature and checks the version number against a stored anti-rollback counter. If both checks pass, it marks the new partition as the active image.
  5. Atomic activation: The boot configuration pointer is updated in a single, power-safe write. On the next reset, the FPGA boots from the new image. Should the image prove unusable, a watchdog timer triggers a fallback to the previous partition. The watchdog timeout should be long enough to allow a full boot attempt, but short enough to detect a stuck system before a critical deadline.

Anti-Rollback Techniques

Simply signing the image is insufficient if an attacker can replay a valid but old firmware version. To close this gap, design an anti-rollback counter stored in a monotonic, non-volatile memory such as eFuses or a trusted platform module. Every firmware manifest includes a minimum security version number. The update agent compares this number against the stored counter and rejects any image whose version is lower. When a new update is accepted, the counter is advanced to that version. Because eFuses can only be blown in one direction, they form an ideal monotonic counter for this purpose. For devices that support field-programmable fuses, the counter can be incremented remotely as part of the update transaction, with a power-loss safe design that verifies the write completed before marking the update as successful.

Handling Partial Reconfiguration

Many high-performance designs use partial reconfiguration to swap hardware modules at run time. These partial bitstreams must be authenticated as rigorously as full bitstreams. The Xilinx Dynamic Function eXchange (DFX) flow, for instance, supports authenticated partial bitstreams where each reconfigurable module carries its own signature. The FPGA’s internal configuration access port validates the signature before configuring the dynamic region, preventing a compromised processor from side-loading a malicious overlay. Similar capabilities exist in Intel’s Partial Reconfiguration flow and Lattice’s Reveal logic analyzer integrations. Ensure that the authentication keys for partial bitstreams are derived from the same root of trust, but can be rotated independently to allow module-specific lifecycle management.

Cryptographic Primitives and Performance Considerations

The choice of algorithms impacts both security and boot time. ECDSA with P-256 or P-384 curves offers compact signatures and fast verification on hardware accelerators, making it a popular choice. RSA-2048 is still common in older devices but requires larger key storage and longer verification times. NIST’s transition to post-quantum algorithms will eventually affect FPGA bitstream authentication, but most current applications operate within the classical security model.

For bulk bitstream encryption, AES-256 in GCM mode provides both confidentiality and integrity. Many newer FPGA families include hard AES-GCM engines that can decrypt and authenticate multi-megabyte bitstreams at wire speed. Engineers must ensure that initialization vectors (IVs) are never reused; a hardware-based random number generator or a monotonic counter wrapped in the key manager can supply unique IVs per boot session.

A practical latency analysis from Xilinx’s configuration user guide shows that enabling AES-256 decryption and HMAC-based authentication adds roughly 50-80 milliseconds to the total configuration time for a typical 25 MB bitstream, well within acceptable limits for most embedded applications. For time-critical applications such as automotive sensor fusion during startup, designers can pre-authenticate the bitstream in a background step while the FPGA holds I/Os in a safe state.

Key Management Throughout the Lifecycle

Key management is the hardest part of any secure boot scheme. A lifecycle-aware approach segments key usage into distinct phases:

  • Factory provisioning: The root public key hash is programmed into eFuses. The private key is locked in an offline HSM and never leaves the facility. During this phase, the device’s unique identity (e.g., Device DNA) can be fused to enable binding of keys to individual units.
  • Field updates: Secondary signing keys are used for routine firmware updates. These keys are themselves signed by the root key and may have shorter lifetimes or be stored in a cloud-based HSM. The secondary key rotation can be automated so that a device never runs with a key older than, say, one year.
  • End-of-life: When a product is decommissioned, revocation certificates or a “kill” bit can be set to permanently disable the FPGA’s ability to accept new firmware, rendering the device unusable for an adversary who obtains physical access. Some solutions also support cryptographic erasure of all stored keys by blowing a dedicated eFuse.

Automated key rotation can be implemented by shipping a manifest that contains the new public key, signed by the old key. The update agent verifies the chain, installs the new key into a write-protected register, and then advances the anti-rollback counter. The old key can be retired as soon as the counter propagates to all devices. This approach is documented in the IAB Internet of Things Software Update workshop and aligns with the SUIT manifest standard being developed by the IETF (IETF SUIT Manifest).

Regulatory and Industry Standards Alignment

Engineers in automotive, medical, and industrial sectors must align FPGA security with sector regulations. ISO 21434 for road vehicles requires a secure software update mechanism and a hardware root of trust for any programmable logic that affects safety. IEC 62443 for industrial control systems mandates that devices verify the integrity of firmware before execution and support authenticated field updates. The Common Criteria evaluation for IP protection profiles now references requirements for configuration bitstream signing. By following the architectural patterns described earlier, product teams can satisfy these requirements without re-architecting the platform.

For aerospace and defense applications, standards such as DO-254 and FIPS 140-3 impose additional requirements on the cryptographic module and key management scheme. Using a FIPS-validated cryptographic library for signature verification—even if implemented in FPGA fabric—can streamline certification. Additionally, the Trusted Computing Group’s TPM 2.0 specification provides a standardized interface for key storage and attestation that can be leveraged by FPGAs with external TPM chips.

Operational Best Practices for FPGA Fleet Security

Technology alone cannot guarantee a secure fleet. Teams must wrap their implementation in robust operational practices:

  • Secure your build infrastructure: Isolate the signing server from the corporate LAN. Use a physical HSM to hold private keys and log every signature operation. Implement code review gating for any change to the bitstream manifest.
  • Enforce role-based access controls: Separate the duties of bitstream development, testing, and deployment. Only a designated release manager should be able to initiate the signing of a production image. Use two-person approval rules in the HSM to prevent unilateral signing.
  • Monitor and audit: Asset management databases must track the firmware version, anti-rollback counter value, and last successful boot time for every deployed FPGA. Anomaly detection systems should flag devices that repeatedly fall back to a golden image or show version counters that move backward. Telemetry can be collected via a lightweight agent on an embedded processor or via a dedicated management CPU.
  • Plan for incident response: Have a pre-tested procedure for distributing an emergency firmware update in response to a zero-day vulnerability. This includes maintaining a revocation list for compromised keys and ensuring the update channel remains reachable even on partially compromised devices. Practice the procedure in a staging environment at least quarterly.
  • Conduct regular penetration tests: External security assessments should target the FPGA configuration chain specifically. Common attack vectors include glitching the power supply during boot, extracting bitstreams via JTAG, or exploiting weak IV generation in the decryption engine. Include tests for fault injection attacks that attempt to skip authentication steps.
  • Maintain a cryptographic inventory: Keep a record of all key material, including the root public key digest, the public key certifying authority, and the dates of key rotations. This inventory is essential when revoking or updating keys across the fleet.

These practices create a defense-in-depth posture that extends from the silicon to the cloud backend.

The Future of FPGA Security: Post-Quantum and Beyond

Looking ahead, the transition to post-quantum cryptography will influence FPGA secure boot designs. Lattice-based signature schemes such as CRYSTALS-Dilithium offer smaller key sizes than RSA for equivalent security, but verification speed and implementation complexity remain active research areas. Some FPGA vendors have begun demonstrating hardware accelerators for these algorithms, anticipating that long-lifecycle infrastructure equipment will need a migration path before large-scale quantum computing arrives. The NIST post-quantum standardization process, now in its final stages, will provide clear algorithm choices for bitstream authentication by 2024-2025. Engineers designing products today should ensure that the FPGA’s hard security block can be updated to support new algorithms, or include a soft-core accelerator for post-quantum verification that can be loaded via partial reconfiguration.

Additionally, advancements in PUF technology are enabling die-specific key generation that never stores keys at rest, further shrinking the attack surface. Combine a PUF with a secure boot chain that measures the PUF output against a stored helper data—this allows each FPGA to derive its own unique root key without any key injection during manufacturing. This approach, already available in some Intel and Lattice devices, eliminates the risk of key exposure during provisioning.

While the cryptographic primitives evolve, the underlying principles of secure boot and measured firmware update remain constant: anchor trust in immutable hardware, measure each link of the boot chain, and never allow unsigned code to run. By embedding these principles into the FPGA lifecycle, engineering teams can field devices that resist the most determined adversaries and adapt gracefully to future threats.