FPGA Guide
Topic hub

Hardware security

What an attacker can do to an FPGA and its bitstream, the defences built into modern devices, and the research topics (side channels, fault injection, PQC) that shape the next ones.

Updated 13 Nov 2026 · bitstream encryption, secure boot, PUF, side-channel analysis, fault injection, post-quantum cryptography, anti-tamper

Overview

An FPGA has one property no ASIC has: its design is a file, and the file can be copied, read and changed. Security on FPGAs therefore starts with protecting the bitstream, then extends to everything an ASIC designer worries about as well, from key storage and secure boot to physical attacks on the die. This hub is for engineers who must decide which device features to turn on, what they protect against, and what they do not. It covers the device as a target. Using an FPGA to build security products (cryptographic accelerators, network filters) touches the same ideas from the other side.

Three attacker goals cover most cases. Cloning: copy the bitstream into another unit and sell it. Reverse engineering: recover the design, or the keys inside it, from the bitstream. Tampering: change what the device does, in the field or in the supply chain.

Key ideas

Confidentiality and authentication of the bitstream

Every mainstream family since the mid-2000s can decrypt an AES-encrypted bitstream using a key in battery-backed RAM or in eFuses. Encryption stops cloning and casual reverse engineering. It does not stop a modified bitstream being loaded unless the device also authenticates it. Authentication (HMAC on older parts, RSA or ECDSA signatures on current ones) is the feature that matters against tampering, and it is the one more often left off. On AMD UltraScale+ the two are separate options, and on Microchip PolarFire the device checks a signature on every bitstream and on every boot. The Starbleed attack of 2020 showed that on AMD 7 Series the encryption alone could be defeated through the configuration logic. The lesson generalises: turn on authentication, keep keys in eFuses rather than battery RAM where the product allows, and treat the key-programming station as part of the security boundary.

boot ROMimmutableeFuse public key hashfirst-stageloader, signedand encryptedbitstreamAES-GCMsignedOS, firmwaresignedmeasuredverifyverifyverifykey storeeFuse, BBRAM, PUFtampervoltage, temp, clockA break anywhere in the chain lets an attacker rununsigned code with the keys of the stage before it.
Secure boot chain on an FPGA SoC: each stage verifies the next before handing over

Keys: fuses, batteries and PUFs

A key has to live somewhere. eFuses are permanent, cheap and readable by a well-funded laboratory with a microscope. Battery-backed RAM is erasable on tamper, but adds a battery to the bill of materials and a failure mode. A physically unclonable function derives a key from manufacturing variation (SRAM power-up state, ring-oscillator frequencies) each time the device starts, so no key is stored at all. AMD Zynq UltraScale+ and Versal, and Microchip PolarFire, include PUF-based key wrapping. A PUF needs helper data and error correction, and its security rests on the quality of the entropy, so it is a feature to understand before relying on it rather than a box to tick.

Physical attacks: side channels and faults

Side-channel analysis recovers keys from power consumption or electromagnetic emission while the device decrypts. The classic differential power analysis of Kocher and colleagues applies to bitstream decryptors, and published work has recovered AES keys from the configuration engines of several FPGA generations. Vendors have responded with key rolling (changing the key every few kilobytes of bitstream) and masked implementations. Fault injection, by voltage or clock glitching, laser or electromagnetic pulse, skips instructions or flips bits to bypass a signature check. Defences include redundant checks, randomised timing and the on-chip voltage and temperature monitors that most families expose. Your own cryptographic cores in the fabric need the same care, and an FPGA makes it easy to test, since you can add the monitors and run the attack on your own board.

Post-quantum cryptography and the supply chain

NIST published the first post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) in 2024, and FPGA implementations of lattice-based schemes were among the first benchmarked because the number-theoretic transform maps well to DSP slices. Vendors have begun adding PQC-capable boot (AMD Versal Gen 2 supports LMS-based signatures at the time of writing), and products with a decade of field life should plan for it now. Supply chain security is the other live area: counterfeit and remarked parts, bitstreams loaded by a contract manufacturer, and the question of whether to trust vendor IP. Device authentication and per-unit keys answer part of it. Procurement discipline answers the rest.

Where to start

Bitstream security presumes you know what a bitstream is and how it gets into the device, so read /learn/beginner/02-how-an-fpga-is-programmed/ and /learn/beginner/10-from-rtl-to-board/ first. Then read your target vendor’s security user guide end to end, because the defaults are rarely the secure settings. A practical first exercise is to enable encryption and authentication on a development board, break the signature deliberately and confirm the device refuses to boot. An advanced track on security engineering is coming.

Tools and vendors

Vendor Bitstream protection Key storage Notable features
AMD AES-256-GCM, RSA-4096 and ECDSA authentication eFuse, BBRAM, PUF (Zynq UltraScale+, Versal) Key rolling, tamper monitors, secure boot in PMU/PLM, PQC on Versal Gen 2
Altera AES-256, ECDSA authentication eFuse, BBRAM, PUF (Agilex) Secure Device Manager handles all configuration on Stratix 10 and Agilex
Microchip AES-256, signed bitstreams always verified eFuse, PUF Flash-based, no external bitstream at power-up, DPA countermeasures licensed from Rambus, Design Security certification
Lattice AES-256, ECDSA on newer parts OTP Mach-NX and MachXO3D sold specifically as platform root-of-trust parts
Efinix AES-256 with authentication on Titanium eFuse Titanium adds authenticated bitstreams, Trion encryption only

Open-source tooling cannot generate encrypted bitstreams for the main families, so a design that needs encryption needs the vendor tools for the final step.

Common mistakes

  • Enabling encryption but not authentication, which leaves tampering open.
  • Programming keys on the production line without controlling who sees them, and keeping a single key for every unit.
  • Assuming a PUF or eFuse is unreadable. Assume a motivated laboratory can read any stored secret and design so that one unit’s loss does not break the fleet.
  • Trusting JTAG to be disabled because the pins are not populated. Disable it in the device, or lock it with the vendor mechanism.
  • Writing your own AES in RTL without side-channel protection, then placing it next to a user-accessible power rail.
  • Forgetting the soft side. A perfect bitstream loaded by an unsigned bootloader is unsigned.

Going deeper

Latest news on this topic

Recent papers

  • NonSense: On the (In)security of FPGA Anti-tamper Sensors

    M. A. Cetin, F. Khojasteh Dana, S. Khalaj Monfared et al. · arXiv cs.CR · digest

    The authors argue that the on-chip sensors FPGAs use to detect glitching and other active physical attacks are themselves a weak point rather than a trusted foundation. Drawing on their recent experimental results, they show that both the detection and the response paths of current hard-IP and soft-IP sensors can be defeated without opening the package. They identify three effects that threat models rarely include: the power delivery network can steer a fault to its target while sparing a nearby sensor, temperature shifts detection thresholds, and ageing drifts calibration. The paper is a position piece with proposed countermeasures rather than a new attack, so read it as a checklist for anyone relying on sensor-based zeroisation.

  • End-to-End NTT on FPGA for FHE Acceleration

    M. Allam, T. Spendlhofer, H. Sanz-González et al. · arXiv cs.CR · digest

    The number theoretic transform and its inverse take about 63 per cent of CPU time in FHE-based neural network inference, so the authors build a fully unrolled, delay-commutator streaming NTT kernel and floorplan it across the three dies of an AMD Alveo V80. At 400 MHz it transforms a 65,536-coefficient polynomial every 5.12 microseconds, which they state is the highest FPGA throughput at that size, and it is up to 22 times faster than the CPU per transform when offloaded. Integrated into the Lattigo library with 128-bit secure parameters, it speeds up key switching and bootstrapping by 1.8 to 2.2 times and end-to-end inference by 1.8 to 2.1 times. The modest end-to-end gain compared with the kernel speed-up shows how much of FHE is not the NTT.