Skip to main content

📣 OpenSSF Community Day NA CFP is now live. Submit your proposal.

search

What will my business need to do for the EU CRA?

EUCRAMar24

By Mike Bursell, Co-chair, OpenSSF Cyber Policy WG

Introduction

The European Union’s Cyber Resilience Act (CRA) is a piece of legislation that covers all countries within the EU and the EAA and entered into force on 10th December 2024. It covers many types of devices and applications that are either sold or otherwise made commercially available in Europe and the intention behind it is to improve the cybersecurity of products available to consumers and businesses across Europe.

This article looks at the CRA and how it is likely to affect your business, and is a companion to the article “Does the EU CRA affect my business?”. Note that the requirements on “open source stewards” are different, and not covered within this article. The details of implementation of the CRA are still being worked out and although most of the measures aren’t due to come into force until September 2026, the impact of the Act is going to be wide-ranging. For many organisations and businesses, there will be important changes to processes around how they create, document, sell, upgrade and support products, all of which require planning and implementation well in advance of full implementation of the Act. While this article should not be considered as providing legal advice, it will give you basic information to allow you to decide next steps.  

Compliance and conformity

The CRA applies to what are defined as Products with Digital Elements (PDEs).  A PDE is defined as “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.”  

Core to the CRA is a requirement that most PDEs will be required to be conformant with the Act, and extends the “CE mark” to PDEs. In some cases, conformity can be demonstrated through following particular processes and declaring that your PDE meets the specific requirements (though this may be checked by another agency); this is known as “internal conformance based on internal control” and still requires notification to an appropriate EU body.  In other cases the PDE must be submitted for external assessment by an organisation or individual authorised by the EU. It is expected that cross-certifications (by equivalent bodies in other jurisdictions) will be accepted in the future. Which PDEs fit into which classes, and therefore require what – and levels – of conformity has been specified, and a fuller definition should be available by December 2025.  Some of the classification types are discussed in the Classes of PDEs below.

Compliance is a wider concept, which starts with having a PDE that conforms to the requirements, but involves a continuing set of actions such as vulnerability management. The most important of these are listed under Compliance measures.

Classes of PDEs

Some types of PDEs are already covered by EU legislation, including many of those used in telecommunications, healthcare and automotive sectors, as well as those used for national security or defence, are not covered by the CRA.  Other types of PDEs are listed below, with the expected requirements for conformity.

  • Important PDEs – PDEs that have a high risk in that they might have a negative impact on the health, security or safety of users if they malfunctioned or were compromised will be classified as “important PDEs”. There are two categories of important PDEs: Class I & Class II, with Class II having a higher possible impact (see CRA Annex III). These are required to undergo external conformity assessment. Important PDEs include Operating Systems, routers, health monitoring wearables, browsers, virus scanners, baby monitors, firewalls and much more.
  • Critical PDEs – PDEs that have a specific cybersecurity function (see CRA Annex IV).  These are required to undergo external conformity assessment – these include devices like smart electricity meters or smart cards.
  • Open source PDEs – PDEs that are 100% open source (according to the definition provided by the CRA) may undergo internal conformity assessment even if they are “Important PDEs”.
  • Other PDEs – PDEs that do not meet any of the other conformity can generally be declared by the manufacturer, following specific regulations. Anything that is not important or critical according to the CRA falls into this category unless otherwise regulated (e.g. medical devices).

The CRA states that the EU will provide new acts to cover the specific classes and types of PDEs by mid-December 2025, though initial examples are already available.

Compliance measures

This section briefly lists the main compliance measures that manufacturers must undertake under the CRA. It is not complete or a full description, but gives an overview of most of the items most likely to affect manufacturers, and to which they should pay attention.

  • Conformance assessment: this comes in two four types, depending on the class of the PDE (Classes of PDEs).  Two of these involve internal assessment by the manufacturer, following the rules set out in the CRA, and the other two require external assessment by an approved assessment body.  
  • Risk assessment: manufacturers must perform and document an initial risk assessment across the entire supply chain for every PDE they will be making commercially available on the European market. This will be required for conformance assessment.
  • Technical documentation: manufacturers must compile technical documentation, which may include (for example) SBOMs information around supply chain, architecture, design, design processes and deployment options. This will be required for conformance assessment and some of it may be required to be made publicly available in certain circumstances.
  • Vulnerability status at release time: the CRA is clear that PDEs must “be made available on the market without known exploitable vulnerabilities”. 
  • Vulnerability management: there must be clear processes in place for vulnerability reporting and management, including releasing of updates and patches. An initial warning must be issued by manufacturers within 24 hours of their becoming aware of an actively exploited vulnerability, with further actions required at defined times.
  • Incident reporting: an initial warning must be issued by manufacturers within 24 hours of their becoming aware of an incident suspected of being caused by unlawful or malicious acts, with further actions required at defined times.
  • Free security updates: the manufacturer must make free security updates available to the public for 5 or more years in most cases.

Finding out more

For more information, we encourage you to: 

We envision a future where OSS is universally trusted, secure, and reliable. Join us in making open source more secure.

Get Involved
Close Menu