What is the Cyber Resilience Act?

The Cyber Resilience Act (CRA) is the EU regulation that makes cybersecurity a legal condition for selling hardware and software in the European Union. If you manufacture, import or distribute a product with digital elements — an app, a connected device, firmware, a software library sold commercially — the CRA requires it to be secure by design, kept secure with updates through a defined support period, and backed by processes for handling and reporting vulnerabilities. It is Regulation (EU) 2024/2847, it entered into force on 10 December 2024, and its obligations arrive in stages: vulnerability and incident reporting from 11 September 2026, the full set of obligations from 11 December 2027.

That is the short version. The rest of this guide covers who is caught by it, what it actually demands, and what the timeline means in practice.

Why the EU introduced it

Two problems drove the CRA. First, a large share of hardware and software sold in the EU shipped with weak security and no obligation on anyone to fix it — the cost of insecure products landed on users, not makers. Second, even security-conscious buyers could not compare products, because there was no reliable information about how long a product would receive updates or how the vendor handled vulnerabilities.

The CRA answers both: it puts the responsibility for product security on the economic operator that profits from the product, for the whole lifecycle — not just at the moment of sale — and it makes security properties visible through CE marking, documentation and user information. It follows the same logic the EU has long applied to physical product safety: a product that has not been shown to meet the requirements does not get sold on the single market.

What counts as a product with digital elements

The regulation's scope term is deliberately broad. A product with digital elements is any software or hardware product — and its remote data processing solutions — whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. In practice that covers:

• Software products: operating systems, desktop and mobile applications, games, development tools, software libraries and components sold commercially
• Connected hardware: routers, smart-home devices, industrial sensors, wearables, connected toys
• Firmware and embedded software shipped inside devices
• Remote processing that the product cannot function without — the cloud half of a hardware product counts as part of the product

Some categories are excluded because sector rules already cover them: medical devices, in-vitro diagnostics, civil aviation, motor vehicles, and products developed exclusively for national security or defense. Pure services — SaaS as such — are outside the CRA and are addressed by NIS2 instead, unless the remote processing is integral to a product's function. Open-source software developed or supplied outside a commercial activity is out of scope, and non-profit open-source stewards get a deliberately light regime.

Who the CRA applies to: manufacturers, importers, distributors

The heaviest duties fall on manufacturers — anyone who develops or has developed a product with digital elements and markets it under their own name. Manufacturers must meet the essential requirements, run conformity assessment, affix CE marking, maintain technical documentation, operate vulnerability handling for the support period, and report actively exploited vulnerabilities and severe incidents.

Importers may only place compliant products on the EU market and must verify the manufacturer has done its part — conformity assessment performed, documentation drawn up, CE marking present. Distributors must act with due care and confirm the CE marking and required documents exist before selling. Both are obliged to act — up to withdrawal and informing authorities — when they learn a product they handle is non-conforming.

One consequence worth spelling out: if you import or white-label software or devices from outside the EU, you inherit real legal duties. And any importer or distributor that rebrands a product as its own becomes the manufacturer, with everything that entails.

The essential cybersecurity requirements

Annex I of the regulation sets the requirements in two parts. Part I covers the properties of the product itself. Reworded into plain language, a product must:

• Ship without known exploitable vulnerabilities, and with a secure-by-default configuration
• Control access — authentication and protection against unauthorized use
• Protect the confidentiality and integrity of the data it stores, transmits or processes
• Process only the data it needs (data minimization)
• Protect availability of essential functions and be resilient against denial-of-service
• Limit its own attack surface and contain the impact of an incident
• Record security-relevant activity where appropriate, and let users remove their data securely

Part II covers the manufacturer's vulnerability handling process: identify and document components in the product — including a software bill of materials — address vulnerabilities without undue delay via free security updates, test the product regularly, publicly disclose fixed vulnerabilities, operate a coordinated vulnerability disclosure policy, and distribute updates through secure channels.

The depth of conformity assessment depends on how risky the product class is. Most products can self-assess. Important products (Annex III — think password managers, VPNs, operating systems, smart-home hubs) face stricter procedures across two classes, and critical products (Annex IV — smart cards, smart meter gateways, secure elements) can be required to obtain European cybersecurity certification.

Vulnerability handling obligations

The CRA treats a product's launch as the start of the obligation, not the end. Through the support period — at least five years, unless the product's expected lifetime is genuinely shorter — the manufacturer must keep handling vulnerabilities: monitoring, remediating, updating, disclosing. Security updates must be provided free of charge, and where technically feasible, delivered separately from feature updates so users are not forced to accept new functionality to stay secure.

From 11 September 2026, handling becomes reporting. A manufacturer that becomes aware of an actively exploited vulnerability in its product, or of a severe incident having an impact on the product's security, must notify the authorities on a fixed clock: an early warning within 24 hours, a fuller notification within 72 hours, and a final report after remediation. Reports go to the CSIRT designated as coordinator and to ENISA through a single reporting platform. Our guide to what changes on 11 September 2026 walks through the reporting mechanics in detail.

When the CRA applies: the staged timeline

The order matters. Reporting arrives more than a year before the rest, which means a manufacturer can be legally required to report a vulnerability in a product that does not yet legally require CE marking. The reporting duty attaches to products already on the market, not just future ones.

What non-compliance costs

The CRA carries administrative fines in the style of the GDPR. Non-compliance with the essential requirements or with the core manufacturer obligations can draw fines up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. Other obligations top out at €10 million or 2%, and supplying misleading or incomplete information to authorities at €5 million or 1%.

The quieter penalty is market access. Market surveillance authorities can require corrective action, restrict or prohibit a product's availability, and order recalls or withdrawals. For a product company, being ordered off the EU market is usually a bigger number than the fine.

Where to start

Three questions tell you most of what you need to know:

1. Are you in scope? If you make, import or rebrand software or connected hardware sold in the EU, assume yes until you have confirmed an exclusion applies.
2. Can you report on the clock? The 24-hour early warning on 11 September 2026 assumes you can detect exploitation, decide severity and notify — with contacts, process and ownership already in place.
3. Can you evidence the requirements? Secure development, an SBOM, a disclosure policy, an update process — auditors and market surveillance authorities ask for records, not intentions.

If the honest answer to the last two is "not yet," that is a gap list — and closing it looks the same whether you run it in spreadsheets or on a platform. Our CRA compliance software page shows how ZeroRisk covers both sides of it: your own readiness, and proof that your suppliers meet the same bar.