The Cyber Resilience Act explained for software makers

The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) requires manufacturers of products with digital elements – hardware and software – to ensure cybersecurity across the entire lifecycle. It has been in force since 10 December 2024, but obligations apply in stages: rules for conformity assessment bodies from 11 June 2026, reporting obligations from 11 September 2026 and everything else from 11 December 2027.

For mid-sized companies this means: if you sell software, firmware or connected devices in the EU, you need a working reporting process within months and robust technical documentation with CE marking by the end of 2027.

What is the Cyber Resilience Act?

The CRA is an EU regulation and applies directly in all member states. It follows the logic of EU product law (New Legislative Framework): whoever places a product on the market must demonstrate that it meets essential requirements and confirm this with an EU declaration of conformity and the CE mark.

Scope: products with digital elements

In scope are products whose intended use includes a direct or indirect data connection to a device or network. That covers off-the-shelf software, apps, firmware, IoT devices, networked industrial controllers and separately sold components. Remote data processing solutions without which a product cannot perform one of its functions also count as part of the product.

Exclusions

• Products already covered by sector rules, such as medical devices, in-vitro diagnostics, motor vehicles and certain aviation equipment.
• Pure software-as-a-service with no link to a product generally falls under NIS2, not the CRA.
• Free and open-source software not supplied in the course of a commercial activity.

The three key dates

Manufacturer, importer, distributor

Most obligations fall on the manufacturer – whoever develops a product, or has it developed, and markets it under their own name or trademark. Importers must check that non-EU manufacturers have met their obligations. Distributors check CE marking and documents. Anyone who sells a product under their own name or substantially modifies it becomes a manufacturer.

Essential requirements in Annex I

Annex I has two parts: requirements on product properties and requirements on vulnerability handling.

• Part I – product: no known exploitable vulnerabilities at release, secure-by-default configuration, protection against unauthorised access, confidentiality and integrity of data, data minimisation, reduced attack surface, support for security updates.
• Part II – vulnerability handling: maintain a software bill of materials (SBOM), remediate vulnerabilities without delay, test regularly, disclose fixed vulnerabilities, publish a coordinated vulnerability disclosure (CVD) policy, distribute updates securely.

Article 13 adds a documented cybersecurity risk assessment, a support period of generally at least five years (shorter only if the expected use time is shorter) and technical documentation according to Annex VII.

Penalties

Article 64 sets three tiers of fines. In each case the higher of the fixed amount and the share of worldwide annual turnover applies.

Authorities can also order withdrawals or recalls. Micro and small enterprises get one relief: no fine for missing the 24-hour early-warning deadline.

First steps

1. Build a product inventory: which products and versions with digital elements are on the market, and who is the manufacturer of each?
2. Get report-ready: name owners, define escalation paths, publish a contact point for vulnerability reports.
3. Set up SBOMs: capture dependencies in machine-readable form – the basis for quickly identifying affected products.
4. Check the product category: default, important (class I/II) or critical? It determines the conformity assessment procedure.
5. Plan documentation: build risk assessment, support period and technical documentation by the end of 2027.

Practical examples

Machine builder with remote maintenance

A packaging machine maker ships systems with a controller, an HMI panel and a remote maintenance module. The machine itself is covered by the Machinery Regulation; the digital elements are additionally covered by the CRA. The manufacturer therefore needs a risk assessment, an SBOM and an update process for controller software, panel firmware and remote client – and from September 2026 a reporting route if, say, a library in the remote module is actively exploited.

Software house with an on-premise product

A software house sells an ERP extension that customers install on their own servers. That is a classic product with digital elements. Key issues are the support period – customers often use such systems well beyond five years –, secure defaults at installation and a way to ship security updates separately from feature updates.

Agency with a white-label app

A digital agency builds an app for a retailer that appears under the retailer's brand. The retailer is usually the manufacturer; the agency, however, supplies the evidence conformity depends on. Clarifying these roles early in contracts avoids disputes when it counts.

CRA, NIS2 and Machinery Regulation compared

Many companies are affected by several regimes at once. A machine builder can be a manufacturer under the CRA and an operator under NIS2. It pays to organise evidence so it can be reused across regimes.

How Nuowei helps

Nuowei is a CRA compliance platform by hafencity.dev in Hamburg, currently in beta. It connects to your repositories, generates SBOMs, matches vulnerabilities and collects evidence for your technical documentation. Launch is planned for November 2026 – join the waitlist for early access.