Docs

Regulations

Cyber Resilience Act

Cyber Resilience Act — A practical guide for developers and companies 🛡️

The CRA does not ask you to make your software “perfect”. It requires every product with digital elements to be secure by design and any vulnerability to be handled and reported for the whole product lifetime. The days when “I have a support channel” was enough are over.

What it is and why it matters 🔍

Regulation (EU) 2024/2847 — the Cyber Resilience Act (CRA) — is the first horizontal European law imposing essential cybersecurity requirements on all products with digital elements. It was adopted on 23 October 2024 and published in the Official Journal of the EU on 20 November 2024 (OJ L 2024/2847).

It is a regulation: directly applicable in all member states with no transposition needed. It entered into force on 11 December 2024 (20 days after publication) and applies from 11 December 2027, with some operational provisions effective earlier (see Timeline and deadlines).

The stated goal leaves no room for ambiguity: cybersecurity no longer ends where one company’s software ends. Every connected product — from a router to a smart fridge, from a firewall to an ERP — must be secure by design, stay patched throughout its lifecycle, and report vulnerabilities and incidents to authorities.

The CRA fills the “gap” between other regulations: NIS 2 covers the organisations running critical infrastructure, the GDPR covers personal data, but no one regulated the digital products themselves. Now someone does.

Who it applies to 🎯

What is a “product with digital elements” 📦

A broad definition (Art. 3): any software or hardware product — and its related remote data processing solutions — including software or hardware components marketed separately, whose intended or reasonably foreseeable use includes a direct or indirect data connection (logical or physical) to a device or a network.

In practice: almost anything with a firmware, an app or an API exposed to the outside. A mobile app, an IoT device, a router, a connected ERP, an SDK. If it “talks” to something, the CRA is relevant.

Who is bound 👤

Manufacturer (Art. 3.13): any entity that develops or has developed a product with digital elements and markets it under its own name or trademark, whether for payment, monetisation or free of charge;
Authorised representative, importer, distributor (for products from third-country manufacturers);
Open-source software steward (Art. 3.14): an entity providing systematic and ongoing support for the development of open-source products intended for commercial activities, ensuring their economic sustainability.

The commercial hook in the manufacturer definition is deliberate: “it’s free” will not save you. Even a free app with ads or telemetry counts as commercial activity.

Main exclusions (Art. 2) ⛔

Medical devices (Regulation 2017/745) and in-vitro diagnostic medical devices (2017/746);
Motor vehicles (2019/2144) and certified aircraft (2018/1139);
Marine equipment (2014/90);
Spare parts replacing identical components;
Products developed or modified exclusively for national security, defence or handling classified information.

Sectors covered by other EU law (e.g. medical devices) stay under their own frameworks, but the CRA applies horizontally to everything else. The software and hardware supply chains it does not touch are very few indeed.

Essential cybersecurity requirements 📋

The CRA’s core is Annex I, split into two parts.

Part I — Product properties 🧱

Products must be designed, developed and produced to ensure an adequate level of cybersecurity given the risk. Key requirements:

sold without known exploitable vulnerabilities;
secure-by-default configuration, no default passwords;
security updates manageable, ideally automatic with deferral options;
protection against unauthorised access (authentication, identity management);
encryption of data at rest and in transit, protection of confidentiality and integrity;
data minimisation: process only the data needed for the purpose;
availability of essential functions even after an incident, anti-DoS resilience;
limited attack surface (external interfaces), mitigation of exploitation;
logging and monitoring of internal activity accessible to the user;
ability to remove data securely and permanently.

Part II — Vulnerability handling 🐛

The manufacturer must:

identify and document vulnerabilities and components, producing a software bill of materials (SBOM) in a machine-readable format, including top-level dependencies;
address and fix vulnerabilities with security updates, separate from functional updates where technically feasible;
carry out periodic security testing and reviews;
publicly disclose fixed vulnerabilities with description, impact, severity and remediation instructions;
adopt a coordinated vulnerability disclosure policy;
provide a single point of contact for vulnerability reporting;
distribute updates securely;
provide updates promptly and free of charge (with exceptions for bespoke products).

The SBOM is not optional: it is how you concretely “know what is inside”. If you have no machine-readable dependency list, the CRA forces you to build one.

Manufacturer obligations (Art. 13) 🏭

Beyond the essential requirements, the manufacturer must:

A documented cybersecurity risk assessment, kept current for the support period;
Due diligence over third-party components, including integrated open source: report component vulnerabilities and share code/fixes with maintainers;
Support period: at least 5 years from when the product is placed on the market, or matching the expected useful life if shorter. For products meant for long use (routers, operating systems, motherboards) the period must exceed 5 years;
Keep security updates available for at least 10 years after release (or the remaining support period, whichever is longer);
Technical documentation (Art. 31, Annex VII) plus EU declaration of conformity (Art. 28) and CE marking (Art. 30);
Keep documentation and declaration for 10 years;
Single point of contact for user reports; product identification (type/lot/serial number); clear user information and instructions kept for 10 years;
Notification of the end of support period and, on cessation of business, notice to authorities and users;
Corrective measures in case of non-compliance (withdrawal or recall).

Reporting vulnerabilities and incidents (Art. 14) 🚨

The most operational part for software people is the duty to simultaneously notify the coordinator CSIRT and ENISA, through the single reporting platform (Art. 16).

Actively exploited vulnerability 📢

Early warning within 24 hours of becoming aware;
Notification within 72 hours with general information on the product, the nature of the exploitation, corrective measures and the sensitivity level;
Final report within 14 days of a corrective measure being made available: description, severity, impact, the threat actor (if known), security update.

Serious incident affecting product security 🧯

Considered serious if it has (or may have) an impact on the product’s ability to protect availability, authenticity, integrity or confidentiality of sensitive data or functions, or has led (or may lead) to malicious code being introduced into the product or the user’s systems (Art. 14.5).

Early warning within 24 hours;
Notification within 72 hours with the nature of the incident and initial assessment;
Final report within 1 month of filing the notification.

In both cases the manufacturer must inform the users of the affected product (Art. 14.8).

Operational note: the report goes to the CSIRT terminal of the member state of the manufacturer’s principal establishment; for third-country manufacturers, by priority criteria (authorised representative, importer, distributor, largest number of users). If you have not decided “who notifies where”, now is the time.

There are also voluntary reporting duties (Art. 15) for vulnerabilities and threats outside the mandatory scope.

Conformity assessment and classification ✅

The CRA introduces a graduated rigour based on the product:

Category	Examples	Conformity procedure
General products	apps, business software, common IoT devices	Self-assessment (internal control, Annex VIII)
Important products — Class I (Annex III)	password managers, browsers, VPNs, antivirus, SIEM, operating systems, routers/modem	Self-assessment (internal control)
Important products — Class II (Annex III)	firewalls, intrusion detection/prevention systems, hypervisors, container runtimes	Third-party assessment (notified body)
Critical products (Annex IV)	hardware security modules, smart meter gateways, smart cards	Mandatory EUCC cybersecurity certification

Even though “general” and Class I products can self-assess, the documentation (Art. 31, Annex VII) must still prove conformity: the requirements are the same, only the verifier changes.

Golden rule: if your product is a firewall or a hypervisor, you are in Class II and you need a notified body. This is not a rubber stamp: it is CE marking with a third party, like medical devices.

Impact for companies 🏢

If you make or distribute software/hardware in the EU market, the compliance path is:

Product inventory: identify all products with digital elements (including components and SDKs);
Classification: determine whether the product is general, important (Class I/II) or critical;
Gap analysis vs Annex I: product properties + vulnerability handling;
Documented cybersecurity risk assessment;
SBOM + coordinated disclosure policy + single point of contact;
Conformity assessment procedure (self-assessment or notified body);
Technical documentation + EU declaration of conformity + CE marking;
Support period defined and announced; updates available.

Penalties (Art. 64 — EU-wide maxima, enforced by member states):

Breach	Maximum penalty
Non-compliance with essential requirements (Annex I) and Art. 13/14 obligations	€15,000,000 or 2.5% of worldwide turnover
Non-compliance with other obligations (documentation, declaration, marking, operator duties)	€10,000,000 or 2% of worldwide turnover
Inaccurate, incomplete or misleading information to bodies/authorities	€5,000,000 or 1% of worldwide turnover

Targeted exemptions (Art. 64.10): penalties do not apply to open-source software stewards (for regulation breaches) nor to micro/small manufacturers for the missed early-warning deadlines (24h). Not a get-out-of-jail card: all other breaches remain sanctionable.

The 5-year support period and 10-year update availability change business models: you can no longer ship “abandoned software” after the sale and walk away.

Impact for developers 💻

The CRA changes daily work far more than NIS 2 or the GDPR:

Secure by default: no default passwords, hardened default configuration, automatic updates with opt-out;
SBOM: a machine-readable dependency list (e.g. CycloneDX, SPDX) is no longer a luxury, it is a requirement;
Vulnerability management: a structured process to receive, assess, fix and disclose vulnerabilities; a coordinated disclosure policy;
Periodic security testing and reviews: functional tests are not enough, security tests must be repeated;
Incident/vulnerability notification in time: 24h/72h plus final report (14 days / 1 month) to CSIRT and ENISA;
Conformity documentation: technical documentation, EU declaration of conformity, 10-year retention;
Open-source components: due diligence when integrating them, reporting vulnerabilities to maintainers, sharing fixes.

The example that shows everything: a mobile app that updates itself, runs on HTTPS, keeps no plaintext passwords and logs logins probably already satisfies Part I. In Part II, the newest piece is: “do you know exactly which libraries are inside, and what do you do when one has a flaw?”

Timeline and deadlines 📆

Date	What applies
11 December 2024	Entry into force (20 days after publication on 20.11.2024)
11 June 2026	Chapter IV (Art. 35-51: market surveillance, ENISA, notifications)
11 September 2026	Art. 14 — vulnerability and incident reporting obligations
11 December 2027	Full application of the regulation
From 11 December 2027	Products placed on the market before 11/12/2027 are covered only if substantially modified — but the Art. 14 reporting obligations still apply to all existing products
Existing EU certificates	Valid until 11 June 2028

In practice: from September 2026 you already have to report vulnerabilities and incidents, including for products already on the market. The rest (design, documentation, marking) kicks in with 2027.

Compliance checklist ✅

A pragmatic checklist for developers and companies.

Product and design

Product identified (type/lot/serial number)
No known exploitable vulnerabilities at release
Secure-by-default configuration, no default passwords
Manageable security updates (better automatic with opt-out)
Authentication and access control; access logs
Data encrypted at rest and in transit
Data minimisation; secure data removal
DoS resilience and limited attack surface

Vulnerabilities and lifecycle

Documented cybersecurity risk assessment
SBOM in machine-readable format
Coordinated vulnerability disclosure policy
Single point of contact for reports
Patch process + free updates during the support period
Periodic security testing and reviews
Support period governed (≥5 years) and its end communicated

Notification and conformity

Explicit decision: who notifies, where (CSIRT + ENISA), by when
24h/72h runbook + final report (14 days / 1 month)
Users informed of incidents/vulnerabilities
Technical documentation (Annex VII) kept current
EU declaration of conformity + CE marking
Documentation retained for 10 years
Product classified (general / important I-II / critical)

Useful links 🔗

Cyber Resilience Act text (EUR-Lex) — Regulation (EU) 2024/2847
European Commission CRA page — Key facts and guidance
ENISA — Single reporting platform and technical reports
CSIRT network / CSIRT Italia — Reporting contacts in Italy
EUCC — European cybersecurity certification — For critical products
CycloneDX / SPDX — Interoperable SBOM formats