Cyber Resilience Act: reporting duties and the 2027 deadline

What the Cyber Resilience Act covers

The Cyber Resilience Act (opens in a new tab) (CRA), Regulation (EU) 2024/2847, sets cybersecurity rules for products with digital elements made available on the EU market. Article 3 defines them as software or hardware products and their remote data processing solutions, including components placed on the market separately. Under Article 2, the CRA applies when the product's intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network.

That covers connected devices, desktop and mobile apps, firmware, operating systems and software components, whether they are sold or supplied free of charge in the course of a commercial activity.

Remote data processing and cloud services

A cloud back end is in scope when the manufacturer designed it, or had it designed, and the product cannot perform one of its functions without it, such as the manufacturer's own API behind a mobile app (recital 11). Websites that do not support a product's function, and cloud services built outside a manufacturer's responsibility, are outside the CRA. Recital 12 points to the NIS2 Directive for cloud services such as software as a service (SaaS), which our NIS2 guide for suppliers covers.

Products excluded by other EU rules

Article 2 excludes:

• Medical devices and in vitro diagnostic medical devices (Regulations (EU) 2017/745 and 2017/746)
• Vehicles and their systems under Regulation (EU) 2019/2144
• Aviation products certified under Regulation (EU) 2018/1139
• Marine equipment under Directive 2014/90/EU
• Spare parts made to the same specifications as the components they replace
• Products made only for national security or defense, or to process classified information

Open-source software

Free and open-source software is in scope only when it is made available in the course of a commercial activity. Recital 18 explains that open-source software its developers do not monetize is not a commercial activity, and that people who only contribute code to projects outside their responsibility are not covered. A company that sells a product built on open-source components is the manufacturer of the whole product. It must exercise due diligence on those components (Article 13(5)) and report vulnerabilities it finds in them to their maintainers (Article 13(6)).

Manufacturer, importer, distributor or steward

Most duties fall on the manufacturer. Article 3 defines each role, and Articles 13 to 24 set the duties.

Roles can change. An importer or distributor that sells a product under its own name, or substantially modifies it, becomes its manufacturer (Article 21), and so does anyone else who substantially modifies a product and makes it available (Article 22). Open-source software stewards face a light regime, and Article 64(10) exempts them from fines.

Product categories and conformity assessment

The category decides who checks your product before it can carry CE marking. Most products fall into the default category. Annex III lists important products in two classes, and Annex IV lists critical products. Commission Implementing Regulation (EU) 2025/2392 (opens in a new tab) of November 28, 2025 gives the technical description of each category.

What counts is the core function of the product you sell. Integrating a component from Annex III does not by itself make your product an important one (Article 7(1)). Open-source products in Annex III categories can use self-assessment if their technical documentation is public (Article 32(5)).

For Class I, harmonized standards decide the route. The Commission's implementation plan (opens in a new tab) scheduled the first standards deliverables for the third quarter of 2026 and more by October 30, 2027. Until a standard for your product type is cited in the Official Journal, plan for a notified body. The rules on notified bodies have applied since June 11, 2026.

Cyber Resilience Act requirements for product design

Annex I, Part I, lists the security properties a product must have. Article 13 requires a documented cybersecurity risk assessment first, and that assessment decides how each requirement applies. Where a requirement does not apply, the technical documentation must say why. In plain words, a product must:

• Offer a level of security that fits its risks.
• Ship without known exploitable vulnerabilities, with a secure default configuration and a way to reset it.
• Accept security updates, with automatic updates on by default where applicable, a clear opt-out and the option to postpone them.
• Protect against unauthorized access through authentication and identity or access management, and report possible unauthorized access.
• Protect the confidentiality and integrity of data, commands, programs and configuration, for example with encryption.
• Process only the data it needs for its intended purpose (data minimization).
• Keep essential functions available, including under denial-of-service attacks, and limit its impact on other devices and networks.
• Limit its attack surface and use exploit mitigation techniques.
• Record and monitor relevant internal activity, with an opt-out for the user.
• Let users remove all data and settings securely and permanently.

Vulnerability handling and the SBOM

Annex I, Part II, covers the processes behind the product. For the whole support period, manufacturers must:

• Draw up a software bill of materials (SBOM) in a common, machine-readable format that covers at least the top-level dependencies.
• Fix vulnerabilities without delay and, where technically feasible, ship security updates separately from feature updates.
• Test and review the product's security regularly.
• Publish information about fixed vulnerabilities once an update is available, including impact, severity and how to fix them. In justified cases, publication can wait until users have had a chance to patch.
• Enforce a coordinated vulnerability disclosure policy, with a contact address for reporting vulnerabilities.
• Distribute updates securely and, for security updates, automatically where applicable.
• Release security updates without delay and free of charge, with advisory messages, unless a business customer agreed otherwise for a tailor-made product.

The SBOM is part of the technical documentation. Recital 77 states that manufacturers do not have to make it public, but a market surveillance authority can request it. Article 13(17) also requires a single point of contact for vulnerability reports, and users must be able to choose how they reach it, not only through automated tools.

Support period and security updates

Under Article 13(8), you must handle vulnerabilities effectively for a support period that reflects how long the product is expected to be in use. It is at least 5 years, unless the product is expected to be in use for a shorter time. Record the reasons for your choice in the technical documentation.

Buyers must see the end date of support, at least the month and year, at the time of purchase. Where technically feasible, the product must notify users when support ends. Each security update must stay available for at least 10 years after release or for the rest of the support period, whichever is longer (Article 13(9)).

Technical documentation and CE marking

Before placing a product on the market, the manufacturer draws up technical documentation under Article 31 and Annex VII: the product and its architecture, the vulnerability handling process with the SBOM, the cybersecurity risk assessment, the reasons for the support period, the standards applied and the test reports.

Once the conformity assessment shows the product meets Annex I, the manufacturer draws up the EU declaration of conformity and affixes the CE marking (Article 13(12)). For software, the CE marking can appear on the declaration or on the product's website (Article 30). Keep both documents for at least 10 years after placing the product on the market or for the support period, whichever is longer.

Reporting has applied since September 11, 2026

Article 14 was the first manufacturer duty to apply. Manufacturers must report actively exploited vulnerabilities and severe incidents that affect product security through ENISA's single reporting platform: an early warning within 24 hours, a notification within 72 hours and a final report later. The duty also covers products placed on the market before December 11, 2027 (Article 69(3)).

Our post on CRA reporting obligations explains each deadline, what each report contains and how to find the CSIRT (computer security incident response team) you report to.

CRA timeline and key dates

Products placed on the market before December 11, 2027 only have to meet the other requirements if they are substantially modified after that date (Article 69(2)). A change is substantial when it affects compliance with Part I of Annex I or changes the intended purpose (Article 3). The Commission's first CRA guidance (opens in a new tab) explains substantial modification, scope and support periods with practical examples. It is not legally binding.

Penalties under Article 64

Member States set penalty rules within these limits and consider the nature, gravity and duration of the breach and the size of the company. Microenterprises and small enterprises are exempt from fines for missing the 24-hour early warning deadlines. Fines can come on top of other corrective measures (Article 64(9)).

A CRA roadmap for non-EU manufacturers

The CRA applies to manufacturers outside the EU in the same way as to EU companies. With reporting already live and the main deadline in December 2027, work in this order:

1. 1Build a product inventory. List every product with digital elements you sell into the EU, its versions, its remote data processing and who places it on the market: you, an importer or a distributor.
2. 2Classify each product. Compare its core function with Annex III, Annex IV and Implementing Regulation (EU) 2025/2392. Record the result and your reasoning.
3. 3Settle your EU set-up. Decide whether to appoint an authorized representative. Agree with importers and distributors who keeps which documents and how they report vulnerabilities to you.
4. 4Run a gap assessment. Compare each product and your processes with Annex I, Parts I and II. Start the cybersecurity risk assessment early, because design decisions depend on it.
5. 5Fix process gaps first. Generate an SBOM in your build pipeline, publish a coordinated vulnerability disclosure policy, set up a single point of contact and separate security updates from feature updates.
6. 6Decide the support period. Base it on expected use, show the end date at the point of sale and plan engineering capacity for it.
7. 7Choose the conformity route. For important and critical products, contact a notified body early. Prepare the technical documentation, declaration of conformity and CE marking for every product.
8. 8Keep reporting ready. Your Article 14 process must already work for the products on the market today.

Our cybersecurity consulting team runs CRA gap assessments against Annex I and helps manufacturers set up vulnerability handling, SBOM generation and reporting. If your product includes AI, check the AI Act too. Under Article 12 of the CRA, a high-risk AI system that meets the CRA's essential requirements is deemed to meet the AI Act's cybersecurity requirement, under the conditions listed there. Our EU AI Act guide explains when an AI system is high-risk.