# The EU Cyber Resilience Act explained for hardware teams

Who the CRA applies to, the key dates, what manufacturers must do and which technical documentation, including the SBOM, you need to keep and for how long.

*Reviewed on 17 October 2026.*

## What is the EU Cyber Resilience Act?

The **EU Cyber Resilience Act (CRA)**, [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng), is an EU regulation that sets cybersecurity requirements for products with digital elements: hardware and software that connect to a device or a network, including firmware-based products and components sold separately. Most obligations fall on the manufacturer, the company that places the product on the EU market under its own name. Manufacturers must design products to an appropriate level of security (Annex I), handle vulnerabilities for a support period of at least five years unless the product is expected to be in use for less time (Article 13(8)), and report actively exploited vulnerabilities and severe incidents, starting with an early warning within 24 hours (Article 14). They must also keep technical documentation, including a software bill of materials (SBOM), for at least ten years (Article 13(13)), and affix the CE marking before the product is sold. Reporting applies from 11 September 2026 and the rest of the regulation from 11 December 2027 (Article 71).

Article references in this guide point to the official text on EUR-Lex.

## This guide and its companion pages

This page explains the regulation: who it covers, when it applies and what it requires. Three companion pages go further:

- **[CRA engineering checklist](https://neopdm.com/en/cra-engineering-checklist)**: the work for an engineering team, step by step from classification to retention, with the Article or Annex behind each item. You can print it.
- **[SBOMs and product data](https://neopdm.com/en/sbom-product-data)**: what the CRA requires of a software bill of materials, which formats and data fields to use, and how to tie each SBOM to a firmware version and hardware revision.
- **[CRA compliance with neo](https://neopdm.com/en/cra-compliance)**: how neo keeps the technical documentation controlled and linked to product revisions, and what neo does not do.

## Who the CRA applies to

The regulation covers **products with digital elements**, defined in Article 3(1) as "a software or hardware product and its remote data processing solutions", including components placed on the market separately. If your product contains firmware, connects to a network or an app, or ships with software, it is likely in scope.

Most obligations fall on the **manufacturer**, the company that places the product on the EU market under its own name or trademark. Importers and distributors have their own, lighter obligations.

Article 2 excludes some products that sector legislation already covers:

- Medical devices under Regulation (EU) 2017/745 and in vitro diagnostic medical devices under Regulation (EU) 2017/746.
- Vehicles under Regulation (EU) 2019/2144.
- Civil aviation products under Regulation (EU) 2018/1139 and marine equipment under Directive 2014/90/EU.

If you build medical devices, check which of your products the MDR or IVDR covers and which it does not. Accessories, companion hardware and non-medical product lines can still fall under the CRA. Annex III, for example, lists personal wearables with a health monitoring purpose to which the MDR and IVDR do not apply.

![Three questions. If the product has no digital elements or data connection, it is out of scope. If it falls under MDR, IVDR or the vehicle, aviation or marine rules, it is excluded. If you do not place it on the market under your own name, you are an importer or distributor with lighter obligations. Otherwise you are the manufacturer and the CRA applies.](https://neopdm.com/diagrams/cra-scope.en.svg)

## Timeline

![Published 20 November 2024, in force 10 December 2024, conformity assessment bodies from 11 June 2026, Article 14 reporting from 11 September 2026, full application from 11 December 2027.](https://neopdm.com/diagrams/cra-timeline.en.svg)

| Date | What happens | Source |
|---|---|---|
| 20 November 2024 | Regulation published in the Official Journal | OJ L, 2024/2847 |
| 10 December 2024 | Regulation enters into force | Article 71(1) |
| 11 June 2026 | Rules on notification of conformity assessment bodies apply (Chapter IV) | Article 71(2) |
| 11 September 2026 | Reporting obligations for actively exploited vulnerabilities and severe incidents apply (Article 14) | Article 71(2) |
| 11 December 2027 | The regulation applies in full | Article 71(2) |

Two details are easy to miss. The Article 14 reporting obligations apply to all in-scope products, including those placed on the market before 11 December 2027 (Article 69(3)). Products placed on the market before 11 December 2027 are subject to the other requirements only if they undergo a substantial modification from that date (Article 69(2)).

## Key obligations for manufacturers

### Essential cybersecurity requirements

Annex I Part I requires products to be designed, developed and produced to ensure "an appropriate level of cybersecurity based on the risks". It lists specific properties, among them: no known exploitable vulnerabilities at release, a secure by default configuration, the ability to receive security updates, access control, confidentiality and integrity of data, data minimisation, a limited attack surface, security logging, and a way for users to securely remove their data and settings.

### Vulnerability handling

Annex I Part II sets out how manufacturers must handle vulnerabilities during the support period. They must identify and document components and vulnerabilities, remediate vulnerabilities without delay, test security regularly, publish information about fixed vulnerabilities, maintain a coordinated vulnerability disclosure policy, distribute updates securely, and provide security updates without delay and free of charge.

### Risk assessment and due diligence

Article 13(2) requires a cybersecurity risk assessment that informs planning, design, development, production, delivery and maintenance. Article 13(5) requires due diligence when you integrate third-party components, including open-source software.

### Support period

The support period must be at least five years, unless the product is expected to be in use for less time, in which case it matches the expected use time (Article 13(8)). Each security update issued during the support period must remain available for at least 10 years after it is issued, or for the rest of the support period if that is longer (Article 13(9)). The manufacturer must tell users the end date of the support period (Annex II).

### Reporting

Under Article 14, manufacturers notify actively exploited vulnerabilities and severe incidents to the CSIRT designated as coordinator and to ENISA, through the single reporting platform. The deadlines: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report (14 days after a fix is available for vulnerabilities, one month after the notification for incidents). The [checklist](https://neopdm.com/en/cra-engineering-checklist) sets the deadlines out in a table, together with the process around them.

### Conformity assessment and CE marking

Before placing a product on the market, the manufacturer runs a conformity assessment, draws up an EU declaration of conformity (Article 28) and affixes the CE marking (Article 30). The procedure depends on the product's class (Article 32):

| Product class | Examples from the regulation | Conformity assessment |
|---|---|---|
| Default | Most products with digital elements | Internal control (module A) is permitted |
| Important, class I (Annex III) | Operating systems, routers and switches, password managers, microcontrollers with security-related functionalities, smart home products with security functionalities | Module A only if harmonised standards, common specifications or a certification scheme are applied; otherwise third-party assessment (modules B and C, or H) |
| Important, class II (Annex III) | Firewalls, intrusion detection systems, hypervisors, tamper-resistant microcontrollers | Third-party assessment (modules B and C, or H) or a European cybersecurity certification scheme |
| Critical (Annex IV) | Hardware devices with security boxes, smart meter gateways, smartcards and secure elements | European cybersecurity certification scheme where required, otherwise as class II |

A product counts as important when its core functionality matches an Annex III category (Article 7(1)). Containing such a component is not enough on its own.

## What technical documentation does the CRA require?

Under the CRA, **technical documentation** is the file a manufacturer draws up before placing a product with digital elements on the EU market, to show that the product meets the essential cybersecurity requirements (Article 31). Annex VII sets its minimum contents: a general description of the product and its intended purpose; design, development and production information such as drawings and system architecture; the vulnerability handling process, including the software bill of materials (SBOM); the cybersecurity risk assessment; the reasoning behind the support period; the standards or specifications applied; test reports; and the EU declaration of conformity. The SBOM must be in a commonly used, machine-readable format and cover at least the top-level dependencies (Annex I, Part II, point 1), but the manufacturer does not have to publish it (recital 77). The documentation must be kept up to date and available to market surveillance authorities for at least ten years after the product is placed on the market, or for the support period if that is longer (Article 13(13)).

The [checklist](https://neopdm.com/en/cra-engineering-checklist) breaks Annex VII into items you can tick off, and [SBOMs and product data](https://neopdm.com/en/sbom-product-data) covers the SBOM in depth.

## What this means for engineering and product data

The CRA is a cybersecurity regulation, yet much of the work lands on how your team controls engineering data. For hardware teams, that means:

- **Documentation must match a specific product.** Software versions, the SBOM, test reports and the declaration of conformity all describe a particular build. When firmware or hardware changes, you need to know which documents change with it.
- **Changes need traceability.** You will need evidence to show whether a change is a "substantial modification": what changed, why, and who approved it.
- **Records must outlive the product team.** Ten years or more is longer than most file shares, tools and employees last, so your documentation has to stay findable and intact.
- **Suppliers are part of the picture.** Due diligence on third-party components means you collect and control supplier information alongside your own.

## How to get started

1. **Map your portfolio.** List products with digital elements and check each against the exclusions and the Annex III and IV categories.
2. **Prepare for reporting.** Article 14 already applies. Define who receives vulnerability reports, who decides, and who notifies.
3. **Decide the support period** for each product and record the reasoning.
4. **Set up SBOM generation** in your firmware and software build process with a dedicated tool.
5. **Structure the technical documentation** per Annex VII and link it to product revisions.
6. **Run a gap assessment** against Annex I and plan the conformity route.

The [CRA engineering checklist](https://neopdm.com/en/cra-engineering-checklist) breaks these steps down further.

## Where a PDM system helps

A PDM system does not make a product secure, generate an SBOM or scan for vulnerabilities; those need dedicated tooling and a vulnerability handling process. What it can do is keep the risk assessment, SBOM, test reports and declaration of conformity versioned, approved and linked to the product revision they describe, for as long as the regulation requires. [CRA compliance with neo](https://neopdm.com/en/cra-compliance) shows how that works in neo and where the limits are, or you can [talk to us](https://neopdm.com/en/contact) about your products.