EU Cyber Resilience Act (CRA) Implementation Timeline

On November​ ​20,​ ​2024, the EU Cyber Resilience Act (hereinafter referred to as CRA) was published in the Official Journal of the European Union (OJEU) and came into effect. *1
The harmonized standards of the Radio Equipment Directive (hereinafter referred to as RED) have also been published in the Official Journal of the European Union (OJEU). *2
This will establish the general timeline for adapting to the CRA, and we believe that manufacturing companies will be able to more specifically consider their time constraints and the measures they will need to take.
Here we present a timeline of major regulations, including the CRA, which is an issue for exporting to Europe.

Figure 1 European regulatory timeline

As the timeline above shows, when we work backwards taking into account the development, production, and export of applicable products, we can see that there is little time left to implement adaptation efforts.
In particular, the timeline is even tighter for CRA-focused product manufacturers that manufacture products that are also subject to the RED.
In terms of the order in which we work on these issues, the fact that we start with RED, which has a strong emphasis on security requirements for products, also complicates the plan, I feel.

Product Manufacturer Concerns and Initiatives

Product manufacturers will likely have a wide range of concerns, from product development to creating corporate systems, such as whether hardware modifications are necessary and whether they will be able to meet the time constraints of vulnerability reporting requirements.
First of all, it is urgently necessary to plan and make decisions, including grasping the overall picture of the initiative, organizing internal stakeholders, understanding existing secure development processes, and examining the target products.
We believe that the secure development process is relatively easy because there are standards *3 to refer to, which allow steady progress to be made.
However, when it comes to security functional requirements, it can be difficult to grasp the content of the secure functions that are candidates for implementation and how to plan for their implementation.

Specific examples of product security requirements

For example, when considering the need for a PKI (Public key infrastructure), we provide reference information on the amount of work and time required.
This is an authentication technology area that is described as one of the product security requirements in harmonized standards and standardization standards, and is also a technology that is incorporated into standard communication protocols.
Possible uses include device authentication between the same company's products, and device authentication for interoperability between products from other companies.
However, there are many measures that need to be taken before implementation, such as understanding PKI itself, examining the authentication boundaries that require authentication based on the expected environment in which the manufactured products will be placed, organizing internal stakeholders for implementation, and selecting a certification authority.
​One important thing is to develop a basic design for CA operations throughout the product lifecycle and business model.
We believe that it will take approximately six months to complete all of these efforts. 

For example, when considering the need for HW security, we provide reference information on the amount of effort and time required. 

When selecting the security measures to implement, it is a good idea to consider the following points:

1. Define security requirements: (1 week to several weeks)

   Clarify the assets you want to protect, the risks, and the threats, and define the level of security you need. Depending on the risks and threats, you can decide whether to address them through operations, introduce software measures, or introduce HW security.
   Necessary requirements also include attack resistance, data encryption, and authentication methods. 

2. Clarification of use:

   Once you have decided to introduce HW security (here, secure elements), you must clarify the functions required for the secure element. The required performance and functions vary depending on the application (e.g., payment, authentication, data protection, etc.). 

3. Market research (a few weeks):

   Research and compare different secure element options. At this stage it is important to gather information from multiple suppliers.

   
   Survey item examples
   • Standards and Certifications
     ・Standards that the secure element complies with (e.g. CC (Common Criteria), FIPS) and authentication, which allows you to assess the trust and security level.
   • Performance requirements
     ・Consider performance requirements such as processing speed, power consumption, and memory capacity. This is especially important for applications that require real-time performance.
   • Compatibility
     Check compatibility with other systems and devices, especially if integration with existing infrastructure is required.
   • Supplier reliability
     ・Evaluate the reliability and support system of the secure element supplier, and also take into consideration whether long-term support is available.
   • cost
     - Weigh the risks and costs of a security incident. The most expensive option is not always the best option.
4. Review and Comparison (1 month):

   Based on the information gathered, we evaluate and weigh the options, a process that includes technical evaluation and cost analysis. 

5. Selection and decision (1 week):

   Make the final selection and obtain agreement with the relevant parties. 

6. Implementation plan (weeks):

   We will develop an implementation plan for the selected secure elements.
   Since secure elements are said to have a longer manufacturing lead time than general semiconductors, it is necessary to set a period with ample leeway.

Overall, the selection process for a secure element typically takes anywhere from a few weeks to a few months, but it may take longer depending on specific requirements and circumstances. It is important to be flexible and adapt according to the progress of the project.

You will also need to acquire the knowledge necessary to select and implement secure elements.

• Security knowledge
  ・Basic concepts of security (encryption, authentication, access control, etc.)
  ・Security standards and regulations (e.g. CC, FIPS Knowledge of
• Technical skills
  ・Understanding hardware and software
  ・Knowledge of secure element architecture and protocols
  ・Programming skills (especially useful for security-related development and testing)

It is important to compare specific secure elements based on these points and make the most suitable selection. We also recommend seeking the opinion of an expert if necessary.

The Construction and Importance of a Risk Assessment Process

So far, we have provided some reference information (information of interest) from the perspective of rework.
The intention of the description is to include the impact on design rework, but it can also have a significant impact on the content of risk assessment.
We believe it is important to build a risk assessment process that takes CRA (Secure Development Process Operation) into consideration.
If consideration in areas that require expertise is insufficient, there is a possibility that there will be parts that cannot be properly explained when actually proceeding with design and implementation or when conducting third-party evaluation. Furthermore, in the future, application of the standards will be insufficient not only to new products but also to products that are already in circulation.
Although there is a very tight time frame, I believe that manufacturers are making preparations. I hope that this article will be useful for looking back on the processes that have been established and will be of use to you in the future.

Figure 2. Abstraction of the relationship between risk management and processes

■ External References
*1…https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402847
*2…https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32025D0138&qid=1738805602149
*3…IEC62443-4-1