CRA Regulation Explained: What the EU Cyber Resilience Act Requires, When, and From Whom

Search for "CRA regulation" and you get three different laws. In the United States it is the Community Reinvestment Act, a banking statute from 1977. In Canada it is the Canada Revenue Agency and its tax rules. In the European Union, and increasingly everywhere software is sold, it is the Cyber Resilience Act, Regulation (EU) 2024/2847, the first law anywhere to make cybersecurity a condition of placing a product with digital elements on a market. This guide is about the third one. It covers what the CRA regulation is, who it binds, the dates that matter, what manufacturers must actually do, how much non-compliance costs, and what to do this quarter.

What the CRA Regulation Is

The Cyber Resilience Act was proposed by the European Commission in September 2022, adopted by the Parliament and Council in October 2024, published in the Official Journal on 20 November 2024 and entered into force on 10 December 2024. It is a regulation, not a directive, which means it applies directly in every member state without national transposition. There is no Bulgarian, German or French version to wait for.

Its purpose is stated plainly in Article 1: to set cybersecurity requirements for the design, development, production and making available of products with digital elements, so that products reach the market with fewer vulnerabilities and manufacturers take security seriously throughout the product's life. Before the CRA, EU product law covered safety, electromagnetic compatibility and radio spectrum. It did not cover whether the firmware could be taken over by a script from the internet. The CRA closes that gap and attaches the CE mark to it.

The regulation sits alongside three other EU laws that a security team will meet at the same time. NIS 2 regulates organisations in essential and important sectors. The revised Product Liability Directive makes software a product for liability purposes from 9 December 2026. The AI Act regulates AI systems, and a high-risk AI system that meets the CRA's essential requirements is presumed to meet the AI Act's cybersecurity requirement. We come back to those overlaps below.

Who the CRA Regulation Applies To

The CRA uses the language of EU product law. The obligations fall on economic operators according to their role in the supply chain.

• Manufacturers carry nearly all of the obligations: design, vulnerability handling, documentation, conformity assessment, reporting. A manufacturer is anyone who develops or has developed a product with digital elements and markets it under their name or trademark, whether for payment or free of charge in the course of a commercial activity. A company in Sofia, Austin or Bangalore that sells into the EU is a manufacturer under the CRA.
• Importers must verify that the manufacturer has done the conformity assessment and drawn up the technical documentation before placing the product on the EU market, and must put their own name and contact details on it.
• Distributors must check that the CE marking and the required information are present and must not supply a product they know or should know is non-compliant.
• Open-source software stewards, meaning legal persons that provide sustained support for open-source products intended for commercial activities, have a lighter regime: a cybersecurity policy, cooperation with authorities and reporting duties, but no conformity assessment.

What counts as a product with digital elements

Article 3 defines it as a software or hardware product and its remote data processing solutions, including components placed on the market separately. In practice that means firmware, operating systems, desktop and mobile applications, libraries sold commercially, routers, cameras, industrial controllers, smart meters, wearables and the cloud backend a device cannot function without. The test is whether the product involves a direct or indirect logical or physical data connection to a device or network.

What is excluded

Five categories fall outside the CRA because other EU laws already cover them: medical devices under the MDR and IVDR, motor vehicles under the type approval regulation, civil aviation products under the EASA Basic Regulation, marine equipment, and products developed exclusively for national security or defence. Non-commercial open-source software is also outside scope, and so is software as a service in its pure form.

CRA Regulation Timeline: The Four Dates That Matter

One transitional rule is worth knowing. Products placed on the market before 11 December 2027 are only subject to the reporting obligations, unless they are substantially modified after that date. A substantial modification is one that affects compliance with the essential requirements or changes the intended purpose, which a major firmware release can easily do. Treating an existing product line as grandfathered is a decision that needs a written risk assessment, not an assumption.

What Manufacturers Must Do

The obligations are spread across Article 13 and Annexes I, II and VII. Read together, they describe a security programme for the product, run for as long as the product is supported.

Annex I Part I: security properties of the product

• Designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks.
• Placed on the market without known exploitable vulnerabilities.
• Secure by default configuration, with the ability to reset to that state.
• Security updates available, installed automatically by default where appropriate, and separated from functionality updates.
• Protection against unauthorised access through authentication, identity and access management, and reporting of unauthorised access.
• Confidentiality and integrity of stored, transmitted and processed data, using encryption at rest and in transit where relevant.
• Data minimisation, availability of essential functions after an incident, limited impact on other devices, minimised attack surface, mitigation of exploitation techniques, security logging, and the ability to securely remove all data.

Annex I Part II: the vulnerability handling process

• Identify and document vulnerabilities and components, including a software bill of materials in a machine-readable format covering at least the top-level dependencies.
• Address and remediate vulnerabilities without delay, including through security updates provided free of charge.
• Apply effective and regular tests and reviews of the product's security.
• Publicly disclose information about fixed vulnerabilities once a security update is available.
• Put in place and enforce a coordinated vulnerability disclosure policy, and provide a contact address for reporting vulnerabilities.
• Share information with the responsible parties and distribute updates securely.

The support period

The manufacturer must determine a support period that reflects how long the product is expected to be in use, and it may not be shorter than five years unless the product is expected to be used for less. During that period security updates must remain available for at least ten years after issue or for the rest of the support period, whichever is longer. The support period must be stated at the time of purchase. For a company used to ending support when the next version ships, this is the obligation with the largest engineering cost.

Documentation, conformity and the CE mark

Before placing a product on the market the manufacturer draws up technical documentation in the Annex VII structure, carries out or commissions a conformity assessment, draws up an EU declaration of conformity and affixes the CE marking. The documentation must be kept for ten years or the support period, whichever is longer, and produced to a market surveillance authority on request.

The 24-Hour Reporting Duty

Article 14 is the part of the CRA regulation that arrives first, on 11 September 2026, and the part most likely to be breached by accident. Manufacturers must report two things: any actively exploited vulnerability in their product, and any severe incident having an impact on the product's security. Both go to a single reporting platform operated by ENISA, which forwards them to the CSIRT of the member state where the manufacturer has its main establishment.

Twenty-four hours is not enough time to decide who decides. The companies that will meet this deadline are the ones that already have a security incident response process with a named person who can classify a vulnerability as actively exploited, a pre-agreed template, an account on the ENISA platform and a rehearsed path from the engineer who spots the exploit to the person who files. Companies without those four things will discover the gap on the day it matters.

Product Classes and Conformity Assessment

Not every product is assessed the same way. The CRA sorts products into four groups, and the group determines whether the manufacturer can assess conformity itself or must involve a notified body.

Here is the practical problem in 2026. No harmonised standards for the CRA have been cited in the Official Journal yet; the core deliverables from CEN and CENELEC are expected between August and October 2026, with the rest in 2027. And as of June 2026 no notified bodies had been designated, with the Commission targeting enough of them by 11 December 2026. A class I manufacturer therefore cannot yet complete a self-assessment on the strength of a harmonised standard, and cannot yet book a notified body either. The correct response is to build the technical file now against the Annex I text and the draft standards, so that either route can be completed quickly when it opens.

The Software Bill of Materials

The SBOM is the CRA obligation engineering teams ask about most, and the one that is easiest to get wrong by treating it as a document. The regulation requires it to be machine-readable and to cover at least the top-level dependencies of the product. It goes into the technical documentation and must be produced to a market surveillance authority on request; it does not have to be published to customers, although many enterprise buyers now ask for it anyway.

The workable approach is to generate it in the build pipeline, in CycloneDX or SPDX format, for every release, and to store it with the release artefacts. A one-off SBOM produced by a consultant is out of date the day after the next dependency bump. The same pipeline can then feed vulnerability monitoring, which is how the "no known exploitable vulnerabilities at release" requirement in Annex I is actually met.

Penalties Under the CRA Regulation

Article 64 sets three tiers of administrative fines, applied by the national market surveillance authorities.

• Up to EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher, for non-compliance with the essential requirements in Annex I or the manufacturer obligations in Articles 13 and 14.
• Up to EUR 10 million or 2 percent for non-compliance with any other obligation in the regulation.
• Up to EUR 5 million or 1 percent for supplying incorrect, incomplete or misleading information to notified bodies or authorities.

Fines are not the only sanction. Authorities can require corrective action, restrict or prohibit the product on the market, or order its withdrawal or recall. And from 9 December 2026 the revised Product Liability Directive treats software as a product, treats a cybersecurity defect as a defect, and treats non-compliance with the CRA as evidence of one. The commercial exposure from a recall or a liability claim will in most cases exceed the fine.

How the CRA Fits With NIS 2, the RED, the PLD and the AI Act

What to Do Now: A Seven-Step Plan

1. Inventory every product with digital elements, including agents, apps, firmware and the remote processing they depend on. Most companies find more than they expected.
2. Classify each product as default, important class I, important class II or critical, and record the reasoning. The class decides the budget and the timeline.
3. Set up the reporting path before 11 September 2026: a named decision-maker, an ENISA platform account, templates and one drill against a real vulnerability from your backlog.
4. Generate an SBOM in the build pipeline for every release, and connect it to vulnerability monitoring.
5. Publish a coordinated vulnerability disclosure policy and a contact address, and decide how you will handle researcher reports.
6. Run a security assessment of the product against Annex I, including a penetration test of the product and its update mechanism, and fix what it finds.
7. Assemble the technical file in the Annex VII structure and decide the support period, so the declaration of conformity can be signed the day the conformity route opens.

Five Misconceptions About the CRA Regulation

• "We are not in the EU, so it does not apply." It applies to any product placed on the EU market, wherever the manufacturer is based. The importer or distributor is liable if you are not.
• "We are SaaS, so we are exempt." Pure SaaS is under NIS 2, but agents, apps, connectors and the remote processing a product depends on are under the CRA.
• "Nothing applies until December 2027." Reporting applies from 11 September 2026, including for products already on the market.
• "ISO 27001 covers it." ISO 27001 certifies the organisation's management system. The CRA assesses the product. The overlap is real but partial, and there is no presumption of conformity.
• "We will wait for the standards." The standards and the notified bodies are late, but the deadlines are not moving. The technical file built against the Annex I text now is what gets assessed quickly later.

Frequently Asked Questions

Sources

• Regulation (EU) 2024/2847, the Cyber Resilience Act, on EUR-Lex
• European Commission: Cyber Resilience Act policy page
• European Commission: reporting obligations under the CRA
• ENISA: Single Reporting Platform
• Directive (EU) 2024/2853, the revised Product Liability Directive