Chapter I - GENERAL PROVISIONS

Article 3

Definitions

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

For the purposes of this Regulation, the following definitions apply:

(1)

‘product with digital elements’ means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately;

(2)

‘remote data processing’ means data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions;

(3)

‘cybersecurity’ means cybersecurity as defined in Article 2, point (1), of Regulation (EU) 2019/881;

(4)

‘software’ means the part of an electronic information system which consists of computer code;

(5)

‘hardware’ means a physical electronic information system, or parts thereof capable of processing, storing or transmitting digital data;

(6)

‘component’ means software or hardware intended for integration into an electronic information system;

(7)

‘electronic information system’ means a system, including electrical or electronic equipment, capable of processing, storing or transmitting digital data;

(8)

‘logical connection’ means a virtual representation of a data connection implemented through a software interface;

(9)

‘physical connection’ means a connection between electronic information systems or components implemented using physical means, including through electrical, optical or mechanical interfaces, wires or radio waves;

(10)

‘indirect connection’ means a connection to a device or network, which does not take place directly but rather as part of a larger system that is directly connectable to such device or network;

(11)

‘end-point’ means any device that is connected to a network and serves as an entry point to that network;

(12)

‘economic operator’ means the manufacturer, the authorised representative, the importer, the distributor, or other natural or legal person who is subject to obligations in relation to the manufacture of products with digital elements or to the making available of products with digital elements on the market in accordance with this Regulation;

(13)

‘manufacturer’ means a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge;

(14)

‘open-source software steward’ means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products;

(15)

‘authorised representative’ means a natural or legal person established within the Union who has received a written mandate from a manufacturer to act on its behalf in relation to specified tasks;

(16)

‘importer’ means a natural or legal person established in the Union who places on the market a product with digital elements that bears the name or trademark of a natural or legal person established outside the Union;

(17)

‘distributor’ means a natural or legal person in the supply chain, other than the manufacturer or the importer, that makes a product with digital elements available on the Union market without affecting its properties;

(18)

‘consumer’ means a natural person who acts for purposes which are outside that person’s trade, business, craft or profession;

(19)

‘microenterprises’, ‘small enterprises’ and ‘medium-sized enterprises’ mean, respectively, microenterprises, small enterprises and medium-sized enterprises as defined in the Annex to Recommendation 2003/361/EC;

(20)

‘support period’ means the period during which a manufacturer is required to ensure that vulnerabilities of a product with digital elements are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I;

(21)

‘placing on the market’ means the first making available of a product with digital elements on the Union market;

(22)

‘making available on the market’ means the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge;

(23)

‘intended purpose’ means the use for which a product with digital elements is intended by the manufacturer, including the specific context and conditions of use, as specified in the information supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation;

(24)

‘reasonably foreseeable use’ means use that is not necessarily the intended purpose supplied by the manufacturer in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation, but which is likely to result from reasonably foreseeable human behaviour or technical operations or interactions;

(25)

‘reasonably foreseeable misuse’ means the use of a product with digital elements in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or interaction with other systems;

(26)

‘notifying authority’ means the national authority responsible for setting up and carrying out the necessary procedures for the assessment, designation and notification of conformity assessment bodies and for their monitoring;

(27)

‘conformity assessment’ means the process of verifying whether the essential cybersecurity requirements set out in Annex I have been fulfilled;

(28)

‘conformity assessment body’ means a conformity assessment body as defined in Article 2, point (13), of Regulation (EC) No 765/2008;

(29)

‘notified body’ means a conformity assessment body designated in accordance with Article 43 and other relevant Union harmonisation legislation;

(30)

‘substantial modification’ means a change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I or which results in a modification to the intended purpose for which the product with digital elements has been assessed;

(31)

‘CE marking’ means a marking by which a manufacturer indicates that a product with digital elements and the processes put in place by the manufacturer are in conformity with the essential cybersecurity requirements set out in Annex I and other applicable Union harmonisation legislation providing for its affixing;

(32)

‘Union harmonisation legislation’ means Union legislation listed in Annex I to Regulation (EU) 2019/1020 and any other Union legislation harmonising the conditions for the marketing of products to which that Regulation applies;

(33)

‘market surveillance authority’ means a market surveillance authority as defined in Article 3, point (4), of Regulation (EU) 2019/1020;

(34)

‘international standard’ means an international standard as defined in Article 2, point (1)(a), of Regulation (EU) No 1025/2012;

(35)

‘European standard’ means a European standard as defined in Article 2, point (1)(b), of Regulation (EU) No 1025/2012;

(36)

‘harmonised standard’ means a harmonised standard as defined in Article 2, point (1)(c), of Regulation (EU) No 1025/2012;

(37)

‘cybersecurity risk’ means the potential for loss or disruption caused by an incident and is to be expressed as a combination of the magnitude of such loss or disruption and the likelihood of occurrence of the incident;

(38)

‘significant cybersecurity risk’ means a cybersecurity risk which, based on its technical characteristics, can be assumed to have a high likelihood of an incident that could lead to a severe negative impact, including by causing considerable material or non-material loss or disruption;

(39)

‘software bill of materials’ means a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements;

(40)

‘vulnerability’ means a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat;

(41)

‘exploitable vulnerability’ means a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions;

(42)

‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner;

(43)

‘incident’ means an incident as defined in Article 6, point (6), of Directive (EU) 2022/2555;

(44)

‘incident having an impact on the security of the product with digital elements’ means an incident that negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of data or functions;

(45)

‘near miss’ means a near miss as defined in Article 6, point (5), of Directive (EU) 2022/2555;

(46)

‘cyber threat’ means a cyber threat as defined in Article 2, point (8), of Regulation (EU) 2019/881;

(47)

‘personal data’ means personal data as defined in Article 4, point (1), of Regulation (EU) 2016/679;

(48)

‘free and open-source software’ means software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable;

(49)

‘recall’ means recall as defined in Article 3, point (22), of Regulation (EU) 2019/1020;

(50)

‘withdrawal’ means withdrawal as defined in Article 3, point (23), of Regulation (EU) 2019/1020;

(51)

‘CSIRT designated as coordinator’ means a CSIRT designated as coordinator pursuant to Article 12(1) of Directive (EU) 2022/2555.

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.3Computer code — source code and machine code

Both machine code and source code are 'software' within the meaning of Article 3(4). What matters is whether the supply occurs in the course of a commercial activity: openly shared FOSS code, unfinished code during development, and demo or tutorial code are not considered placed on the market — source code licensed commercially to customers is.

Key takeaways

Supplying source code to customers as a product places it on the market — even where the customer must adapt and compile it first (Example 7).
The licensor is not responsible for CRA compliance of the customer's downstream adaptations.
Unfinished software (alpha, beta, release candidates) may be made available under Article 4(3) for the time necessary for testing and feedback.

In practice

Review your licence and supply contracts: where do you provide customers with source code for remuneration? You bear full manufacturer obligations for that code — but not for what the customer builds from it. Demo code, tutorials and beta versions for testing remain out of scope.

Section in the guidance overview

Section 2.4Hardware and software forming one product

Whether software forms part of a product is determined not by how it is delivered, but by whether it is necessary for the product to perform its intended functions. Separately obtained drivers and companion apps (e.g. from an app store) together with the hardware constitute a single product with digital elements.

Key takeaways

Network printer + downloadable drivers = one product, because the printer cannot fulfil its purpose without the drivers (Example 8).
Fitness wearable + companion app = one product, because they are designed to operate together (Example 9).
The software is placed on the market at the same point in time as the hardware units.

In practice

Assign every companion app and driver to its hardware product: they belong in that product's risk assessment, SBOM, technical documentation and conformity assessment — not in one of their own. The delivery channel (app store, download link) is irrelevant.

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.3Software updates as substantial modifications

The yardstick is not the scale of the change but its effect on the risk profile: where an update alters the assessed intended purpose or introduces new risks not covered by the risk assessment, it is a substantial modification. Security updates generally are not. Four assessment criteria (para. 110) structure the case-by-case analysis.

Key takeaways

Features already anticipated and assessed in the original risk assessment do not trigger a substantial modification — nor does later activation of assessed, dormant functionality (Examples 42/43).
Even small features can be substantial: a 'remember me' login storing tokens locally introduces new risks (token theft, session hijacking — Example 44).
Security updates are substantial only exceptionally — e.g. where they fundamentally alter the intended purpose, data flows or dependency structure (Examples 49/50: local encryption becomes a cloud service; external key management replaces internal).
Assessment criteria (para. 110): new threat vectors, new attack scenarios, changed likelihood, changed impact of known scenarios.
Regardless of classification: the risk assessment and technical documentation must be kept continuously up to date (Art. 13(7), Art. 31(2)).

In practice

Anchor a fixed review question with a documented answer in your release process: does this update introduce new threat vectors or attack scenarios, or change the likelihood/impact of known ones? No, and covered by the risk assessment → no new placing on the market. Yes → update the risk assessment and check whether a new conformity assessment is due.

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 8.3Five RDPS use cases: banking app, thermostat, e-reader, robot, cellular network

Five worked cases illustrate the boundary: for a mobile banking app, the self-developed banking interface is RDPS, downstream ledger/account systems are not, and the third-party SaaS support chat is a third-party component. Smart thermostat and industrial robot: the manufacturer's own cloud software on third-party IaaS is RDPS. E-reader: third-party SaaS storage is not RDPS but must be treated as a component. The cellular network is a mere communication channel — no RDPS, no due diligence required.

Key takeaways

The CRA covers only the parts of the system the product directly interacts with — risks from systems behind them (e.g. a compromised ledger) must be mitigated at product level (strong back-end authentication, integrity protection, secure channels).
With third-party IaaS: document the RDPS and the IaaS reliance in the technical documentation; obtain e.g. NIS 2 evidence from the provider.
Network infrastructure (5G, ethernet, Wi-Fi, routers) is a communication enabler, not data processing whose absence would prevent a product function.

In practice

Map your own setup to the closest of the Commission's five use cases (banking app, smart thermostat, e-reader, industrial robot, cellular network) and adopt its logic: what interacts directly with the product and was developed by you is RDPS; systems behind it are external dependencies; pure network infrastructure is neither. In most cases this replaces an expensive bespoke legal opinion.

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

(7)

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