What the Cyber Resilience Act requires of manufacturers

Scope: who the CRA applies to

The CRA applies to products with digital elements placed on the EU market — hardware and software products whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. This covers a very broad range of products, from consumer IoT devices to industrial controllers, network equipment and standalone software. A small number of product categories are excluded because they are already regulated by sector-specific rules that address equivalent cybersecurity requirements, such as certain medical devices, vehicles and aviation equipment; manufacturers should check the exclusions on a product-by-product basis rather than assuming an entire sector is out of scope.

The regulation also introduces a category of 'important' and 'critical' products with digital elements, listed in annexes, which attract stricter conformity assessment routes because of their higher risk profile — examples include operating systems, firewalls, and industrial automation and control components.

The core obligations

• Security by design and by default: risk assessment during planning and design, and minimisation of the attack surface, exposed interfaces and default access.
• Essential cybersecurity requirements: covering aspects such as confidentiality, integrity, secure default configuration, vulnerability handling capability, and protection against unauthorised access.
• A cybersecurity risk assessment, documented and kept up to date, and used to justify design and process decisions.
• Technical documentation demonstrating conformity, retained for a defined period after the product is placed on the market.
• A software bill of materials (SBOM) covering the product's dependencies, in a commonly used machine-readable format.
• A vulnerability handling process, including coordinated disclosure, a point of contact, and free security updates for the support period.
• Reporting of actively exploited vulnerabilities and severe incidents to the relevant authority within defined timelines.
• Conformity assessment appropriate to the product's classification, followed by CE marking and an EU declaration of conformity.

Where organisations typically underestimate the work

The essential requirements are written at a level of generality that makes them easy to agree with and hard to implement without translation into concrete engineering practice. A common failure mode is treating the CRA as a documentation exercise layered on top of an unchanged development process, rather than as a set of constraints that need to shape architecture, component selection and release engineering from the start. Retrofitting vulnerability handling, SBOM generation and update mechanisms into a product line late in its life is materially harder than designing for them.

A second common gap is ownership. The obligations span security engineering, quality, legal and product management, and organisations that assign the CRA to a single function — usually whichever team already deals with cybersecurity — tend to under-resource the parts that depend on other functions, particularly the support-period commitments and the update mechanism.

Practical steps

• Classify each product line: default, important, or critical, and confirm which conformity assessment route applies.
• Map the existing development lifecycle against the essential requirements and identify gaps rather than assuming coverage.
• Stand up SBOM generation as part of the build pipeline, not as a manual end-of-project task.
• Define the vulnerability intake, triage and disclosure process, including a published point of contact.
• Define the support period for each product and the mechanism by which updates will actually reach deployed units.
• Assemble technical documentation incrementally, as design decisions and verification results are produced, not retrospectively.

What reviewers and auditors expect to see

Conformity assessment bodies and market surveillance authorities expect technical documentation that shows a coherent chain: identified risks, the design and process decisions taken in response, and verification evidence that those decisions were implemented and are effective. They also expect the vulnerability handling process to be demonstrably operating, not merely documented — for example, evidence of intake records, triage decisions and update releases. A written policy with no operating history is a common source of findings.

For the reporting obligations specifically, reviewers will look for a decision chain that can act inside the 24-hour early warning and 72-hour notification windows, supported by an accurate, queryable inventory of shipped versions and components.

Frequently asked questions