All About Circuits

Hardware-Based Security for FPGAs: Protecting Against Evolving Threats

Learn how rising security threats, quantum computing, and strict regulations demand FPGA architectures with integral hardware security and crypto agility for long-term compliance.


Industry Article September 17, 2026 by Keith L. Spencer, Efinix

FPGAs have become foundational components across some of the most security-sensitive sectors in the electronics industry. From military and aerospace platforms to 5G wireless and wireline infrastructure, automotive systems, data centers, industrial automation, and edge-connected devices communicating with cloud services are areas where FPGAs are deeply embedded in applications.

In these cases, compromise is not an inconvenience but a threat to safety, national security, and economic stability. Their versatility and reprogrammability are well established advantages. But that same connectivity and programmability also make them attractive targets in an increasingly hostile threat environment.

 

FPGAs offer great flexibility, but they are also attractive targets to hostile attacks.

FPGAs offer great flexibility, but they are also attractive targets to hostile attacks.
 

The attack vectors facing FPGA-containing systems are numerous and evolving:

 

Bitstream tampering—Where adversaries intercept, reverse-engineer, or substitute FPGA configuration data—remains one of the most direct threats, capable of inserting malicious logic or exfiltrating sensitive design IP. Software for embedded processors is also vulnerable to compromise, requiring complex methods to ensure the software comes from a trusted boot source.

Side-channel attack—Exploiting physical leakage such as power consumption, timing behavior, and electromagnetic emissions to extract cryptographic keys, bypassing software-layer protections entirely.

Supply chain threats—Substituting counterfeit component hardware containing a ‘Trojan Horse’ inserted during manufacturing, and compromised IP blocks integrated during design, have moved from theoretical concern to documented reality.

Fault injection attack—Manipulating voltage, clock, or laser signals to force devices into exploitable states.

 

Looming over all of these is the quantum computing threat: adversaries pursuing "harvest now, decrypt later" strategies are already collecting encrypted data today, betting that future quantum-capable systems will break the cryptography protecting it.

 

Two Regulatory Frameworks

This evolving threat matrix is forcing organizations and government institutions worldwide to mandate more rigorous security features and countermeasures for systems containing programmable logic. Two regulatory frameworks in particular are driving urgency and establishing hard compliance timelines:

  • CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) - Released in 2022, CNSA 2.0 defines the post-quantum cryptographic algorithms required for all U.S. National Security Systems. The transition timeline is aggressive: by 2027, all new NSS acquisitions must be CNSA 2.0 compliant. Software and firmware signing must use quantum-resistant algorithms by 2030, legacy networking equipment that cannot support PQC must be phased out by the end of 2030, and full enforcement across all NSS cryptographic implementations is targeted for 2031–2033. The approved algorithms, including ML-KEM (CRYSTALS-Kyber) for key encapsulation, ML-DSA (CRYSTALS-Dilithium) for digital signatures, and hash-based schemes LMS/XMSS for firmware signing, represent a fundamental shift away from RSA and ECC that will ripple across every hardware platform in the defense supply chain.
  • European Union Cyber Resilience Act (CRA) - Entered into force in 2024, the CRA establishes mandatory cybersecurity requirements for all products with digital elements sold in the European market. Mandatory vulnerability and incident reporting to the European Union Agency for Cybersecurity (ENISA) begins September 2026, with full compliance, including secure-by-design development, lifecycle vulnerability management, and conformity assessment, required by December 2027. The CRA applies broadly across hardware and software, and non-compliance carries financial penalties. For FPGA vendors and the system manufacturers who integrate them, the CRA effectively mandates security as a design requirement, not an afterthought.

 

A Now Problem, Not a Future Problem

These are not distant milestones. For organizations designing FPGA-based systems today (i.e. systems that may ship in 2027 and remain in the field for a decade or more), the compliance clock is already running. Semiconductor suppliers are tasked with extending production manufacturing and support well beyond 2040.

This extended service life underscores the critical importance of crypto agility; the ability to add, update, or revoke cryptographic keys and/or transition to new algorithms in response to emerging vulnerabilities or breakthroughs in quantum-enabled decryption and deploy field upgrades to products. FPGAs are inherently well suited to this requirement as their reprogrammable architecture allows cryptographic implementations to evolve in place, without the costly and often impractical hardware replacement cycles that fixed-function devices demand.

Furthermore, FPGAs offer the unique ability to distribute security functions across a heterogeneous landscape of dedicated hard IP blocks, programmable fabric-based hardware implementations, and software executing on embedded hard and soft processor cores. This creates a diverse defense that is significantly more difficult for adversaries to analyze, attack, or compromise than the fixed implementations of application specific standard products(ASSP).

 

A Multi-Layered Architecture for FPGA Security

Securing an FPGA-based system requires addressing two fundamentally distinct but interconnected domains. The first is protecting the FPGA device itself by ensuring that only trusted, authentic configuration images are loaded, that cryptographic keys are securely provisioned and stored, and that the device can establish a verifiable chain of trust from its very first power-on cycle. The second is leveraging the FPGA's unique architectural properties to implement robust security functions within the user's designed system. These two domains are complementary: a secure platform foundation enables trustworthy user-mode security operations, while the flexibility of the FPGA fabric allows both domains to evolve as threats change.

 

Securing the Platform: Hardware Root of Trust and Bitstream Protection

The security of any FPGA-based system begins before the first line of user logic executes. At power-on, an SRAM-based FPGA is a blank device—it contains no configuration, no application logic, and no inherent identity. It must load its entire functional definition from an external source, typically a flash memory or a host processor. This creates a critical vulnerability window: if the configuration bitstream can be intercepted, modified, or substituted during this process, the entire system is compromised from the ground up.

 

On-chip encryption and authentication on FPGAs

On-chip encryption and authentication on FPGAs

 

Establishing a hardware root of trust (HRoT) is the foundational countermeasure. The HRoT is an immutable or highly protected anchor point from which all subsequent trust decisions derive. The FPGA must be able to start from a zero-trust state and build confidence in the authenticity and integrity of its configuration image through a cryptographic chain of verification. This process involves several critical capabilities:

 

Bitstream encryption and authentication. The configuration bitstream must be encrypted (typically using AES-256) to protect intellectual property and prevent reverse engineering, and authenticated using a digital signature (RSA, ECDSA, or increasingly, PQC-based schemes) to verify that the image has not been tampered with and originates from a trusted source. The FPGA's on-chip decryption engine processes the encrypted bitstream as it is loaded, while the authentication engine validates the signature before allowing configuration to complete. If authentication fails, the device should enter a secure lockdown state and refuse to operate.

Secure key provisioning and storage. The cryptographic keys that underpin bitstream encryption and authentication must themselves be protected. Modern FPGAs typically offer multiple key storage mechanisms: one-time programmable eFUSE arrays that permanently burn keys into silicon, battery-backed RAM (BBRAM) that provides volatile but reprogrammable key storage, and increasingly, Physically Unclonable Functions (PUFs) that derive device-unique keys from inherent manufacturing variations in the silicon itself. Each mechanism presents different trade-offs between permanence, reprogrammability, and resistance to physical extraction, and the choice of mechanism has direct implications for field serviceability and key lifecycle management.

Key revocation and update. A secure system must not only protect keys but also provide the ability to revoke compromised keys and provision replacements. This is particularly critical for long-lifecycle deployments where a key compromised years into a product's service life must be recoverable without physical hardware replacement. FPGA devices that support multiple key slots, secure key rotation protocols, and anti-rollback mechanisms provide essential resilience against evolving threats.

Secure debug and access control. Debug interfaces such as JTAG, which are essential during development, represent significant attack surfaces in deployed systems. A comprehensive security architecture must provide the ability to disable, lock, or authenticate access to these interfaces after production, preventing adversaries from using debug ports to extract keys, read back configuration data, or inject malicious logic. Equally important from a practical standpoint is the security posture of devices returned through the manufacturer's return material authorization (RMA) process. Returned devices may contain sensitive cryptographic keys, proprietary design IP embedded in the bitstream, or application-specific data that must not be exposed during failure analysis or device disposal. A robust FPGA security architecture must support secure RMA workflows that allow the device vendor or system integrator to perform diagnostics without compromising stored secrets and ensure that keys and sensitive configuration data can be zeroized before a device leaves the controlled environment.

 

When properly implemented, these capabilities establish a chain of trust that extends from the immutable boot ROM through the authenticated bitstream and into the running application, ensuring that the FPGA's operational state can be verified as genuine at every stage.

 

User-Mode Security: Leveraging the FPGA's Heterogeneous Architecture

Once a trusted platform foundation is established, the FPGA's architectural versatility becomes a powerful asset for implementing system-level security functions. Unlike ASSPs or discrete security controllers that offer a fixed set of cryptographic capabilities, an FPGA allows the system designer to distribute security operations across three distinct execution domains: dedicated hard IP blocks, custom logic implemented in the programmable fabric, and software routines running on embedded processor cores. This heterogeneous approach provides both performance and security advantages that no single-domain implementation can match.

 

Hard IP acceleration. FPGAs include dedicated silicon blocks for common cryptographic primitives, offering AES encryption engines, SHA hash accelerators, and true random number generators (TRNGs) built directly into the device. These hard IP blocks offer the highest throughput and lowest latency for their supported operations because they are purpose-built in silicon, with fixed data paths optimized at the transistor level. For high-bandwidth applications such as line-rate encryption of network traffic or real-time integrity checking of data streams, hard IP accelerators are essential.

Programmable fabric implementations. The FPGA's reconfigurable logic fabric allows designers to implement cryptographic functions as custom hardware accelerators tailored to their specific requirements. This is particularly significant for PQC algorithms, where dedicated hardware acceleration is critical for practical deployment. Lattice-based algorithms such as ML-KEM and ML-DSA rely heavily on polynomial arithmetic that benefit enormously from hardware parallelism. FPGA fabric implementations of these algorithms can achieve performance levels that software implementations on embedded processors often cannot approach. More broadly, fabric-based implementations of AES-GCM have demonstrated throughput exceeding tens of gigabits per second per stream.

Software on embedded processors. Embedded processor cores such as RISC-V or Arm can be built as hard IP or synthesized in the FPGA fabric to provide flexibility to run cryptographic operations in software. This is valuable for protocol management, certificate handling, key negotiation, and less performance-critical operations where the ability to update algorithms through a firmware patch without redesigning hardware provides maximum crypto agility.

 

Embedded processor cores can be built to run cryptographic operations in software.

Embedded processor cores can be built to run cryptographic operations in software.

 

The Blended Advantage

The real power of the FPGA lies not in any one of these domains alone but in the ability to blend all three into a unified security architecture. An example implementation might use hard IP blocks for high-speed AES encryption, fabric-based accelerators for key exchange and signature verification, and software on an embedded processor for Transport Layer Security (TLS) handshake management and certificate validation.

Inline hashing and encryption of cleartext data can potentially be performed via hard IP accelerators for maximum throughput, through custom fabric implementations for algorithm-specific optimization, or via software for flexibility. A well-designed FPGA-based system can employ all three approaches simultaneously across different data paths or security layers and obfuscate the design security layers for would-be attackers.

This distribution of security functions across multiple execution domains creates a fundamentally different attack surface than a purely hardware or purely software solution. An adversary cannot target a single processor's instruction stream or a single hardware block's side-channel signature; instead, they must contend with a heterogeneous mix of implementation styles, each with different physical characteristics, timing profiles, and vulnerability surfaces.

The result is a security posture that is inherently more complex to analyze, probe, and defeat. A blended security solution in an FPGA offers a significant advantage in the PQC era of increasingly sophisticated and well-resourced attackers.

 

Meeting the Moment

The convergence of escalating hardware threats, firm regulatory deadlines, and the looming post-quantum transition has made FPGA security a defining challenge for the semiconductor industry. To address this market need, Efinix has announced its latest expansion in the 16nm Titanium FPGA family called Titanium Edge with enhanced security features:

  • Symmetric bitstream encryption using AES256-GCM algorithm
  • Asymmetric private & public key pair generation and authentication using RSA-4096 algorithm
  • Non-volatile anti-fuse key storage with anti-tamper and side channel attack protection and data obfuscation
  • Signature authentication using EC-DSA-384 and quantum resistant ML-DSA-65 algorithms
  • AES-KW key wrapping and unwrapping
  • Physically Unclonable Function (PUF) for generating individual device-unique cryptographic keys
  • Unique Device Identity (UID)
  • Hash-based Message Authentication Code using SHA-512 (HMAC-512) for message-level authentication and validation of trusted data source
  • Key management features including revocation and zeroization
  • True Random Number Generator (TRNG) for high-entropy, hardware based randomness for generating keys, nonces, and seeds for secure protocols
  • JTAG port disabling

 

In addition to these silicon features in Titanium Edge, Efinix has a number of IP solutions for PQC compliance including ML-DSA, ML-KEM, SHA3, SHAKE that can be implemented in FPGA fabric and on Efinix Sapphire RISC-V processors.

Efinix welcomes the opportunity to discuss how its FPGA-based security solutions can address the challenges facing your applications. For more information visit us at www.efinixinc.com.

 

All images used courtesy of Efinix.