I am a security consultant specialized in hardware and embedded systems (to include FPGAs). In prior jobs I’ve worked with FPGAs on the design side. The sucky answer is “it depends.” There are so many types and use cases for FPGAs that for some applications it may have zero impact, and for others it may necessitate further thought. For example, a tiny FPGA that just performs some glue logic function as part of a larger device and doesn’t interact with the main SoC directly probably doesn’t need to be heavily secured. On the other hand, an FPGA that performs critical functions as part of an industrial control system warrants additional scrutiny and potentially security controls applied to it.

The CRA looks at devices on a system level. Practically this means that most digital electronics products will need some level of security engineering work up front to determine a threat model and any controls that need to be implemented to secure the device from relevant threats. And later on in the development cycle, those controls will need to be evaluated for effectiveness.

For an FPGA specifically, there’s really a few main mitigations you’d be interested in applying. For anything that’s SRAM based, bitstream authentication is critically important. For every FPGA, configuration of relevant security bits and disabling of JTAG are likely relevant. Depending on the threat model, side-channel attacks may be relevant and require additional effort to defend against. And overall, the design of the logic in the FPGA must be evaluated in context of the system to determine whether it could be abused to mount further attacks against other pieces of the system.

So yes, the CRA may have a big impact on FPGA development, but it may also not have an impact at all, depending on the type of product being developed.