Cyber Resilience Act (CRA) Essential Guide

01/10/2025

The new Cyber Resilience Act: The New Framework for Digital Product Security

The Cyber Resilience Act (CRA) is a European Union regulation aimed at ensuring some level of cybersecurity for products with digital elements placed on the EU market depending on its criticality. Its primary objective is to enhance the overall cybersecurity posture by embedding security throughout the entire lifecycle product with digital elements from design and development to post-market support.

Why is everyone talking about CRA impact?

For manufacturers, the CRA represents a significant shift in regulatory expectations, placing clear responsibilities on them to deliver secure products by default and to manage vulnerabilities effectively over time. Understanding and complying with the CRA is essential not only for legal market access but also for maintaining customer trust, avoiding penalties, and staying competitive in an increasingly security-conscious market.

What does it mean 'placing a product on the Union market'?

Placing on the market is defined as 'making a product available on the Union market for the first time with a view to its distribution or use within the Union, whether for reward or free of charge and irrespective of the selling technique'.

According to the Blue Guide, it is important to remark that a new batch of an existing product will need to be compliant with the new requirements even if the version is the same than before the deadline.

What are the CRA legal obligations and to whom they apply?

CRA applies to manufacturers, importers and distributors and major obligations are:

Cybersecurity risk assessments: Cybersecurity risk assessments is one of the first steps to start the conformity assessment related to a product according to the intended use.
Technical documentation: Providing documentation and Technical File, including Software Bill of Materials (SBOM) or necessary information on the design and development of the product with digital elements.
Security by default: Ensuring secure default configuration and regular and free (ideally automatic) security updates.
Vulnerability Handling and disclosure process: Establishing vulnerability coordination, disclosure, and incident reporting mechanisms.
Retaining documentation and data for at least 10 years or support lifetime.

When did the CRA come into force, and when do its requirements apply?

The regulation entered into force on 10th December 2024. A transition period lasting 36 months followed:
Reporting obligations became enforceable 21 months after entry, 11th September 2026.
Technical requirements apply after another 15 months, so by 11th December 2027, full CRA compliance is expected.

It is important to remark that the reporting obligations apply to all products. According to Article 69 (3), obligations extend to all products with digital elements, even those sold before 11 Dec 2027. So, from 11 Sept 2026, any product still on the market, including those placed before 2026, must have processes to detect and report vulnerabilities.

Scope. Which products are in scope of the CRA? Is there any guidance to know how to make a categorization?

The CRA applies to “products with digital elements” (PDEs), which include both hardware and software, as well as associated remote data processing solutions. To be covered, the product’s use must foreseeably involve either a logical or a physical connection to a network or another device.

The categorization of a product under the CRA is the first step, as it determines which conformity assessment procedures will apply. The Regulation foresees different levels of assessment depending on whether a product is classified under the general default category of PDEs or falls within a higher-risk class (Important and Critical).

The different conformity assessment routes depending on the categorization are outlined in the accompanying diagram for clarity.

Check in which category your product falls in Annex III and IV of CRA text. Depending on the category, self-assessment is allowed.

Guidance is expected from the European Commission and implementing acts to help manufacturers and providers determine the correct categorization. In the meantime, the Commission has drafted the technical description of the categories of important and critical products in Draft implementing regulation - Ares (2025) 2037850 and Annex - Ares(2025)2037850 in Technical description of important and critical products with digital elements. Note that this document is still under discussion.

What products or sectors are excluded?

Excluded from CRA are product categories already regulated by specific EU frameworks:

Medical devices and invitro diagnosis medical devices (Regulation (EU) 2017/745 and (EU) No 2017/746)
Motor vehicles (Regulation (EU) 2019/2144)
Certified aviation products (Regulation (EU) 2018/1139)
Marine equipment (Directive 2014/90/EU)
Identical spare parts (spare parts that are made available on the market to replace identical components in products with digital elements and that are manufactured according to the same specifications)
Digital elements developed exclusively for national security (products with digital elements developed or modified exclusively for national security or defence purposes or to products specifically designed to process classified information)
Pure SaaS offerings may be outside scope unless they qualify as remote data processing solutions
Non monetized open-source software may also be exempt.

Be careful because pertaining to a sector does not mean you are excluded. The idea behind the CRA is that products covered by other regulations.

What is the status of Standardization Request (SR)? You are still on time to contribute! Join Standardization working groups

Standards are being built for Important (Class I and II) and Critical products, and manufacturers and stakeholders are open to contribute. Standardization request for CRA in Mandate606 shows that 41 topics shall be covered by different standards that are categorized in three types of standards:

Type “A”: Risk assessments (Horizontal framework)
- CEN/CENELEC (JTC 13 WG9)
- Topic #1 of Mandate606.
Type “B”: Product agnostic technical measures and vulnerability handling (Horizontal Framework)
- CEN/CENELEC (JTC 13 WG9)
- Topic #2-15 of Mandate606.
Type “C”: Important and Critical Products 30/10/2026
- CEN/CENELEC and ETSI for Topic #16-38 of Mandate606.
- CEN/CENELEC for topics #39-40 of Mandate606.

Type “A” does not give presumption of conformity. Types “A” and “B” serve as a basis for defining “Type C” standards, and Type C standards will later on provide presumption of conformity.

These are the expected deadlines for the standards:

Are there penalties for non-compliance?

Yes. Some of the defined non-compliance are:

Non-compliance of essential requirements: Fines up to €15 million or up to 2.5% of worldwide annual turnover.
Other non-compliance with the obligations set out in Articles like 18 to 23, Article 28, Article 30(1) to (4), Article 31(1) to (4), Article 32(1), (2) and (3), Article 33(5), and Articles 39, 41, 47, 49 and 53 shall be subject to administrative fines of up to €10 million or up to 2 % of its total worldwide annual turnover for the preceding financial year, whichever is higher.
The supply of incorrect, incomplete or misleading information to notified bodies and market surveillance authorities in reply to a request shall be subject to administrative fines of up to €5 million or, if the offender is an undertaking, up to 1 % of its total worldwide annual turnover for the preceding financial year, whichever is higher.

How does CRA affect open-source software?

The CRA includes a category for open source stewards which are those commercializing or supporting open source products. They are obligated to uphold cybersecurity policies, cooperate with authorities, and support responsible vulnerability disclosure. Non-commercial open source projects may be exempt.

Best Practices for Compliance Preparation

The best practices for CRA engagement.

Engage with trainings and workshops for CRA.
Verify and evaluate whether your products are PDEs. If so, determine their risk class (default, important or critical) and decide the conformity assessment type that can be used and better suits your type(s) of product.
Start documentation and risk assessments early. Include SBOM, technical files, and update processes which contain:
- General descriptions, indented purpose, user information, and instructions
- Risk assessment
- Support periods determination
- Reports of tests carried out to verify the conformity.
Design products with cybersecurity in mind from the beginning and in all the life cycle: secure by default configurations, best cryptographic mechanisms, secure update mechanisms, vulnerability handling, or incident reporting.
Verify the obligations for manufacturers, importers and distributors (and authorised representatives).
Engage with notified bodies or prepare for third-party assessment if products are deemed important or critical or if you do not have enough resources or knowledge to start with the conformity.
Keep detailed technical and support documentation for at least 10 years or the product’s support lifecycle.

How Applus+ Laboratories can help you?

We help our customers get ahead of compliance deadlines by offering:

Training and Workshops: Practical sessions to build your team’s knowledge of the EU Cyber Resilience Act (CRA) requirements and best general practices.
GAP analysis: Practical sessions to build your team’s knowledge of the EU Cyber Resilience Act (CRA) requirements and best practices.
Cyber Resilience Applus+ Mark: Using our FITCEM methodology, we assess your product against the CRA’s essential requirements to identify your current compliance level. This assessment serves as a clear GAP analysis, helping you understand what steps are needed to achieve full compliance.
EUCC Certification is expected to be used as a conformity assessment for critical products. Applus+ has wide experience in Common Criteria methodology.