Cyber Resilience Act: the questions that matter

The CRA covers "products with digital elements" — hardware or software whose intended use includes a direct or indirect data connection to another device or a network — made available on the Union market. The perimeter is wide: not only connected devices, but the software that runs them. Products already covered by equivalent sector rules (medical devices, aviation, automotive) are carved out.

Rule of thumb: if you sell something in the EU that connects or communicates, assume it is in scope and check the exclusions, not the other way round.

Software placed on the market as a product is in scope, even when sold separately from hardware. Cloud/SaaS offerings, as services, are not the CRA’s object (service security is NIS2 territory), but the "remote data processing solutions" required for the product to work — the server side without which the device cannot do its job — fall within the product perimeter.

The distinction that matters is not "on-premise vs cloud" but "product vs service": what counts is what you place on the market.

Free and open source software developed or supplied outside a commercial activity is not in scope. When it is monetised or integrated into a commercial product, the obligations sit with whoever places that product on the market. The CRA also introduces the "open source software steward" (foundations and bodies supporting projects used in commercial products) under a lighter, proportionate regime.

For product makers: using an open source library does not shift CRA responsibility upstream. It stays with you, on the finished product.

Yes, if the product is made available on the Union market. The CRA follows the product, not the manufacturer’s location. Along the chain, importers and distributors have their own due-diligence duties (CE marking, documentation, declared support period) and cannot place non-compliant products.

In practice a non-EU manufacturer needs a counterparty in the European chain answering for these duties.

From this date Article 14 applies: the duty to report actively exploited vulnerabilities and severe incidents, on an hourly clock — early warning within 24h, notification within 72h, final report within 14 days. It also applies to products already on the market.

What you must have done is not "a compliant product" but a process: who is authorised to notify, an active EU Login account, the channel to ENISA’s single platform, and a traceable log. A company without this process is not behind on the CRA — it is exposed to a deadline that is already live.

The SBOM (Software Bill of Materials) is the inventory of the product’s software components, including third-party dependencies. The CRA requires drawing it up and keeping it in a machine-readable format, at least at the top level of dependencies, and using it to manage vulnerabilities. There is no general duty to publish it: it exists to keep control of what is inside the product and to react when a component becomes vulnerable.

For the whole "support period", which the manufacturer sets based on how long the product is expected to be in use. The Commission’s reference point is at least five years, unless the product’s expected lifetime is shorter. During that period, security updates must be provided promptly and free of charge. The support period must be declared: it becomes information that travels with the product, not an internal choice.

It depends on the product class. For most products ("default" class) self-assessment of conformity is enough. For "important" products (Annex III) you must apply harmonised standards — which grant a presumption of conformity — or go through a third party. For "critical" products (Annex IV) the strictest route applies, up to European certification. You do not guess the class: you derive it from the annexes.

The regulation entered into force on 10 December 2024 but applies in stages. Three dates: from 11 June 2026 notified bodies can be designated; from 11 September 2026 the Article 14 reporting duty starts; from 11 December 2027 all substantive requirements and CE marking apply. Read them by urgency, not by calendar: September 2026 is a process problem to solve now, December 2027 a design problem to win earlier.

Penalties come in tiers. Breaching the essential cybersecurity requirements and the vulnerability-handling obligations can reach up to €15 million or 2.5% of annual worldwide turnover, whichever is higher. Other obligations carry lower caps, and false or incomplete information to authorities has its own penalty. These are maximums: the actual fine is proportionate, but the order of magnitude says the CRA is not a formality.

A modification is substantial when it changes the product’s conformity with the essential requirements or alters its intended use in a way that introduces new risks: at that point the product must be reassessed as if new. Security updates that merely fix vulnerabilities, without changing functions, are not substantial modifications. It is a distinction that matters across the lifecycle: it avoids restarting the assessment at every patch, but forces it when you genuinely change the product.

No. A certified quality system is an advantage for the documentation and process backbone the CRA requires — versioning, supplier management, traceability — but ISO 9001 says nothing about product security: it does not cover vulnerability handling, the Annex I requirements, the support period. It is a base to build part of the work on, not a shortcut that closes compliance.

Yes, and they operate on different planes. NIS2 concerns the security of the organisation and services of an essential or important entity; the CRA concerns the security of the product you place on the market. An industrial manufacturer can be subject to both: NIS2 for how it runs its business, the CRA for how it designs and maintains what it sells. They neither replace nor cancel each other: map them together to avoid doing the same work twice or leaving gaps.

IEC 62443 is the technical standard much of the CRA work leans on for industrial products and systems: 62443-4-1 on the secure development process and 62443-4-2 on component technical requirements provide a ready-made language for meeting the Annex I requirements. The formal presumption of conformity will come from the European harmonised standards, but those already working with 62443 start from a coherent backbone, not from scratch.

Yes, for radio equipment. The cybersecurity requirements tied to the RED cease to apply on 11 December 2027 and the CRA becomes the single reference, so the same device no longer answers to two parallel sets of requirements. It is a simplification disguised as a deadline: whoever used the RED as their cyber anchor must move it onto the CRA, which is broader and ongoing.