CRA FAQ

The Cyber Resilience Act (CRA) is a new EU Regulation that aims to safeguard consumers and businesses who use software or hardware products that contain software. It creates mandatory cybersecurity requirements for manufacturers and retailers that extend through those products' lifecycle and software supply chain, including all open source dependencies. It also helps consumers and business identify such products through the CE mark.

The final text of the Cyber Resilience Act (CRA) can be found on EUR-Lex (English HTML version).

The Cyber Resilience Act (CRA) entered into force on December 11, 2024. Reporting obligations of actively exploited vulnerabilities and severe incidents (Article 14) start to apply on September 11, 2026. All other obligations for software developers start to apply on December 11, 2027.

%%{init: {'theme':'base'}}%%
gantt
    title CRA Implementation Timeline
    dateFormat  YYYY-MM-DD
    axisFormat %Y
    tickInterval 1year

    Drafting phase: 2024-01-01, 2024-11-20
    Publication in the Official Journal of the EU (November 20, 2024): milestone, 2024-11-20, 5m
    Entry into force (December 11, 2024): milestone, 2024-12-11, 5m
    Implementation phase: 2024-12-11, 3y
    Notification of conformity of assessment bodies (June 11, 2026): milestone, 2026-06-11, 5m
    Reporting obligations of vulnerabilities and incidents (September 11, 2026): milestone, 2026-09-11, 5m
    All other obligations (December 11, 2027): milestone, 2027-12-11, 5m
    Application phase: 2026-09-11, 2029-06-30

The following types of products are regulated by the Cyber Resilience Act (CRA):

• Hardware products that contain software (e.g. laptops, smart appliances, mobile phones, network equipment, CPUs, etc.)
• Software products (e.g. operating systems, word processing, games or mobile apps, software libraries, etc.)
• Remote data processing solutions for any of the above, as far as those solutions are necessary for a product to perform its functions (e.g. cloud-based services that allow control of a smart lock at a distance, remote database that backs-up user preferences, etc.); See 🌐 Remote Data Processing Solutions FAQ list

The following are NOT regulated by the Cyber Resilience Act (CRA):

• Services
• Software as a service (SaaS) (already regulated by NIS 2 (Directive (EU) 2022/2555) and/or DORA (Regulation (EU) 2022/2554)) and websites, unless used to process data for a product that is regulated by the CRA (see 🌐 Remote Data Processing Solutions FAQ list)
• Products that do not contain software
• Products already covered by other regulations or directives: civil aviation equipment (already covered by Regulation (EU) 2018/1139), marine equipment (already covered by Directive (EU) 2014/90), medical devices (already covered by Regulation (EU) 2017/745 and Regulation (EU) 2017/746), and motor vehicles (already covered by Regulation (EU) 2019/2144)
• Products exclusively designed for national security or defence purposes
• Products specifically designed to process classified information

It is worth noting however, that the intent of the EU legislators is to harmonize the various regulations mentioned above with the CRA in the near future.

The CE mark is a distinctive symbol indicating that a product complies with the relevant EU product regulations. Under the CRA, only manufacturers are authorized to add the CE mark to a product. Open source software stewards and developers outside the scope of the CRA cannot do so.

Article 30 of the CRA outlines how manufactures need to add the CE mark to the their product.

For hardware, the CE mark must be placed directly on the product. If this is not possible, it must be placed on the packaging and in the EU declaration of conformity.

For software, the CE mark must appear either in the EU declaration of conformity or on a website accompanying the software product, provided it is easily accessible to consumers.

Failure to properly add the CE mark may result in financial penalties.

The CRA Expert Group is a consultative body set up by the European Commission to provide it with advice and expertise during the implementation of the CRA. It is composed of 60 members which include:

• individual experts appointed in their personal capacities,
• industry representatives,
• trade and business associations,
• NGOs,
• member state authorities (plus the Norwegian Communications Authority), and
• ENISA.

Open source is particularly well represented, as the following open source organizations are members:

• the Apache Software Foundation,
• the Eclipse Foundation,
• OpenSSF, and
• the Sovereign Tech Agency.

As described in Article 9, the CRA Expert Group is consulted by the European Commission as it:

• prepares Guidance as described in Article 26,
• prepares the technical descriptions of the important and critical product categories described in Article 7 and Article 8, and listed in Annex III and Annex IV respectively, and
• undertakes preparatory work for the evaluation and review of the CRA.

In practice, the CRA Expert Group meets in plenary sessions 2-3 times a year. It has multiple work strands on specific topics, including one on open source, which meet on an ad-hoc basis. The agenda and minutes of the plenary sessions are public and are available on the CRA Expert Group's offical page. Draft regulation and guidance shared with the CRA Expert Group may not be shared publicly until it is officially published.

You can find an explainer on expert groups in general on the European Commission's website.

Under the CRA, 'making a profit' means earning more money than actual costs. This distinction is important because accepting donations or charging for services without the intention of making a profit is not considered a commercial activity.

What counts as 'actual costs' differs depending on who is receiving the funds:

• For individual maintainers, actual costs include expenses related to the design, development, and maintenance of the software, as well as reasonable living expenses. A natural person covering their costs and earning a fair remuneration is not considered to be making a profit on that basis alone.
• For organisations, actual costs include operational expenses, reasonable compensation for contributors and staff, and other costs associated with the design, development, and provision of the software.

Importantly, not-for-profit organisations that invest all earnings after costs back into achieving their not-for-profit objectives are not considered to be supplying software in the course of a commercial activity, even if they're making a profit (Recital 18).

Under the CRA, 'actual costs' refers to the legitimate expenses associated with designing, developing, maintaining, and providing software. These costs can be recovered through donations or fees for technical support without triggering commercial activity status.

For individual maintainers, actual costs include:

• Expenses related to design, development, and maintenance of the software
• Reasonable living expenses — a natural person covering their costs and earning a fair remuneration through support services or donations is not considered to be monetising the software on that basis alone

For legal persons (such as foundations or companies), actual costs include:

• Costs associated with design, development, and provision of the software
• Reasonable compensation for contributors and developers employed by the organisation

The key distinction is that recovering actual costs is not considered commercial activity, while significantly exceeding those costs — particularly with an intention to make a profit — may indicate the software is being supplied in the course of a commercial activity (Recital 15).

This flexibility is important because donations naturally fluctuate over time. Whether someone intends to make a profit should be assessed by considering the broader financial situation over time, not just isolated instances where income temporarily exceeds expenses.

See also: Can a natural person's living expenses count as 'costs' or is that profit? and What does 'make a profit' mean under the CRA?.

Under the CRA, 'intention to monetise' refers to the goal of generating revenue from a product, even when the product itself is provided free of charge. This concept helps determine whether software is being supplied in the course of a commercial activity.

Recital 15 provides several examples of monetisation that go beyond directly charging for a product:

• Monetising related services: Providing a software platform through which the manufacturer monetises other services
• Monetising user data: Requiring the processing of personal data as a condition for use, for reasons other than exclusively improving the security, compatibility, or interoperability of the software
• Monetising support: Charging for technical support services beyond the recuperation of actual costs
• Excessive donations: Accepting donations beyond the recuperation of actual costs

The key distinction is whether revenue generation is a purpose of making the software available, rather than simply a means of covering legitimate development and maintenance costs.

For more on related concepts, see What does 'actual costs' mean under the CRA? and What does 'make a profit' mean under the CRA?.

Freeware that is not free and open-source software (FOSS) is treated differently under the CRA. Unlike FOSS, which benefits from specific exemptions based on how it is developed and distributed, non-FOSS freeware does not qualify for these carve-outs.

The CRA's special provisions for open source apply only to software that meets the definition of "free and open-source software"—meaning software whose source code is openly shared under a licence that allows it to be freely accessible, usable, modifiable, and redistributable (Article 3(48)). Freeware that is distributed free of charge but without open source code and licensing does not meet this definition.

For freeware, the key question is whether it is supplied "in the course of a commercial activity" (Article 3(22)). Even software provided free of charge can fall within the CRA's scope if there is commercial intent—for example, if the software is used to monetise other services, collects personal data for non-security purposes, or serves as part of a broader business model.

If freeware is supplied in the course of a commercial activity, the person or entity distributing it under their name or trademark would be considered a manufacturer and must comply with full CRA obligations, including conformity assessment and CE marking requirements. The fact that no price is charged does not, by itself, place the software outside the CRA's scope.

For more on what constitutes commercial activity, see What does 'intention to monetise' mean under the CRA?.