Cyber Resilience Act (CRA): obligations for software and hardware manufacturers

Jump to frequently asked questions

What is the Cyber Resilience Act and when does it apply?

The Cyber Resilience Act (CRA) is the first European regulation to set across-the-board security requirements for hardware and software placed on the EU market.

In plain terms: what has so far applied to toys or electrical appliances (safe product, CE marking) now applies to cybersecurity too - and, for the first time, to standalone software as well.

When do the individual obligations start?

The Regulation entered into force on 10 December 2024 and has staggered applicability:

The key date for most companies is 11 September 2026. The reporting obligation is not tied to the date a product is placed on the market - it will also cover products that are already being sold today. From my circle of clients I can tell that this is something almost nobody is paying attention to yet.

Who does the CRA apply to?

The CRA applies to manufacturers of both hardware and software, without distinction. A product with digital elements is any software or hardware that connects to a data network - including components placed on the market separately. A developer that places software on the EU market is therefore a manufacturer with all the related obligations. And it is software companies that, in our view, the CRA will hit hardest, because until now they have not been subject to any conformity assessment regime.

Watch out for the manufacturer fiction

If you have an application developed by a contractor and distribute it under your own brand, you are legally the manufacturer, not your contractor. It makes no difference whether you sell the product or provide it for free. The same rule applies to an importer or distributor that sells the product under its own brand or substantially modifies it.

And what about SaaS and cloud?

Providers of purely digital services fundamentally do not fall under the CRA - they are regulated by the NIS2 Directive, transposed in the Czech Republic by the new Cybersecurity Act.

There is, however, one crucial exception: a cloud without which the product cannot deliver one of its functions is part of the product. A typical example? A smart home camera without its own storage that streams video to the manufacturer's cloud. Without the cloud you cannot view the recording - the cloud is therefore part of the product and must meet the CRA requirements.

Not sure whether you are a manufacturer under the CRA? We will run an initial cybersecurity assessment for you - we will go through your products, contracts with suppliers and the overlap with NIS2 and the AI Act, and tell you exactly what applies to you. Get in touch.

What counts as a product with digital elements?

The defining feature is data connectivity. The Regulation applies to products whose intended purpose or reasonably foreseeable use includes a direct or indirect connection to a device or a network. It is deliberately a broad concept. The following will therefore meet under one regulation:

• Consumer electronics - routers, smart watches, baby monitors, connected toys, a washing machine with an app.
• Standalone software - operating systems, mobile applications, and most likely video games too.
• Industrial systems - control systems, smart metering gateways.

The European Commission estimates that around 90 % of products on the market will fall into the default category. The Regulation then grades the regime by risk level: important products (e.g. password managers, firewalls, hypervisors) are subject to stricter conformity assessment procedures, and critical products (e.g. smart cards or hardware devices with security modules) may be subject to mandatory European certification.

Areas the CRA does not cover

The exclusions are exhaustive and sectoral: medical devices, motor vehicles, civil aviation and marine equipment - these areas have their own, often stricter, safety regimes. Free and open source software is also excluded, provided it is not supplied on the market in the course of a commercial activity.

What obligations does the CRA introduce?

The starting point is the principle of security by design and security by default - the product must be designed and developed so that it is secure from the outset. In concrete terms, Article 13 requires you to:

• Assess security risks before the product is placed on the market and keep the documentation up to date for the whole support period.
• Deliver the product without known exploitable vulnerabilities, with a secure default configuration, encryption and a minimised attack surface.
• Maintain a Software Bill of Materials (SBOM) - a machine-readable list of all the components in the product - and set up a process for handling vulnerabilities: free updates, a coordinated disclosure policy and a contact point for reporting.
• Set the support period - typically at least five years.
• Undergo conformity assessment and obtain CE marking. For default products, usually via internal control; for important and critical products, via a stricter procedure. Yes, you read that right: software will need CE marking too.
• Keep the technical documentation for at least ten years from the date the product is placed on the market.
• Report vulnerabilities and incidents - more on this in the next section.

Who bears liability when development is outsourced?

One thing that people often overlook: the obligations rest with the manufacturer even if the development is done by someone else. The CRA does not push liability onto suppliers by itself - you need to address that in the contract. When you buy in development or components, work the CRA requirements into your supplier contracts, in the same way regulated companies do when running supplier checks under the new Cybersecurity Act.

Vulnerability reporting from 11 September 2026: the first hard deadline

From 11 September 2026 you will have 24 hours. That is how long you get, once someone is actively exploiting a vulnerability in your product, to send an early warning to the coordinating CSIRT team and to ENISA. The same rules (Article 14 of the Regulation) apply to any severe incident affecting the security of the product. Reports are submitted through a single European platform.

Reporting deadlines

• Within 24 hours of becoming aware of it - early warning.
• Within 72 hours - vulnerability or incident notification.
• Within 14 days of a corrective measure becoming available - final report (for severe incidents, within one month).

To repeat: from 11 September 2026 this obligation covers products that are already on the market today. You do not get to wait until December 2027.

What does the Czech adaptation act cover and why not wait for it?

The Czech Republic is preparing an adaptation act on cybersecurity requirements for products with digital elements. The bill is currently going through the legislative process - and here is an important note: do not wait for the Czech act. The CRA is a regulation, meaning a legal act that is binding in its entirety and directly applicable in all Member States. The obligations will arise directly from the Regulation, on the European timeline, regardless of where the Czech legislative process stands.

The adaptation act only adds the domestic elements that the Regulation leaves to the Member States.

Supervision split across 12 authorities

The draft assigns market surveillance to sector-specific authorities depending on the type of product - from the Czech Trade Inspection Authority through the State Energy Inspection to the Assay Office. NÚKIB sits alongside them as the notifying authority and technical support. The model follows the existing market surveillance architecture, but for software makers it means uncertainty: you build a smart thermostat with an app and a cloud - is it an energy product, an electrical device, or a designated product? Practice will have to work that one out.

Mandatory Czech

A manufacturer and an importer placing a product on the market in the Czech Republic must provide contact details in Czech, and the manufacturer must ensure that the information and instructions for users are provided in Czech (Section 9 of the bill). This may sound like a detail, but a breach is an administrative offence with a maximum fine of EUR 15,000,000 or 2.5 % of worldwide turnover - the same bracket as placing an unsafe product on the market. For software companies that today only develop products in English, this is a big deal.

What penalties are on the table?

The fine ranges are set by Article 64 of the Regulation. The higher figure always applies - either the absolute amount or the percentage of turnover.

The top bracket also captures "merely" failing to report an actively exploited vulnerability - the very obligation that kicks in as early as September 2026. The Regulation is friendly to micro and small enterprises: they will not be fined for missing the 24-hour early warning deadline.

And one more penalty that gets talked about less but hurts the most: the market surveillance authority can order a product to be withdrawn from the market or ban it from being supplied. A fine is a one-off hit. A ban on the product means zero revenue and open doors for the competition.

How to prepare for the CRA in 5 steps

1. Work out whether the CRA applies to you. It sounds banal, but this is the step that companies skip most often - and then they either pay for compliance they do not need, or find out a year after the deadline that they were a manufacturer without realising it. Combine this initial analysis with a review of other regulations (NIS2, the AI Act, sector-specific rules).
2. Map your product portfolio - which products count as products with digital elements, which category they fall into (default / important / critical) and which of them are already on the market.
3. Set up the vulnerability reporting process by 11 September 2026 - who spots the vulnerability, who sends the early warning within 24 hours, and who communicates with the CSIRT and ENISA.
4. Get ready for December 2027 - risk assessment, SBOM, security updates, support period, technical documentation, conformity assessment and CE.
5. Review your supplier contracts - the liability under the CRA sits with you, so lock in cooperation, warranties and information duties from your suppliers by contract.

Want to have the CRA sorted before the fines start biting? At SEDLAKOVA LEGAL we combine cybersecurity with IT law and TMT law - we will help with impact analysis, setting up processes and drafting supplier contracts. Drop us a line.

Do not wait for September

Only a few months remain before the vulnerability reporting obligation kicks in, and the full applicability of the CRA in December 2027 calls for changes to development, documentation and contracts - none of which can be pulled off in a month. At SEDLAKOVA LEGAL we specialise in cybersecurity and have helped dozens of companies prepare for NIS2 - with the CRA we will support you from the initial analysis through setting up the reporting processes to drafting supplier contracts.

Need advice on the CRA? Get in touch.