Cyber Resilience Act: what manufacturers must do and when

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets horizontal cybersecurity requirements for products with digital elements on the Union market. It addresses both the security of the product and the processes used to handle vulnerabilities. This overview explains the main questions a manufacturer needs to resolve; it is information, not legal advice or a decision about a particular product.

Which products are covered?

Start with the product actually being supplied. Article 2(1) covers products with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. An internet connection is not the only relevant connection. Software and hardware components placed on the market separately can also be products within the definition in Article 3(1).

The definition includes remote data processing solutions where the conditions in Article 3(2) are met: processing at a distance designed by, or under the responsibility of, the manufacturer, without which the product could not perform one of its functions. Assess the product and its dependencies together. The presence of a cloud service does not, on its own, settle the scope question.

Article 2 contains specific exclusions, including products covered by specified medical-device and vehicle legislation, certain aviation products, marine equipment, qualifying identical spare parts and products developed or modified exclusively for national security or defence. These are qualified legal exclusions. An industry label alone is insufficient. Free distribution or an open-source licence also needs a separate assessment of the supply and the role involved.

Who is the manufacturer?

Under Article 3(13), the manufacturer is the person or organisation that develops or manufactures the product, or has it designed, developed or manufactured, and markets it under its own name or trademark. The definition covers supply for payment, monetisation or free of charge. Outsourcing development does not remove the need to identify the manufacturer.

Record the legal entity, the product and the name under which it is marketed. Distinguish that role from importer, distributor and open-source software steward. Commercially supplied open-source software cannot be assessed merely by whether its source is public. The CRA distinguishes the manufacturer from an open-source software steward and discusses non-commercial open-source development in its recitals. Resolve these boundaries before selecting a conformity route.

Three application dates, with different effects

Article 71(2) provides the following application dates. They do not all trigger the same obligations:

• 11 June 2026: Chapter IV, Articles 35–51, has applied since this date. It concerns notification of conformity assessment bodies; this is not the general start date for manufacturers’ product obligations.
• 11 September 2026: Article 14 reporting obligations have applied since this date. They concern actively exploited vulnerabilities and severe incidents affecting product security.
• 11 December 2027: the Regulation generally applies from this date, including the main manufacturer obligations on product requirements, vulnerability handling and conformity.

Do not treat an earlier release as an automatic reporting exemption. Article 69(3) extends Article 14 to in-scope products placed on the market before 11 December 2027. Article 69(2) separately addresses other requirements for those products when they undergo a substantial modification from that date. Keep reporting readiness and the assessment of future releases on separate work tracks.

Secure development starts with the risk assessment

Article 13(1)–(4) connects product design, development and production to Annex I, Part I. Manufacturers must assess cybersecurity risks and take the results into account across planning, design, development, production, delivery and maintenance. The assessment is documented and updated as appropriate during the support period. It considers intended purpose, foreseeable use, conditions of use and expected time in use.

Annex I addresses matters such as secure default configuration, protection against unauthorised access, data confidentiality and integrity, attack surfaces and security updates. Applicability follows the risk assessment and the legal conditions. Where a requirement does not apply, the technical documentation needs a clear justification. As practical preparation, connect each applicable requirement to an implementation choice and supporting test evidence.

Vulnerability handling continues after delivery

Article 13(8) requires effective handling of vulnerabilities, including those in components, when placing the product on the market and during the support period. Annex I, Part II covers remediation, regular security tests and reviews, coordinated vulnerability disclosure, a reporting contact and secure update distribution. Supplier components remain relevant to the manufacturer’s own assessment.

The support period must reflect expected use and the factors specified in Article 13(8). Its minimum is five years unless expected use is shorter, in which case it corresponds to that expected use. Preparation should include an owner for incoming reports, a way to identify affected releases, and a record of corrective measures. These are working suggestions; the statutory requirements remain the reference.

An SBOM supports the process

Annex I, Part II, point 1 requires identification and documentation of vulnerabilities and components, including a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies. The CRA does not name a mandatory SBOM standard in that provision. An inventory needs to relate to the product being assessed, rather than an unrelated development environment.

An SBOM alone does not demonstrate that all cybersecurity requirements have been met. Nor does the CRA create a general duty to publish every SBOM for unrestricted download. Read the guide to CRA SBOM requirements for the distinction between drawing up the inventory, including it in technical documentation, and providing it in the circumstances specified by the Act.

Technical documentation explains the evidence

Before placing a product on the market, manufacturers must draw up the technical documentation under Article 13(12). Article 31 and Annex VII describe its scope. It must cover the relevant information about how the product and manufacturer processes meet Annex I, including the risk assessment and vulnerability-handling procedures. Keep documentation current as required by Article 31(2).

A useful preparation step is to connect product identification, design decisions, component information and test reports. Mark unresolved assumptions instead of presenting them as established facts. A folder containing an SBOM and a scan export is not, by itself, the complete technical documentation described in the Regulation.

Article 14 reporting has its own triggers and clocks

Article 14 distinguishes an actively exploited vulnerability contained in a product from a severe incident affecting its security. A finding needs assessment against the legal trigger. Both the early warning and notification require action without undue delay, with outer limits of 24 and 72 hours from the manufacturer becoming aware. Submitting the early warning does not restart the 72-hour period.

The final-report events differ: for a vulnerability, no later than 14 days after a corrective or mitigating measure becomes available; for an incident, within one month after the incident notification is submitted. Read the Article 14 reporting guide before using the deadline calculator. The ENISA Single Reporting Platform guide explains recipients and preparation. A saved draft is not a submitted report.

Choose the conformity assessment for the actual category

Article 32 sets the conformity assessment procedures. Important products in Annex III are divided into classes I and II; critical products are listed in Annex IV. Classification depends on core functionality and the applicable legal conditions. Integrating an important component does not, by itself, make the whole product important under Article 7(1).

The available route depends on category, applicable standards or specifications and, where relevant, cybersecurity certification. Internal control is not available on identical terms for every category. Following the applicable assessment, demonstrated conformity leads to the EU declaration of conformity and CE marking under Article 13(12). Check current implementing and delegated acts before deciding the route; this overview does not decide it for a specific product.

Where to go next

For a preliminary scope and category assessment, use the self-check. It is available in English and German. Use the glossary to clarify terms before completing a product-specific assessment. crAcken’s free resources collect these tools and the detailed guides.

Sources and limits

• Regulation (EU) 2024/2847 on EUR-Lex (opens in a new tab): Official Journal text, especially Articles 2, 3, 7, 8, 13, 14, 31, 32, 69 and 71; Annexes I, III, IV and VII.
• ENISA: vulnerability services and the Single Reporting Platform (opens in a new tab): reporting context and access to platform information.

Read the applicable legal text and current official guidance for your product. This introduction does not establish that a product is within scope, that an event is reportable, or that a particular assessment procedure is sufficient.