The Cyber Resilience Act: What It Covers and Who It Binds

Most EU digital rules bind organisations or data. The Cyber Resilience Act, Regulation (EU) 2024/2847, binds products. It sits inside the New Legislative Framework, the same machinery that governs toys, lifts and radio equipment: meet essential requirements, assess conformity, draw up a declaration, affix a CE mark, then place the product on the market. What is new is the subject matter. For the first time, software and connected hardware carry a CE mark for cybersecurity.

The distinction decides who has to do the work.

An organisation can sit outside NIS2 entirely and still ship a product squarely inside the CRA. Scoping the company tells you nothing about scoping the catalogue.

Article 3 defines a product with digital elements as a software or hardware product and its remote data processing solutions, including components placed on the market separately. Two conditions bring it into scope.

First, it must be made available on the market, meaning supplied for distribution or use in the course of a commercial activity. Second, its intended purpose or reasonably foreseeable use must include a direct or indirect logical or physical data connection to a device or network.

The connection test is deliberately wide. Indirect covers a sensor that never touches a network itself but writes to a gateway that does. Logical covers software talking to software with no cable involved. A standalone offline calculator is out; almost nothing else a modern vendor ships is.

Separately placed components count too, so a library sold as a product is assessed as a product, not absorbed into whatever integrates it.

The definition pulls in remote data processing solutions, and this is the provision engineering teams most often read past.

If a device or application depends on a vendor-operated backend to perform its function, that backend is part of the product. Not an adjacent service governed by other rules. Part of the product, inside the same conformity assessment, the same technical documentation, the same support period.

The test is functional necessity. Telemetry you collect for your own analytics is not the product's function. The message relay without which your chat client cannot deliver a message is.

This cuts against how most teams organise. Firmware and cloud usually sit in different repositories, different release trains, often different business units. The CRA asks for one coherent security story across the boundary, which means the risk assessment has to cross it too.

Pure software as a service with no product attached stays outside the CRA, though it may sit inside NIS2.

The CRA yields where existing sector law already imposes cybersecurity requirements, so the same product is not assessed twice against two regimes.

Excluded on that basis: medical devices and in-vitro diagnostic devices, motor vehicles, civil aviation equipment, and marine equipment. Each has its own framework. Also excluded are spare parts that restore a product to its original function, products developed or modified exclusively for national security or defence purposes, and products designed exclusively to process classified information.

The list is not frozen. The Commission can narrow scope by delegated act, and has: Commission Delegated Regulation (EU) 2025/1535 removed certain vehicles covered by Regulation (EU) No 168/2013.

The practical error is assuming an exclusion travels. A hospital ships an infusion pump regulated as a medical device and a separate ward-management tablet application. The pump is out. The tablet application is an ordinary product with digital elements, fully in scope.

The CRA does not regulate open source as such. It regulates supply in the course of a commercial activity, and that line runs through the ecosystem rather than around it.

A maintainer publishing a library for anyone to use is not a manufacturer and carries no CRA obligations. A company that takes that library, integrates it and sells the result is a manufacturer, and its due diligence duty on third-party components travels with it. The obligation follows the money, not the licence.

Between those poles, Article 24 creates a role with no equivalent in earlier product law: the open-source software steward. A steward is a legal person, typically a foundation, that systematically provides sustained support for the development of open-source products intended for commercial activities and ensures their viability.

Stewards carry a reduced set of duties: a cybersecurity policy, cooperation with market surveillance authorities, and reporting of actively exploited vulnerabilities in products they help develop. They are not subject to CRA penalties at all.

Scoping runs in two passes, and running them in the wrong order wastes effort.

The first pass asks whether the CRA applies at all. Commercial supply, then a data connection, then whether sector law has already claimed the product. Anything that survives all three is in scope, and every in-scope product owes the same Annex I essential requirements.

Only then does the second pass matter: which tier. The tier is read off two lists. Annex IV names critical products. Annex III splits important products into class II and class I. A product in neither annex sits in the default category, which is where most of the market lands.

The order matters because the tier question is the one people start with, and it is the cheaper question. Tier changes how much independent scrutiny your conformity assessment needs. It never changes what the product itself has to do.

The default category holds most products: ordinary business software, consumer devices with no security-specific role.

Annex III lists important products in two classes. Class I has nineteen entries, weighted toward things that guard other things. Identity and privileged access management, browsers, password managers, malware detection software, VPN products, network management and SIEM systems, boot managers, public key infrastructure and certificate issuance software, network interfaces, operating systems, internet-connected routers, modems and switches, microprocessors and microcontrollers with security functionality, ASICs and FPGAs with security functions, smart home assistants, smart home security products such as door locks and cameras, internet-connected toys with interactive or location-tracking features, and personal wearable health monitors.

Class II has four entries: hypervisors and container runtime systems, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors, and tamper-resistant microcontrollers.

Annex IV lists three critical categories: hardware devices with security boxes, smart meter gateways, and smartcards or similar devices including secure elements.

Commission Implementing Regulation (EU) 2025/2392 supplies the technical descriptions that decide borderline cases.

Take a mid-sized vendor shipping four things.

A team chat desktop application. Commercially supplied, network connected, not in either annex. Default category.

A password manager. Annex III class I. Identical Annex I requirements, restricted conformity route.

A container runtime shipped inside a platform product. Annex III class II. Third-party assessment is mandatory unless a European cybersecurity certification scheme covers it, or the manufacturer qualifies for the open-source documentation route.

The cloud backend the chat application needs to deliver messages. Not a fourth product. It is a remote data processing solution and forms part of the chat application.

Notice what did not move anything. Not company size, not revenue, not how sensitive the data is, not whether customers are regulated. The tier follows the product's function, and only its function. A tiny vendor's password manager sits in class I while a large vendor's project tracker sits in the default category.

The manufacturer carries nearly all the weight: risk assessment, essential requirements, due diligence on third-party components, technical documentation, conformity assessment, the declaration, the CE mark, and reporting.

Importers verify before placing a product on the market that the manufacturer performed the assessment, drew up documentation, and affixed the CE mark. Distributors check the lighter, visible signals: CE marking, contact details, user instructions, and a stated support period.

The trap is role migration. Two acts turn you into a manufacturer for a product you did not build. Placing it on the market under your own name or trademark. Making a substantial modification to it.

A reseller who rebrands a white-label camera inherits the complete Annex I obligation set for hardware it did not design, including vulnerability handling and security updates across the whole support period. That is a due diligence question at supplier selection, not a labelling question at launch.

The Regulation entered into force on 10 December 2024 and applies in stages.

From 11 June 2026, Chapter IV applies. Member States designate notifying authorities and conformity assessment bodies can be notified. This is infrastructure, not a manufacturer obligation.

From 11 September 2026, the Article 14 reporting obligations apply.

From 11 December 2027, the main obligations apply: essential requirements, conformity assessment, technical documentation, CE marking.

Two transitional details reorder the work queue. Reporting applies to all products made available on the Union market, including those placed on it before 11 December 2027, so it reaches the estate you already shipped. Meanwhile products placed on the market before that date escape the main obligations until they undergo a substantial modification.

The consequence is counter-intuitive. The first duty to bite is operational rather than architectural, it applies to legacy products, and it needs a process staffed around the clock.

Three things are new for teams that have never worked under product law.

Evidence becomes a deliverable. Annex VII technical documentation is not a report written before launch and filed. It is a maintained record of architecture, risk assessment, the software bill of materials, and the reasoning behind the support period, which a market surveillance authority can demand.

The support period becomes a public commitment. Article 13 sets a floor of five years, or the expected use time where that is shorter, stated clearly with month and year at the time of purchase. End-of-life stops being a business decision made quietly.

Vulnerability handling becomes a legal duty rather than a practice. Annex I Part II requires a coordinated disclosure policy, a contact address for reports, regular testing, and security updates disseminated without delay and free of charge.

None of this is unusual engineering. What is unusual is that it is now enforceable against the product.