Cyber Resilience Act (CRA): Manufacturer Obligations, Reporting since September 2026 and Practical Examples

Regulation (EU) 2024/2847, known as the Cyber Resilience Act (CRA), is the first EU-wide law setting mandatory cybersecurity requirements for hardware and software throughout their lifecycle. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents; the regulation applies in full from 11 December 2027. We explain who the CRA affects and what exactly it requires – using practical examples taken directly from the regulation's recitals.

The Cyber Resilience Act (CRA) is an EU regulation requiring manufacturers, importers and distributors to ensure that hardware and software placed on the EU market is designed securely, receives security updates for a defined period and bears the CE marking. It is the first horizontal product regulation for cybersecurity – existing legislation (the NIS2 Directive or the Cybersecurity Act) did not directly lay down mandatory security requirements for products themselves (recital 3).

While NIS2 regulates organisations and the security of their systems, the CRA regulates the product a company places on the market – regardless of the company's size or sector. The key milestones:

Products placed on the market before 11 December 2027 must meet the CRA requirements only if they undergo a substantial modification after that date (Art. 69(2)). The reporting obligation, however, always applies to them (Art. 69(3)).

The CRA applies to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network (Art. 2(1)). A product is software or hardware, including separately marketed components and their remote data processing solutions (Art. 3(1)). In practice: routers, modems, smart TVs, locks and watches, industrial sensors and control systems, operating systems, desktop and mobile apps, games, software libraries or firmware.

The recitals explain why the scope is so broad: even less critical hardware or software can serve as an entry point from which an attacker moves laterally across a network. The CRA therefore also covers products connected only logically – via network sockets, pipes, files or APIs – and products connected only indirectly, as attacks also spread by chaining several vulnerability exploits (recital 9).

Cloud and backend: when are they covered? The decisive question is whether there is a remote data processing solution – software designed by (or under the responsibility of) the manufacturer without which the product could not perform one of its functions (Art. 3(2)).

Public administration: a product provided as part of a service for a fee that merely recovers actual costs is not a commercial activity on that ground alone. Software that a public body develops or modifies exclusively for its own use is not considered made available on the market (recital 16).

Exclusions: the CRA does not apply to medical devices and in vitro diagnostic devices (they have their own IT security requirements, recital 25), type-approved vehicles (recital 27, UN Regulation No 155), certified aviation products, marine equipment, products developed exclusively for national security and defence (recital 26) and spare parts made to the same specification as the component replaced. The spare-parts exemption is meant to enable repairs and longer product lifetimes – it covers parts for legacy products as well as parts that have already undergone conformity assessment (recital 29).

The CRA applies only to products supplied in the course of a commercial activity. For open-source software, what matters is therefore not how it was developed or financed, but whether the manufacturer monetises it (recitals 15 and 18).

An open-source component intended for integration into other manufacturers' products is considered made available on the market only if it is monetised by its original manufacturer (recital 18).

Open-source software stewards are legal persons that provide sustained support for the development of open-source products intended for commercial use – typically foundations, or companies and non-profits publishing open source in a business context. Support includes, for example, hosting collaboration platforms and source code or governing and steering development. An intention to integrate a component into monetised products also exists where manufacturers integrating it contribute regularly to its development or provide regular financial support (recital 19). Stewards are subject only to a light-touch regime (Art. 24), may not affix the CE marking (recital 19) and cannot be fined (Art. 64(10)).

Practical example: a Czech company develops an IoT gateway and uses a library from GitHub that nobody monetises. The library itself is outside the CRA, but the gateway manufacturer is responsible for the entire product including that component – it must exercise due diligence (Art. 13(5)) and report a vulnerability it finds to the library's maintainer and remediate it (Art. 13(6)).

Products are divided into four categories according to risk. The category determines whether the manufacturer may assess conformity itself or needs a third party. The vast majority of products fall into the default category.

Why these products? The recitals highlight consumer products for vulnerable groups – toys and baby monitors – and products whose exploitation can harm users' health or safety: smart door locks, alarm systems, connected toys and personal wearable health technology (recital 10). In products with a cybersecurity function, such as boot managers, a vulnerability can propagate throughout the supply chain (recital 43).

Core functionality decides. Only a product whose core functionality matches an Annex III category is an important product. A firewall is a class II product, but another product that merely integrates a firewall does not become important (recital 45, Art. 7(1)). A smart TV with a built-in browser is therefore not a “browser” within class I. Technical descriptions of the categories are set out in Commission Implementing Regulation (EU) 2025/2392.

Manufacturers of open-source products in class I and II may use self-assessment (module A) if they make the technical documentation public (Art. 32(5)).

1. Risk assessment and security by design. The manufacturer must assess the product's cybersecurity risks and take them into account in all phases – from planning to maintenance (Art. 13(2) to (4)). The product must not be placed on the market with known exploitable vulnerabilities, must have a secure default configuration, access control, encryption and a minimal attack surface (Annex I). Where a requirement is not applicable, the manufacturer must justify it. The recitals give an example: a product must follow a widely recognised interoperability standard even though its security features are no longer state of the art. The manufacturer must then address the risks by other means – for instance by limiting the intended purpose to trusted environments or by informing users about the risks (recital 55).

2. Third-party components. The manufacturer must exercise due diligence regarding sourced components – including open source (Art. 13(5)). The recitals specify what that means: checking whether the component bears the CE marking, checking its security update history, verifying that it has no vulnerabilities registered in the European or another public vulnerability database, and carrying out additional security tests where appropriate (recital 34). Immediately after the transitional period, components may not yet bear the CE marking – the manufacturer must then use other means (recital 35). The documentation also includes a software bill of materials (SBOM).

3. Support period and updates. The support period must reflect the time the product is expected to be in use and be at least 5 years (Art. 13(8)). The recitals give examples:

• longer than 5 years – hardware components such as motherboards and microprocessors, network devices such as routers, modems and switches, operating systems or video-editing tools; significantly longer for industrial control systems (recital 60),
• shorter than 5 years – only if the product is genuinely used for a shorter time, e.g. a contact-tracing app for the duration of a pandemic or an app available only on a subscription basis (recital 60),
• software in several versions – the manufacturer may update only the latest version if users get it free of charge and without new hardware (e.g. an operating system upgrade not requiring a faster processor). But if a smartphone cannot run the new operating system, the manufacturer must update at least the latest compatible version (recital 40, Art. 13(10)).

Each security update must remain available for at least 10 years or the rest of the support period (Art. 13(9)). The end date of support (at least month and year) must be clearly stated at the time of purchase, and the product should notify users when support ends where technically feasible (Art. 13(19)). After support ends, the manufacturer may consider releasing the source code to another company that will continue handling vulnerabilities, or to the public; ownership can be protected by contract (recital 61).

4. Single point of contact. Users must have an easy way to report vulnerabilities to the manufacturer (Art. 13(17)). A chatbot is not enough – the manufacturer must also offer a phone number, e-mail or contact form (recital 63). A coordinated vulnerability disclosure policy is also required.

5. Documentation and cessation of business. The technical documentation and EU declaration of conformity must be kept for 10 years or for the support period, whichever is longer (Art. 13(13)). A manufacturer ceasing operations must inform market surveillance authorities and users in advance (Art. 13(23)).

A substantial modification is a change after placing on the market that affects compliance with the essential requirements or changes the intended purpose (Art. 3(30)). It matters for two reasons: it requires verifying conformity and, where applicable, a new assessment (recital 41), and for products placed on the market before 11 December 2027 it triggers the application of the CRA (Art. 69(2)). Anyone who substantially modifies a product becomes its manufacturer (Art. 22).

It does not matter whether a new feature is delivered separately or bundled with a security update (recital 39). Packaging a new feature with a patch therefore does not help.

Since 11 September 2026, manufacturers must report two types of events simultaneously to the CSIRT designated as coordinator and to ENISA via the single reporting platform (Art. 14, recital 65):

• an actively exploited vulnerability – there is reliable evidence that a malicious actor has exploited it without the system owner's permission. The recitals give the example of a weakness in identification and authentication functions. Vulnerabilities discovered in good faith during testing or research are not subject to mandatory reporting (recital 68),
• a severe incident having an impact on the security of the product – the incident affects the availability, authenticity, integrity or confidentiality of sensitive data or functions, or has led or may lead to malicious code being executed (Art. 14(5)). A typical example from the recitals: an attacker inserts malicious code into the channel through which the manufacturer releases security updates (recital 68).

Model example: a manufacturer of smart cameras discovers on Friday at 8 pm that attackers are bypassing login and viewing users' recordings. It must file the early warning by Saturday 8 pm, the notification by Monday 8 pm and the final report within 14 days after releasing a fix. At the same time, it must inform affected users and recommend measures – e.g. by publishing information on its website or contacting users directly (Art. 14(8), recital 67). If the manufacturer fails to do so in time, the CSIRT may inform users.

Where to report: to the CSIRT of the Member State of the manufacturer's main establishment, i.e. where decisions on the cybersecurity of its products are predominantly taken; if that cannot be determined, the establishment with the most employees in the EU decides (Art. 14(7)). In the Czech Republic, the coordinating CSIRT role is performed by the governmental CERT at NÚKIB. A manufacturer without an EU establishment reports according to the state of its authorised representative, importer, distributor or largest number of users.

The Commission's July 2026 guidance confirms that exploitation the manufacturer already knew about before 11 September 2026 need not be reported retroactively. The obligation does, however, also cover products sold before that date.

An importer may place on the market only a product for which the manufacturer has carried out conformity assessment, drawn up documentation and affixed the CE marking (Art. 19). A distributor verifies the CE marking and accompanying documentation (Art. 20). Both must act if they identify non-conformity or a vulnerability.

Watch out for a change of role: an importer or distributor placing a product on the market under its own name or trademark, or substantially modifying it, bears the manufacturer's obligations (Art. 21). Practical example: an e-shop that has smart cameras manufactured in Asia and sells them under its private label is the manufacturer for CRA purposes – including the support period and incident reporting.

Online marketplaces according to the recitals (recital 78): a platform that merely intermediates sales is not an economic operator under the CRA. If it also distributes the product itself, it is a distributor; if it sells its own-brand products, it is a manufacturer. It may also be a fulfilment service provider. Each case is assessed individually.

The higher amount always applies. Micro and small enterprises cannot be fined for missing the 24-hour early-warning deadline, and open-source software stewards cannot be fined at all (Art. 64(10) as corrected on 2 July 2025). Member States should not impose other pecuniary penalties on them either (recital 120). The size of the undertaking and fines imposed for the same infringement in other states are taken into account – the cumulative penalty must be proportionate (recital 120).

Who will supervise in the Czech Republic: under the draft act on cybersecurity requirements for products with digital elements prepared by the Ministry of Industry and Trade, NÚKIB will be the notifying authority. Market surveillance will remain with the authorities that already supervise products today – primarily the Czech Trade Inspection Authority, but also, for example, the Czech Mining Authority, the State Energy Inspection or the Rail Authority. A market surveillance authority can order a non-compliant product to be withdrawn from the market.

NIS2 (in the Czech Republic implemented by the new Cybersecurity Act) concerns the organisation and its services, the CRA concerns the product. One company may therefore be subject to both regimes: to NIS2 as a cloud service provider and to the CRA as the manufacturer of an app or device. CRA reporting is meant to help CSIRTs and ENISA carry out their tasks under NIS2 and raise the cybersecurity of essential and important entities (recital 66).

AI Act: high-risk AI systems that are also products with digital elements and meet the CRA's essential requirements are deemed compliant with the cybersecurity requirements of Article 15 of the AI Act (Art. 12 CRA). The Digital Omnibus strengthens this link further – see our article AI Act after the Digital Omnibus.

1. Product inventory – list the hardware, software, firmware and backends you supply to the EU market, including legacy products (reporting covers them too).
2. Determine your role – are you a manufacturer, importer, distributor or open-source steward? Do you sell anything under your own brand?
3. Classification – default, important (class I/II) or critical product? Core functionality decides.
4. Reporting process – who decides whether a vulnerability is actively exploited or an incident is severe, who files the 24-hour report (including at weekends) and how you inform users.
5. Supply chain – SBOM, component checks and supplier contracts (cooperation on vulnerabilities, component support periods, access to information).
6. Support period – set and justify it, and include the end-of-support date in your terms, e-shop and packaging.
7. Point of contact and vulnerability disclosure policy – not just a chatbot.
8. Development process – security by design, risk assessment and a rule for which updates are substantial modifications.