EU Cyber Resilience Act (CRA) - All you need to know in a nutshell

(Updated: 20th March 2024)

New regulations are always difficult to understand. They are filled with confusing terms and can seem scary, especially if they affect your development and manufacturing process. We collected the main key points of the EU’s Cyber Resilience Act (CRA) so you know what’s ahead.

What is cyber resilience?

Cyber resilience strives to make sure products and customers are safe in the virtual space. This can be achieved with a variety of elements, ranging from the anticipation of cyber attacks to the quick recovery when an attack is carried through successfully. In our everyday life, a lot of this might seem unlikely at first glance, just something that we read in the news. However, knowing that cybercrime had an annual global cost of €5.5 trillion in 2021, it’s only fair that these issues are addressed and regulations are kept up to date on this topic as well.

Why do we need the Cyber Resilience Act (CRA)?

The Cyber Resilience Act (or CRA for short) complements the NIS2 Directive (Network and Information Systems Directive-2) making sure that connected devices don’t fall through the cracks of the upcoming new legislation when it comes to cybersecurity issues. CRA aims to cover all digital products that were not covered by the previous legislative framework. The main aspects they are trying to solve are 1) the lack of information about the products so buyers can make informed decisions and keep their products secure and 2) the overall improvement of devices' generic low security level.

What is the impact of the CRA?

It will impact your business if you are operating in EU markets.

The target is mainly manufacturers, they will have to meet requirements when it comes to the design of devices with digital elements. Their authorized representatives, resellers, and distributors also bear responsibility for checking compliance with the regulation. The scope is truly as wide as it sounds based on this definition.

Product Classification

Products are classified into 3 categories: default, Class I, and Class II. You should first determine which one applies to you.

Default

This is quite simple. If your product is not in the other categories, then it is in the default one. For this category, conformity is reached via self-assessment and documentation.

Class I and Class II

Annex III lists the categories for each. You can review the full list here. These are deemed more critical and will have to face more strict requirements. Class I refers to critical products by having one of these characteristics, while Class II encompasses products where both apply:

• their function is critical for the security of another product, therefore its failure carries further risks,
• their function itself carries a significant risk.

For Class I, manufacturers can choose whether they confirm via a cybersecurity standard (not yet specified which one, but so far, ETSI EN 303 645 appears to be a winner) or via 3rd party assessment.

For Class II, 3rd party assessment will be mandatory.

My business is affected, what now?

If you fall into Class I or Class II, you will have a lot more work cut out for you. In the case of Class I, we suggest you start reviewing ETSI EN 303 645, as compliance with that standard might be the way to go, although this is not yet confirmed. However, the experience you gain by reviewing and mapping such standards will be valuable still.

Alternatively, you can start searching for a trusted 3rd party security lab that will be your partner, especially if you are in Class II. We had the luck to work together a bit with cetome, and we can wholeheartedly recommend their services. (No paid promotion or affiliate benefits involved in this.)

Now, let’s check some of the requirements for the generic category, which applies to most products. This list is not exhaustive but should give you a pretty good idea of what’s coming.

Security by design

Below are several elements of this aspect you must consider and adopt:

• Determine risks during the design phase, and apply solutions that correspond with the risk factors.
• You must make an effort to limit the attack surface and reduce the potential impact.
• Process only strictly necessary data.
• Data must be protected by encryption or other mechanisms.
• Unauthorized access should be prevented by authentication, identity, or access management systems.
• Your product cannot enter the market with known exploitable vulnerabilities. You can read our previous post here about the most dangerous types of vulnerabilities.
• You will need to document this whole process.

Security throughout the product’s lifecycle

You need to regularly test your products, and keep a record of all the vulnerabilities discovered. You must also keep you security updates available free-of-charge for 10 years after they were issued, or for the remainder of the support period, whichever is longer.

Transparent vulnerability reporting process

You need to have a proper, publicly available vulnerability disclosure policy, and an easy way for anyone, including your buyers to file their reports.

Informed customers

You will be obligated to inform customers of the product’s security aspects in a clear, easily understandable format.

Reporting obligations

If you have a security breach, you will have to report it immediately to the EU cybersecurity agency - ENISA. They recently announced they will have a separate team handling CRA-related issues. The timeline here is incredibly tight - within 24 hours of noticing the issue.

How much time do I have to comply?

The first draft of the CRA was published in September 2022.

In March 2024, The European Parliament accepted the draft, now we expect that it will enter into force around the end of Q2 2024.

Upon entry into force, manufacturers, importers, and distributors of hardware and software products will have 36 months to adapt to the new requirements, except for a more limited 21-month grace period concerning the reporting obligation of manufacturers for incidents and vulnerabilities. So overall, currently we expect vulnerability reporting final deadline for 2026 Q1, and the overall final deadline for 2027 Q2.

Can it mean the end of open source in Europe?

Adding some interesting spice into the mix if you are interested. This webinar dives into the effect of CRA on the open-source community. It draws attention to the fact that some widely used open-source components might simply not be available for products coming to the Europan market.

Commercial activity has a strange definition, which means many open-source projects could fall into it just because of their quality.

We believe the situation will not be this dire, but we acknowledge that there might be side-effects of the regulation we do not yet see.

Our take on the state of cybersecurity today

Having a common baseline for the IoT players who are affected by cybersecurity is a step in the right direction. Before these regulations, it was up to the manufacturers to implement security elements and these solutions were as diverse as the IoT landscape. But “diverse” doesn't mean sufficient, the IoT sector was lagging behind alarmingly when it comes to security.

Despite the positive change, we are worried about some of the guidelines of the upcoming legislation. This can lead to a situation where the necessary security steps might be properly implemented when it comes to the reports and administrative tasks but will be lacking in real-world security resilience. Strong protective measures against practical exploitability are what matter for consumer safety at the end of the day.

Compliance in this case is a very welcome first step but creating truly secure IoT devices (and keeping them secure) will need more significant changes from all players in the industry. We built our cybersecurity tool with this in mind, regardless of the regulations or your place in the industry, we offer something that can be used in any situation to level up IoT cyber security across the board.