Does the CRA apply to your product? Three questions to place it

You manufacture a connected device, you publish software, you sell an application. One question comes before all the others: does this regulation apply to you or not?

The regulation calls what it governs a "product with digital elements": a software or hardware product able to exchange data, together with the remote processing without which it could not perform its functions. Three questions help you place yours, and they come in this order. The second is where most companies get it wrong.

Two preconditions frame them: these questions assume you supply the European Union market, and that none of the exclusions set out below already covers your product.

1. Does your product exchange data?

This is the entry point. The regulation does not target everything containing electronics, but everything that communicates.

The distinction is finer than it looks, and the Commission took the trouble to spell it out: an electrical signal that triggers a function is not data. A switch that turns on a lamp carries current, not information.

For a data connection to exist, a sender must deliberately encode information and a receiver must be able to decode it. A product that stays strictly offline, exchanging nothing with any device or network, is therefore out of scope. If yours connects — even indirectly, even through a gateway, even once a month for an update — move to the next question.

2. Does your customer install it, or merely access it?

This question only concerns software. If you manufacture connected hardware — a device, a sensor, an appliance running embedded software — the answer is settled: your customer obtains it and uses it on their premises, it is a product with digital elements, and you can move straight to question 3.

The most common case deserves an immediate answer, because it is a mixed one: you sell a device, and your customers operate it from a web page you built. The device is a product, without discussion. For the web page, the question is not whether the device survives without it, but whether it carries one of its functions — commanding, configuring, pairing, updating, displaying measurements to the user. If it does, the page is absorbed into the product and follows its regime: you have a single product to qualify. The fact that the same function remains available manually does not change that answer (guidance, § 191). What stays outside is remote processing that delivers no function to the user — typically telemetry collected for statistical purposes or future product development (§ 192). The paragraphs below explain where that distinction comes from.

For software, by contrast, this is where it is decided, and where qualification errors are most frequent. The criterion is not the technology you use: it is how the product is delivered.

A downloaded mobile app, an installed desktop application, a browser extension, firmware embedded in a device — each meets those three conditions: provided, obtained, and run on the user’s own system.

Note that the Commission is explicit that this distinction predates its guidance: recitals 11 and 12 of the regulation — the introductory paragraphs setting out the legislator’s intent — already established that remote processing falls within scope only insofar as it is necessary for a product to perform its functions.

The phrase "on that basis alone" carries weight. Two very common situations pull a seemingly out-of-scope service back in.

• Your remote service supports a product’s functionality. Art. 3(1) includes within the product its remote data processing solutions, which Art. 3(2) defines by two cumulative conditions: the software is designed and developed by you or under your responsibility, and its absence would prevent the product from performing one of its functions. A portal you build to issue your device’s authentication tokens is part of the product. A third-party commercial service you depend on is not.
• You also ship an installed client. As soon as part of your offering runs on the user’s machine, it is a product — and the remote processing it depends on is absorbed into it.

A vendor whose software is reachable exclusively through a browser, with nothing to install and no associated hardware, sits outside the scope. The same vendor shipping an agent, a browser extension or a thick client falls inside it — and their remote infrastructure comes along.

3. Do you supply it in the course of a commercial activity?

Beware the most common misreading: the criterion is not sale. Art. 3(22) defines making available on the market as the supply of a product for distribution or use on the Union market in the course of a commercial activity, "whether in return for payment or free of charge".

Being free of charge is therefore not enough to fall outside. An application distributed at no cost but funded by advertising, by a paid tier, or by the exploitation of personal data is still supplied in the course of a commercial activity: the Commission illustrates this with a free marketplace earning commissions, a free virtual private network service whose servers are paid for, and a fitness tracking application conditioned on the processing of personal data.

The exception covers free and open-source software that is not monetised, and it alone.

Recital 15 characterises supply in the course of a commercial activity: charging for the product, charging for technical support beyond recovering actual costs, requiring personal data for purposes other than security, compatibility or interoperability, providing a software platform through which the manufacturer monetises other services, or accepting donations exceeding project costs.

On that last point the Commission softened its reading on 27 July 2026: merely collecting donations, even beyond costs, does not establish profit intent, and free and open-source software funded solely through donations is "unlikely" to be regarded as placed on the market (guidance, § 61). That flexibility stops where the donation conditions access: reserving binaries, updates or security fixes for donors amounts to charging for the product, and brings it into scope (§ 62).

The regulation also creates an intermediate status: the open-source software steward, defined in Art. 3 as a legal person, other than the manufacturer, providing systematic and sustained support to the development of free and open-source software intended for commercial activities — typically a foundation. Its obligations under Art. 24 are lighter, and no fine may be imposed on it. If you do not publish open-source software, this paragraph does not concern you.

Exclusions: six sectors, and a list that can grow

Six families of products fall outside the scope because other EU legislation already covers them: medical devices and in vitro diagnostic devices, motor vehicles, certified aeronautical products, marine equipment, and — since a 2025 delegated regulation — L-category vehicles, meaning two-wheelers, three-wheelers and quadricycles. That last exclusion carries an exception worth knowing: L1e-category cycles designed to pedal remain within the scope of the regulation.

Three further exclusions, often overlooked, have nothing to do with sector: spare parts replacing identical components to the same specifications (Art. 2(6)), products developed exclusively for national security or defence purposes, and products specifically designed to process classified information (Art. 2(7)).

That list is not fixed, and the regulation planned for it: Art. 2(5) empowers the Commission to add exclusions by delegated act — a text it adopts without a fresh legislative procedure, the European Parliament and the Council holding a two-month right of objection that can prevent it from entering into force (Art. 61(6)). Two cumulative conditions apply: the exclusion must be consistent with the sector’s regulatory framework, and sectoral rules must provide a level of protection equal to or higher than the CRA.

In scope: under which regime?

Not every covered product carries the same burden. The regulation sets three families — default, important (in two classes) and critical — that is, four assessment regimes. The practical difference is one question: will you need an external body to sign off on your conformity? If your product appears in none of the lists below, you fall under the default regime.

• Default regime: you assess conformity yourself, under your own responsibility. This covers most products.
• Important products, class I — 19 categories in Annex III, including browsers, password managers, antimalware software, virtual private networks, security information and event management systems, operating systems, routers and modems, connected toys with interactive or location features, and personal wearables for health monitoring outside the medical device regime.
• Important products, class II — 4 categories: hypervisors and container runtime systems, firewalls and intrusion detection and prevention systems, tamper-resistant microprocessors, tamper-resistant microcontrollers. A third party is always required, even under full standards compliance.
• Critical products — 3 categories in Annex IV: hardware devices with security boxes, smart meter gateways, and smart cards or similar devices including secure elements.

For class I, self-assessment stays available, but only if you apply harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level "substantial" or above. Harmonised standards are technical standards developed at the Commission’s request and then cited in the Official Journal: complying with them grants presumption of conformity for the requirements those standards cover, meaning the authority presumes you compliant on those points without further demonstration. Where those references are missing, a notified body steps in: an independent conformity assessment body, designated and notified by a Member State, that examines your product or your quality system (Art. 32(2)).

In practice, today, that self-assessment route is not open: no harmonised standard or common specification has been published, and the Commission has not yet designated by delegated act the certification schemes usable to demonstrate conformity with the regulation (Art. 27(9)). A manufacturer of an important product therefore goes through a third-party body.

For critical products under Annex IV, European cybersecurity certification becomes mandatory once the Commission requires it by delegated act, which presupposes that a relevant European scheme exists and is available. As long as no delegated act has been adopted — and none has to date — these products follow the class II regime: third-party assessment is mandatory (Art. 8(1) and Art. 32(4)).

One exception is worth knowing for open-source publishers: Art. 32(5) lets them stay on self-assessment even for an important product, provided the technical documentation is made public at the time of placing on the market.

What is at stake, and what small companies do not risk

Art. 64 sets three ceilings for administrative fines. Failure to meet the essential cybersecurity requirements of Annex I, or the obligations in Art. 13 and Art. 14, can reach EUR 15 million or 2.5 % of total worldwide annual turnover, whichever is higher. Other breaches cap at EUR 10 million or 2 %. Supplying incorrect information to authorities caps at EUR 5 million or 1 %.

Two limits matter for a small organisation: no fine may be imposed on a microenterprise or small enterprise for missing the twenty-four-hour early warning deadline alone, nor on an open-source software steward for any infringement whatsoever (Art. 64(10)). The thresholds are those of Recommendation 2003/361/EC, to which the regulation refers: a microenterprise employs fewer than 10 people and does not exceed EUR 2 million in annual turnover or balance sheet total; a small enterprise employs fewer than 50 people and does not exceed EUR 10 million. The headcount criterion and the financial criterion apply together. Belonging to a group, however, does not rule a company out by itself: a linked enterprise adds its group’s figures, a partner enterprise aggregates them in proportion to its holding, and the company remains a micro or small enterprise if the resulting total stays below the thresholds — unless 25 % or more of its capital or voting rights are held by public bodies, in which case the Recommendation excludes SME status regardless of size. The protection also covers only this specific deadline, not other breaches.

Your dates

The third date, 11 June 2026, has already passed: it concerned only the designation of conformity assessment bodies. Two deadlines remain.

On 11 September 2026 the reporting obligation will take effect: every actively exploited vulnerability and every severe incident will have to be notified, the first alert within twenty-four hours of your becoming aware of it. One point deserves emphasis, because it surprises: this obligation also covers products already placed on the market before 11 December 2027 (Art. 69(3)). Your existing catalogue is in scope, not only your future releases. The detail of that reporting — who receives it, what the first alert contains, how the clock runs — is covered in a separate article on this blog, devoted to Art. 14.

On 11 December 2027 the full set of essential requirements in Annex I will apply. Annex I is the list attached to the regulation setting out what a product must satisfy: being made available on the market without known exploitable vulnerabilities, a secure-by-default configuration, the ability to fix vulnerabilities through security updates, protection against unauthorised access, and confidentiality of data, among others. It comes with CE marking — the mark you affix to declare that the product meets the applicable requirements.

Where to start

If all three answers place you in scope, two actions are worth starting before 11 September 2026, because everything else depends on them.

• Know what your product is made of. The reporting obligation covers actively exploited vulnerabilities: without an inventory of your components and their versions, you cannot tell whether a published vulnerability affects you, or how fast you must act.
• Decide who receives the alert and who decides. The twenty-four-hour clock starts when you become aware of the fact. A decision chain that is not designated in advance burns that window looking for someone to call.

A few configurations remain unwritten: software built to order for a single customer, a product sold outside the Union but reachable from it, a beta distributed for testing — for the latter, Art. 4(3) provides a specific regime for the time needed to test it. None of the 67 examples in the Commission guidance addresses them. If your case is one of those, the three questions above remain the right starting point: they place you, and the analysis continues from there.