Quick summary
What the CRA is
The CRA (Cyber Resilience Act) is the European regulation that sets mandatory cybersecurity requirements for products with digital elements: hardware and software that connect, directly or indirectly, to another device or to a network. It is a product safety law, in the same spirit as CE marking, and not a law on the security of an organization's networks and systems, which is the domain of NIS2.
Because it is a regulation, it applies directly, without transposition. What each Member State has to do is designate its market surveillance authorities and set up the enforcement regime. The rules cover the whole product lifecycle: design, development, placing on the market and the support period, including how vulnerabilities are handled after sale.
In practice, a product that does not comply with the CRA cannot be sold in the EU with a CE marking. For European customers, that marking will also be the proof that the product was developed and is maintained to minimum cybersecurity criteria.
Timeline and deadlines
- Nov. 20, 2024Publication of Regulation (EU) 2024/2847 in the Official Journal of the European Union.
- Dec. 10, 2024The CRA enters into force, 20 days after publication. The transition period begins.
- Dec. 2025Supporting acts from the Commission: technical descriptions of the categories of important and critical products (Implementing Regulation (EU) 2025/2392) and rules for delaying the dissemination of notifications among CSIRTs (Delegated Regulation (EU) 2026/881, adopted on December 11, 2025).
- June 11, 2026The provisions on notified bodies apply (Chapter IV). Conformity assessment bodies can now be notified and prepare to assess products.
- July 27, 2026The Commission publishes its first CRA application guidance, with practical examples on scope, remote data processing solutions, open-source software, substantial modification and the support period.
- Sept. 11, 2026Reporting obligations begin (Article 14) for actively exploited vulnerabilities and severe incidents. ENISA's Single Reporting Platform went live on this date.
- Through end of 2026 and 2027Harmonized standards in preparation by CEN, CENELEC and ETSI, under the Commission's standardization request. Delivery dates have been adjusted, so keep an eye on them.
- Dec. 11, 2027Full application of the CRA. New products placed on the market must meet the essential requirements, undergo conformity assessment and carry the CE marking.
The delivery dates for harmonized standards and the Commission's guidance are still evolving. Check the current status before fixing your compliance plan. Through October 2026 we found no change to the CRA's application dates: the simplification proposals in the so-called Digital Omnibus package (November 2025) mainly concern other legislation.
Who is covered
The CRA applies to operators that make products with digital elements available on the Union market, whether or not they are established in the EU. Each role has its own obligations.
Manufacturers
Anyone who designs, develops or manufactures a product, or has it designed and manufactured, and markets it under its own name or trademark. They carry the heaviest obligations: security by design, technical documentation, conformity assessment, CE marking, vulnerability handling and reporting.
Importers
Anyone who places on the EU market a product from a manufacturer established outside the Union. They must check that the manufacturer has complied with the CRA (assessment, documentation, CE marking, instructions) before placing it on the market, and identify themselves on the product.
Distributors
Anyone who makes the product available on the market without being the manufacturer or the importer. They must check the CE marking, the documentation and the instructions, and act with due care. They must not make available products they know to be non-compliant.
Open-source software stewards
Legal persons that systematically support the development of free software intended for commercial use. They have a lighter regime: a cybersecurity policy, cooperation with authorities and reporting, and they are exempt from fines.
An importer or distributor is treated as a manufacturer if it places the product on the market under its own name or trademark, or if it modifies the product substantially. The manufacturer may also appoint an authorized representative, by written mandate, for certain tasks such as cooperating with authorities.
Products: scope, exclusions and classes
What is in scope
Any product with digital elements whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network: connected devices (IoT), computer equipment, operating systems, applications, libraries and components placed on the market separately. It also includes remote data processing solutions that the manufacturer develops (or has developed) and without which the product cannot perform one of its functions, for example the cloud application that is part of how a device works.
A standalone software as a service (SaaS) offering, which is not needed for a product to function, is generally not a product with digital elements under the CRA. Such services may, on the other hand, be subject to NIS2. Open-source software developed or supplied outside a commercial activity is out of scope.
Main exclusions
- Medical devices and in vitro diagnostic medical devices (Regulations (EU) 2017/745 and 2017/746)
- Motor vehicles covered by Regulation (EU) 2019/2144
- Civil aviation products covered by Regulation (EU) 2018/1139
- Marine equipment covered by Directive 2014/90/EU
- Products developed exclusively for national security or defense purposes
- Spare parts intended to replace identical components in existing products
The list of exclusions has conditions and cross-references to other sectoral legislation. Confirm how your product is classified under Article 2 of the regulation and in the Commission's July 2026 guidance.
Product classes
The CRA distinguishes three risk levels, which determine the conformity assessment route. Most products fall into the default class.
| Class | Examples (Annexes III and IV) | Conformity route |
|---|---|---|
| Default | Most products: ordinary applications, games, most connected consumer and industrial devices | Self-assessment (internal control, module A) |
| Important, class I | Identity and password managers, browsers, VPNs, malware detection software, operating systems, routers and modems, SIEM systems, smart home virtual assistants and security products, connected toys, health wearables | Self-assessment only if harmonized standards, common specifications or European certification are fully applied; otherwise third-party assessment |
| Important, class II | Hypervisors and container runtimes, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors and microcontrollers | Assessment by a notified body (or European certification); self-assessment is not allowed |
| Critical | Devices with security boxes, smart meter gateways and advanced security devices, smart cards and secure elements | European cybersecurity certification, where required by a Commission delegated act; otherwise third-party assessment |
Classification depends on the product's core functionality, as defined in the technical descriptions in Implementing Regulation (EU) 2025/2392. A product that merely integrates a listed component does not become important for that reason.
Requirements for manufacturers
The essential cybersecurity requirements are set out in Annex I of the regulation and fall into two parts: security properties of the product and vulnerability handling.
- Security by design and by default. A cybersecurity risk assessment at the start of and throughout development, secure configuration out of the box, protection against unauthorized access, confidentiality and integrity of data, a reduced attack surface and resilience against denial-of-service attacks.
- Vulnerability handling. Identify and document the product's vulnerabilities and components, fix vulnerabilities without delay, test security regularly, publicly disclose vulnerabilities once fixed, and have a coordinated vulnerability disclosure policy and a contact point for receiving reports.
- Security updates. Make security updates available free of charge and in a timely manner during the support period, preferably separate from functional updates, and inform users.
- Software bill of materials (SBOM). The manufacturer must document the product's components and dependencies in a commonly used, machine-readable format, as part of the technical documentation. It does not have to be published, but it must be available to authorities.
- Support period. Set by the manufacturer and clearly stated to the user, with an end date. The minimum is 5 years, unless the product is expected to be used for a shorter time, in which case the period may be shorter, with justification.
- Technical documentation and user information. Documentation with the product description, the risk assessment, the standards applied and the test results (Annex VII), plus instructions and information for the user (Annex II), including the manufacturer's contact details and the end of the support period. The documentation is kept for 10 years after the product is placed on the market or for the duration of the support period, whichever is longer.
- Due diligence on third-party components. The manufacturer remains responsible for the components it integrates, including open-source ones, and must assess and maintain them.
This section summarizes the obligations in Article 13 and following and in Annexes I, II and VII. Confirm the details in the regulation.
Conformity assessment and CE marking
Before placing the product on the market, the manufacturer demonstrates conformity and draws up the corresponding documentation.
- Choosing the route. Internal control (self-assessment, module A) for the default class and, under the conditions above, for class I; third-party assessment (notified body, for example type examination plus conformity to type, or full quality assurance) for class II; European cybersecurity certification for critical products where required.
- EU declaration of conformity. A document in the Annex V format, signed by the manufacturer, who takes responsibility for conformity.
- CE marking. Affixed visibly, legibly and indelibly on the product (or on the packaging or accompanying documents, where that is not possible) before it is placed on the market.
- Notified bodies. The rules on their designation have applied since June 11, 2026. Manufacturers of class II products should check the capacity and lead times of these bodies early, because demand will concentrate close to December 2027.
- Harmonized standards. Conformity with harmonized standards cited in the Official Journal gives a presumption of conformity. As of the date of this information, the standards were still in preparation.
- Retention and cooperation. The declaration and the documentation are kept available to the market surveillance authorities, which may request them.
Reporting vulnerabilities and incidents
Article 14 requires manufacturers to report two situations: actively exploited vulnerabilities in the product and severe incidents affecting the security of the product. The report is submitted simultaneously to the CSIRT designated as coordinator in the Member State of the main establishment and to ENISA, through a Single Reporting Platform run by ENISA. ENISA then distributes the information to the relevant CSIRTs. The platform has been live since September 11, 2026.
Besides reporting to the authorities, the manufacturer must inform the affected users and, where relevant, tell them which measures they can take to protect themselves.
For a manufacturer with no establishment in the EU, the CSIRT it must report to is determined by a cascade (Article 14(7)): the Member State of the authorized representative, if there is one; failing that, that of the importer; then that of the distributor; finally, the Member State where the largest number of users is located. Microenterprises and small enterprises are not fined for missing the 24-hour early warning deadline, but the duty to report remains. Open-source software stewards have their own regime. Confirm the date and scope in the regulation. Voluntary reporting of vulnerabilities and of incidents that are not severe is also possible.
Enforcement and fines
Enforcement is carried out by the market surveillance authorities designated by each Member State, not by the European Commission. Products can be inspected in any Member State where they are on sale, and the authorities cooperate through an administrative cooperation group. In Portugal, check with the competent authorities which body has been designated, because as of the date of this information we found no official confirmation.
| Infringement | Fine ceiling (whichever is higher) |
|---|---|
| Non-compliance with the essential cybersecurity requirements (Annex I) and the manufacturer obligations in Articles 13 and 14, including reporting | Up to €15 million or 2.5% of worldwide annual turnover in the preceding financial year |
| Non-compliance with other obligations in the regulation (for example those of importers and distributors, the EU declaration of conformity, CE marking and the rules for notified bodies) | Up to €10 million or 2% of worldwide annual turnover |
| Supplying incorrect, incomplete or misleading information to notified bodies or authorities | Up to €5 million or 1% of worldwide annual turnover |
Before a fine, the authorities have measures that in practice hurt the business more: requiring the product to be fixed within a set period, restricting its availability, withdrawing it from the market or recalling it. The actual fine takes into account severity, the size of the company and the cooperation shown. Open-source software stewards are exempt from fines.
The ceilings above are set in Article 64 of the regulation. The fines actually imposed depend on each authority and on the specific case. Confirm the amounts in the regulation.
NIS2, DORA and non-EU suppliers
Relationship with NIS2 and DORA
The CRA, NIS2 and DORA complement each other: the CRA regulates the product and its manufacturer, while NIS2 and DORA regulate the organization that uses it. In practice:
- An essential or important entity under NIS2 has to manage the risk in its supply chain. Products with a CE marking and a known support period make that assessment easier, and customers can be expected to start asking for them.
- A financial entity under DORA has to manage the risk of its ICT providers. A supplier that sells software or digital devices may be subject to both: the CRA for the product, and DORA through the contract.
- A manufacturer that also operates services may have obligations under both regimes, with different reporting deadlines and different recipients. A single triage process is advisable.
- The Digital Omnibus package under discussion includes a single entry point for incident reports. We found no indication that it changes the CRA's timeline or reporting platform. Follow developments.
Suppliers outside the EU
The CRA applies to anyone who makes products available on the Union market, including direct online sales to European customers. A manufacturer in Cabo Verde, or in any other third country, is treated as a manufacturer for all purposes, even with no presence in the EU.
- Importer. If you sell through an importer in the EU, the importer has to verify your compliance before placing the product on the market. In practice, it will ask you for the documentation and the declaration of conformity.
- Authorized representative. Appointment is optional, by written mandate, but useful: it gives you a stable contact with the authorities and fixes the Member State for reporting purposes. Make sure the mandate covers what you want to delegate. The representative cannot take over the secure design of the product or the risk assessment, which remain with the manufacturer.
- Customer contracts. European buyers can be expected to start including clauses in contracts on CRA compliance, vulnerability reporting, SBOM and end of support. Compliance tends to become a commercial requirement, not only a legal one.
How we do it
We help manufacturers, importers and software suppliers turn the CRA into a work plan with owners and deadlines, in six steps.
- Scoping. We confirm which products are in scope, your role (manufacturer, importer, distributor), the applicable exclusions and the class of each product.
- Gap analysis. We compare your current development and maintenance lifecycle with Annex I, the support period, the documentation and the standards in preparation.
- Security by design. Product risk assessment, security requirements, secure development lifecycle, testing, and management of third-party and open-source components.
- Vulnerabilities and SBOM. Intake and handling process, coordinated disclosure policy, SBOM generation and maintenance, and the update channel.
- Reporting and conformity. A 24 h, 72 h and final report process, connected to ENISA's platform; choice of assessment route, EU declaration of conformity and preparation for the notified body, if applicable.
- Evidence and continuous improvement. Technical documentation ready for the authorities, clauses for importers and customers, and periodic reviews.
If you sell into the EU from outside, we also prepare the coordination with importers, the decision on whether to appoint an authorized representative, and the answers to the security questionnaires from European customers.
Frequently asked questions
Does the CRA apply to my product if my company is outside the EU?
Yes, if the product is made available on the EU market, including through direct online sales. The CRA applies to the product and to the operator that places it on the market, wherever it is. The company's location is not a criterion.
What reporting deadlines do we have to meet, and since when?
Since September 11, 2026: early warning within 24 hours, notification within 72 hours, and a final report within 14 days after the fix (vulnerabilities) or within 1 month after the notification (severe incidents). The obligation also covers products placed on the market before December 2027.
For how long do we have to provide support and security updates?
The manufacturer sets the support period, with a minimum of 5 years, unless the product is expected to be used for a shorter time. The period must be clearly stated to the user, and security updates are free of charge during that period.
Is our SaaS software covered?
A standalone SaaS service, which is not needed for a product to function, is generally not covered by the CRA, but may be subject to NIS2. A remote data processing solution without which the product does not work, however, is part of the product and is covered. The Commission published guidance on this boundary in July 2026.
It is already October 2026. Are we late?
On reporting, the deadline has already started, so the first step is to have a process and an owner. On design requirements and CE marking, the deadline is December 11, 2027, which gives about fourteen months, not much for class II products that need a notified body. A quick assessment lets you prioritize.
Sources and legal notice
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
- European Commission, Cyber Resilience Act summary
- European Commission, CRA reporting obligations
- European Commission, CRA application guidance (July 27, 2026)
- ENISA, CRA Single Reporting Platform factsheet
- Delegated Regulation (EU) 2026/881 (delaying the dissemination of notifications), EUR-Lex
- Implementing Regulation (EU) 2025/2392 (technical descriptions of product categories), Snellman note
- cyberresilienceact.eu, state of play and timeline