Chapter I - GENERAL PROVISIONS

Article 2

Scope

Regulation (EU) 2024/2847 — published 10 December 2024 · Last reviewed by Kunnus: March 2026

(1)

This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.

(2)

This Regulation does not apply to products with digital elements to which the following Union legal acts apply:

Regulation (EU) 2017/745;

Regulation (EU) 2017/746;

Regulation (EU) 2019/2144.

(3)

This Regulation does not apply to products with digital elements that have been certified in accordance with Regulation (EU) 2018/1139.

(4)

This Regulation does not apply to equipment that falls within the scope of Directive 2014/90/EU of the European Parliament and of the Council (36).

(5)

The application of this Regulation to products with digital elements covered by other Union rules laying down requirements that address all or some of the risks covered by the essential cybersecurity requirements set out in Annex I may be limited or excluded where:

such limitation or exclusion is consistent with the overall regulatory framework that applies to those products; and

the sectoral rules achieve the same or a higher level of protection as that provided for by this Regulation.

The Commission is empowered to adopt delegated acts in accordance with Article 61 to supplement this Regulation by specifying whether such limitation or exclusion is necessary, the products and rules concerned, as well as the scope of the limitation, if relevant.

(6)

This Regulation does not apply to 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 as the components that they are intended to replace.

(7)

This Regulation does not apply to products with digital elements developed or modified exclusively for national security or defence purposes or to products specifically designed to process classified information.

(8)

The obligations laid down in this Regulation shall not entail the supply of information the disclosure of which would be contrary to the essential interests of Member States’ national security, public security or defence.

European Commission Interpretation

Guidance of 27 July 2026

The EU Commission guidance of 27 July 2026 provides official interpretation notes on this provision. Each section: summary, key takeaways, and what it means for you in practice.

Section 2.1Placing standalone software on the market

Standalone software is placed on the market once its manufacturing phase is complete and it is first offered for distribution or use on the EU market. All copies of the same version are considered placed on the market at the same time — regardless of when individual users download them.

Key takeaways

The moment of first offering counts for all copies of a version — later downloads are merely instances of 'making available' the same products.
Iterations that are not substantial modifications do not shift the date of placing on the market; only a substantial modification counts as a new placing on the market (see Chapter 4 of the guidance).
Variants that differ in included components, configurations or enabled functionalities (e.g. builds per operating system, differing feature bundles) are distinct products.

Example from the guidance

Version 1.0.0 is first offered via the website on 1 January 2028. Customer 1 buys the same day, customer 2 on 15 January. Both copies are considered placed on the market on 1 January 2028 (Example 1 of the guidance).

In practice

Record the date each software version is first offered — it determines when CRA obligations start for all copies of that version. Also keep a list of your variants (builds per operating system, feature bundles): each variant is a separate product with its own date.

Section in the guidance overview

Section 2.2Software as a product — web apps and websites

Software is a product with digital elements only where it is supplied to the user and executes on the user's system. Web applications accessed exclusively through a browser and purely informational websites are not themselves products — they fall within scope only as remote data processing where they support a function of a product.

Key takeaways

Locally installed applications are products — including browser extensions and desktop apps built with web technologies but supplied for local execution.
Web apps and progressive web apps accessed exclusively through a browser are not products with digital elements (recitals 11 and 12).
A locally installed client plus the data processing at a distance it relies on for its functions together constitute the product.

In practice

Sort your portfolio into three buckets: (1) runs locally on the user's device (app, desktop client, browser extension) → a product under the CRA; (2) browser-only web app or informational website → not a product; (3) a back-end supporting a product function → assess as remote data processing (Chapter 8 of the guidance).

Section in the guidance overview

Section 2.5Data connection — distinguishing mere electronics

The CRA's scope is anchored in a data connection, not the mere presence of electronics. A data connection requires binary states to be deliberately encoded as information by a sender and capable of being decoded as data by a receiver. Electrical signals that merely trigger or power a function do not bring a product within scope.

Key takeaways

Merely switching an output on and off (0/1) is not a data connection where those states are not intended to represent data.
Required: a sender deliberately generating digital symbols according to a defined scheme, and a receiver capable of interpreting them as data.
The boundary separates products that participate in digital communication (and are exposed to cyber risks) from products merely using electrical signals.

In practice

Ask a single question per product: does it deliberately send or receive encoded data (protocol, bus, radio, serial interface)? Only then is it within CRA scope. Products that merely switch signals or carry power can be documented out of scope on that basis.

Section in the guidance overview

Section 3.1 – 3.2Open source: when is FOSS 'placed on the market'?

What matters is monetisation by the person responsible (the maintainer), not how development was financed: charging for binaries, monetising other services through the software, requiring personal-data processing, or paid editions bundled with support benefits mean placing on the market. Voluntary donations, optional consultancy and third-party sponsoring do not, on their own, trigger CRA scope.

Key takeaways

The FOSS definition (Art. 3(48)) cumulatively requires a FOSS licence granting the full set of rights AND openly shared source code — code shared only with paying customers is not FOSS.
Responsibility lies with whoever controls releases, roadmap and distribution; contributors without that control are not subject to the CRA, even with commit access (Example 13).
A community version and a paid (open-core) version are two distinct products — the free version remains off-market.
Optional paid services (consulting, training, deployment help) are harmless; paid access to a version bundled with technical support is monetisation (Examples 17/18).
Donations only become critical where they are de facto a condition of access — e.g. releases or security fixes only for donors (Examples 21/22); cost recovery including reasonable living expenses is permissible.
Third-party financing (grants, bug bounties, paid feature development) does not make FOSS commercial (recital 18, Example 23).

In practice

Go through your open-source projects one by one and answer two questions: do we control releases and distribution? And do we monetise this specific version (price, monetisation through the software, mandatory data processing, paid edition with support)? Only two yeses make you a manufacturer. A donation link, sponsoring and optional consultancy change nothing.

Section in the guidance overview

Section 4.1 – 4.2Physical repairs and spare parts

Repair, refurbishment and maintenance generally do not amount to a substantial modification as long as the intended purpose and level of risk remain unchanged. The spare-parts exemption (Art. 2(6)) applies only where the part is demonstrably supplied to repair an existing product; 'identical' is measured against security-relevant characteristics, not physical sameness.

Key takeaways

Replacing a defective part with a better-performing one is not in itself a substantial modification (Example 35: faster RAM in a server).
A new chipset using the same protocols and security mechanisms can be 'identical' (Example 38); a different cryptographic implementation or secure-boot mechanism cannot (Example 37).
The repair purpose must be apparent from the supply context (product identified in the order/offer, after-sales channel) — keep supporting evidence for market surveillance.
The exemption also covers replacing entire modules or sub-products within larger systems (Example 39: CPU unit or complete PLC).

In practice

For every spare part, document the repair context (product identified in the order/offer, supply via after-sales channel) and compare security-relevant characteristics — crypto, protocols, secure boot, access controls — rather than part numbers. Only then can you demonstrate the Art. 2(6) exemption to market surveillance.

Section in the guidance overview

Section 8.1What counts as a remote data processing solution (RDPS)?

Remote data processing is part of the product where three criteria are cumulatively met: processing 'at a distance', functional necessity (without it the product could not perform one of its functions), and development by or under the responsibility of the manufacturer. The guidance turns this into two test questions with a decision flowchart.

Key takeaways

'Who operates it' is irrelevant: on-premises or private-cloud solutions can qualify as RDPS just like public-cloud solutions.
'Functions' means more than core functionality: onboarding, file sync, configuration, automated update distribution and identity/access management all count.
Telemetry purely for statistics or future product development is not RDPS — but the risks of such remote components still belong in the risk assessment.
IaaS/PaaS: where the manufacturer's own (or commissioned) software runs on third-party infrastructure, it can be RDPS; standard third-party SaaS is not RDPS but must be treated like a third-party component (mitigate risks + due diligence).
'Under the manufacturer's responsibility' = tailor-made for the manufacturer to its designs/specifications — not merely licensing an existing service.
Internal systems (HR, CRM, CI/CD pipelines, update distribution to edge locations, pentest/red-team infrastructure) are not RDPS.
Websites only where they support a function: an authentication portal issuing tokens for the product can be RDPS — an informational website is not, even if the product links to it.

In practice

Answer two questions per cloud/back-end service: (1) would a product function fail without it (including onboarding, sync, updates, login)? (2) was the software developed by us or to our specifications? Two yeses → part of your product, belongs in the risk and conformity assessment. Only question 1 yes (e.g. standard SaaS) → treat as a third-party component: mitigate risks plus due diligence.

Section in the guidance overview

Section 9.3Interplay with other EU law: vehicles, RED, Machinery Regulation

Vehicle components (Regulation (EU) 2019/2144, Regulation (EU) No 168/2013) are exempt from the CRA where they are exclusively designed, constructed and suitable for integration into such vehicles — generic components sold through open distribution channels fall within the CRA regardless of intended-use statements. EU type-examination certificates covering cybersecurity requirements (e.g. RED Delegated Act, Machinery Regulation) remain usable as evidence of conformity for the covered risks until 11 June 2028 at the latest.

Key takeaways

The objective conditions of supply are decisive: sale through general retail/online channels open to the public argues against the vehicle exemption; restricted B2B channels within the automotive supply chain support it.
Existing certificates (RED DA, Machinery Regulation Annex III 1.1.9/1.2.1) do not replace the CRA risk assessment — they only serve as evidence for the risks they cover.
CRA risks not covered by the certificate (e.g. vulnerability handling processes, data minimisation, attack surface reduction) must be addressed additionally.

In practice

Check your distribution channels: components also sold outside the automotive supply chain (retail, open online shop) fall under the CRA — regardless of what the datasheet says about intended use. Also inventory your RED/Machinery Regulation certificates: they count as CRA evidence only for the risks they cover and until 11 June 2028 at the latest — plan the gap closure now.

Section in the guidance overview

Browse all guidance chapters

EU Commission Guidance (C(2026) 5252 final) — The guidance reflects the European Commission's interpretation and is not legally binding. An authoritative interpretation of the EU CRA may only be given by the Court of Justice of the European Union.

Related Recitals

(14)

CRA updates by email

Deadlines, official guidance, and myth-busting fact-checks on the Cyber Resilience Act — compact in our newsletter.

View newsletters

This text is reproduced from Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024. It is provided for informational purposes only and does not constitute legal advice. Only the text published in the Official Journal of the European Union is legally binding. Original text on EUR-Lex