I’ve seen quite a few people talking about the upcoming EU Cyber Resilience Act (CRA) on FPGA forums. Some are favorable, especially from those in the aerospace, defense and medical sectors, seeing it as strengthening the security of FPGAs throughout the whole supply chain. Others are concerned that FPGA workflows don’t map cleanly to the CRA requirements which can be seen as software‑centric. A number see the certification and documentation overhead as yet another unwelcome burden.
I am concerned about it, but in many ways it could be a good thing. FPGA features like secure boot, bitstream encryption and tamper detection are good engineering practice and regulated sectors have their own security frameworks for issues like these to define appropriate standards and expectations. Across every sector, though, the security challenges are widening.
Post-quantum cryptography has already arrived on the testbench, requiring engineers to update public key cryptography approaches along with secure boot, firmware signing, and key exchange protocols. That’s a challenge all by itself
Similarly, more and more devices are now processing workloads at the edge, calling for engineers to secure FPGA based systems that are exposed to hostile networks and remote update paths. And FPGAs themselves are becoming far more complex and connected, with hardened processors, high speed interfaces and network facing subsystems expanding the potential attack surface yet further.
So in a way, the CRA could be seen as a wake-up call. In practise, it’s less about adding new burdens and more about recognizing that security can no longer be treated as an afterthought. The CRA pushes us to think about how our designs evolve over time, how updates are delivered, and how vulnerabilities are handled once a product is in the field. It encourages us to build repeatable processes rather than relying on tribal knowledge or ad hoc engineering judgement. For FPGA teams, that shift alone is significant, because many of our workflows were never designed with formal security evidence in mind.
Security is evolving and we need to evolve our own approaches as well. What the CRA does provide is an auditable set of security obligations and processes that force us to demonstrate how our FPGA based systems are secured, maintained and updated over time, not just at the release stage.
For FPGA based products, that means documenting the security chain from power on to application load, maintaining a clear record of third party IP blocks, and showing how bitstream protection, secure boot and update mechanisms are configured and verified. It also means demonstrating how vulnerabilities are tracked, assessed and resolved across the product’s lifetime.
None of this is impossible, but it does require a more structured approach than many engineering teams are used to. It will be a task, yet at the same time it will make security a measurable engineering discipline rather than an informal best effort.
Fortunately, a timely session at the FPGA Horizons Conference in October will provide some valuable insights into what the CRA really is, and how we can prepare for it. In The Cyber Resilience Act is here: Are your FPGAs ready?, Ian Pearson from Microchip will explain the CRA’s essential requirements, life-cycle-based security expectations, and mandatory vulnerability-management processes.
He’ll also clarify the responsibilities for manufacturers, including support and security update requirements, and highlight how the CRA applies to both new and legacy products. So something we’re perhaps not looking forward to can at least be something that’s manageable.
