and what it means for FPGAs
Peter Trott, Staff Field Application Engineer, Microchip
The industry today is highly focused on the Cyber Resilience Act (CRA). But what exactly does it mean for FPGAs and FPGA design implementation? Why is it important to all designers, and what does everyone need to do to be compliant?
From 11 December 2027, all Products with Digital Elements (PwDE), which includes hardware and software, placed onto the European Union (EU) market must be compliant with the CRA if they are directly or indirectly connected to a network. A digital product is both the final product and the components used to build products. Placed on the market applies to all products, not just when you place or sell the first version of that product. So, if you sell a product on 10 December 2027, it does not need to be compliant, based on the regulations in place. A day later, the CRA regulations will be enforceable and the product must comply.
The Act applies to all PwDEs and has been defined to help protect critical infrastructure within the EU. However, it does not apply to military or national security products, medical, civil aviation or automotive products which already have their own regulations and standards which cover the same level of protection. However, it does apply if a product is intended for a dual-use application.
To be compliant with the Act, a set of essential cybersecurity requirements are laid out in Annex 1 of the CRA which can be found online. Those requirements are split into two parts. Firstly, the components of the Act that the product must conform to, and then the vulnerability handling requirements that need to be carried out on the device. The Act also addresses the continuous support that must be applied to the product once it is in the market and the penalties that could be imposed if the essential requirements are not met.
In practical terms, the inference is that security can no longer be treated as a checklist item at the end of the design and development process. In its place, the Act mandates a secure-by-design methodology. Companies must show that risks have been identified, attack surfaces are limited, interfaces have been assessed and protected, and that FPGAs can be supported on an ongoing and continuous basis by, for example, updating the logic in the field. This requires a structured approach and an understanding of how components like FPGAs meet these obligations.
That means including a secure development lifecycle, clear documentation before and during development, and early threat analysis to demonstrate compliance.
This then informs the design-focused considerations that follow and the rigorous assessment that needs to be carried out to allow products to be placed on the market.
The implications for design
Fundamentally, the design process to develop a product needs to change from what the industry has been using up to the present day. It is no longer a process that takes a set of marketing requirements and from that, a block diagram is created to support the desired set of features.
From the outset, a Threat and Risk Assessment (TARA) is required to be created from this initial development phase to address the Essential Requirements. Exposed interfaces and features of the design must be examined to determine how they are protected and what threats could be encountered by the device.
Product classes
This applies to the product being developed and also the components that could potentially be used within the product. To support this, the Act defines classes of products at the component level and for horizontal markets from a default class to Class I, Class II, and Critical Class. It is envisaged that most products will fall into the default class where the product developer will do a self-assessment against the Essential Requirements before it is made available on the market.
For Class I products, a similar self-assessment is required but technical standards are being developed to support this process. Class II products have a more stringent standard to adhere to and must be assessed by an external third party. Critical Class is for critical products and carries the burden of requiring a higher level of assurance to an EU approved scheme. In Annex III of the Act a set of important products are defined and assigned to either Class I or Class II. Item 15 of the Class I set specifies: “Application specific integrated circuits (ASIC) and field-programmable gate arrays (FPGA) with security-related functionalities.”
Since the majority of FPGAs available today contain some level of security they will fall into this class of product and a European standard is being established, prEN 50767, to support the development and analysis of the security features of these products that can then be leveraged by the end user’s application to address the risks within their products.
It should be noted that classification is for the product being placed on the market. Since an FPGA is placed on the market as an individual product it must comply with its own regulations. A product needs to conform only to the class defined. Thus, a default product could contain multiple components each with different classes, which could be higher, but the use of higher-class components in the product does not increase the class of the product they are used within.
How is this applied to FPGAs?
Now all FPGAs are not the same. There are two different technologies, SRAM and Flash, and they provide a different fundamental base. On top of this, there is no standard set of cryptographic features. The prEN 50767 standard does not specify what these features are but just that they need to support the Essential Requirements.
How this is done is down to the technology and the implemented elements. The TARA for each family will describe how the requirements are addressed within the device, but it will be down to the user to determine if the methods described within the device’s documentation address the Essential Requirements that need to be met within their product.
Microchip FPGAs
Microchip FPGAs and SoCs provide a feature-rich set of cryptographic features within the Igloo2 FPGA, SmartFusion2 FPGA, PolarFire FPGA and PolarFire SoC families. Firstly, as Flash-based technologies, the devices are secure by design since the configuration cannot be read out of the non-volatile families.
The programming file is encrypted by default, but the user can add their own keys which are stored securely in a hashed format. Each device has a unique ID determined through a Physically Unclonable Function (PUF) which can also be used to generate private keys that can be used in secure communications. The PolarFire families also have the addition of a highly versatile cryptographic coprocessor that can be utilized in a user’s application.
Finally, although not required or described within the FPGA standard, Microchip FPGAs and SoCs include several anti-tamper features that can be used to secure interfaces, protect against physical attacks and return a device to its default state if required. This makes the families compliant with some of the requirements defined for Class II devices. A simplified security model of PolarFire can be seen in figure 1.
What is the Cyber Resilience Act trying to achieve?
The properties of a product that the Essential Requirements are addressing are:
- Security by design
- No known exploitable vulnerabilities
- Secure by default configuration
- Security updates
- Access control
- Confidentiality protection
- Data minimization
- Availability of essential and basic functions
- Minimizing negative impact
- Limiting the attack surface
- Mitigation of incidents
- Recording and monitoring
- Deletion of data and settings
When it comes to the vulnerability handling, the Essential Requirements relate to:
- Identifying the components and their vulnerabilities
- Addressing vulnerabilities
- Regular testing
- Publishing addressed vulnerabilities
- Having a coordinated vulnerability disclosure policy
- Secure distribution of updates
- Dissemination of updates
To achieve this, the product supplier needs to provide both technical and user documentation to describe the product. The technical documentation should include the process used to create the product, its cybersecurity risks, the product’s support period, the tests that were performed and a list of all its components.
Technical documentation must be made available to regulators on request and does not need to be released publicly. The User documentation should include the manufacturer’s details, the unique identifier for the product, its intended purpose, the support period, user guidance on its use and documentation of its components.
What is your next step?
So, in essence, what should you, as a product manufacturer do? Initially you need a process that defines a secure development lifecycle, and establish a cybersecurity culture within your company. For your product you need to identify which product category and class it falls within and, if necessary, identify any harmonized standards that are applicable.
Everything needs to be documented through the product’s full lifecycle, a minimum of five years, and these documents must be kept for at least ten years. Your product must be designed to be secure as defined by the Essential Requirements and the installation of your product must be done securely. Once on the market this security must be maintained continuously through a Vulnerability Management process with provision of updates to the product to maintain a state of continuous compliance.
It must be supported for at least the expected lifecycle and any vulnerabilities discovered during this time must be disclosed and addressed by monitoring and managing any cyber incidents. In the event of a vulnerability being exposed and exploited, both the regulators and customers must be informed. By using FPGAs within your product, you will have the assurance of their integrity as a Class I product and have the documentation available to support your own vulnerability analysis.
The CRA introduces many product requirements and changes to the development and lifecycle management. Some of these requirements will be new to many developers and thus have an impact on the new skills and ongoing support required to maintain a product. This will undoubtedly affect the design cycle time, so working with your vendors to leverage the capabilities and documentation they provide will be essential to success.
