Does the EU Cyber Resilience Act apply to your product? Scope, definitions and the product classification system explained

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) (the “CRA”) entered into force on 10 December 2024 and will apply in full from 11 December 2027. On 27 July 2026, the EU Commission published its long-awaited guidance on the CRA (C(2026) 5252), clarifying how it applies in practice. For businesses that design, develop or sell hardware or software in the EU, the first and most critical question is whether – and at what tier – the CRA catches their products. Below we unpack the scope, key definitions and the three-tier product classification system that will determine how demanding compliance obligations will be. 

Which products does the CRA cover?

The CRA applies to “products with digital elements”, i.e. any software or hardware product, together with its remote data processing solutions, whose intended purpose or reasonably foreseeable use includes a direct or indirect, logical or physical, data connection to a device or network. The definition is deliberately broad: it covers everyday connected consumer devices (such as smart doorbells, smartwatches and connected toys), a commercially licensed password manager, an enterprise firewall appliance, an industrial programmable logic controller (PLC) with remote monitoring capability and a general-purpose operating system.

Two conditions are key: (i) the product must be capable of connecting to a network or other device; a purely offline product such as a standalone USB charging cable or an industrial sensor with no network interface falls out of scope; and (ii) the product must be placed on the EU market as part of a commercial activity. Software developed by a company’s IT team for internal use only and never placed on the market is also out of scope.

What are the key definitions businesses need to know?

Several definitions are central to understanding where obligations take effect:

• Remote data processing solutions: Data processing at a distance that the manufacturer designs or develops, or that is developed under its responsibility, and without which the product could not perform one of its functions. Such solutions are treated as part of the product and fall within scope, for example, the cloud back-end that lets a smart thermostat be controlled from its app. A standalone web app merely accessed through a browser is not caught.
• Manufacturer: Any natural or legal person who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its own name or trademark – whether for payment or free of charge. The manufacturer bears the primary CRA obligations; importers and distributors carry verification duties.
• Vulnerability: A weakness, susceptibility or flaw that can be exploited by a cyber threat.
• Exploitable vulnerability: A vulnerability with the potential to be effectively used by an adversary under practical conditions.
• Actively exploited vulnerability: One for which there is reliable evidence of exploitation in the wild. This requires mandatory 24-hour ENISA notification.
• Support period: The period – minimum five years, unless the product’s expected lifetime is shorter – during which the manufacturer must handle vulnerabilities and issue security updates. A consumer smart home hub expected to be in use for five to eight years would satisfy the five-year minimum; a router deployed in critical infrastructure or an industrial SCADA component active for 15–20 years requires a support period that reflects that reality.
• Software bill of materials (SBOM): A formal record of all software components and their supply chain relationships, which manufacturers must maintain as part of their technical documentation.
• Substantial modification: A post-market change that affects the cybersecurity of a product or alters its intended purpose. The change is treated as putting a new product on the market, which triggers a fresh conformity assessment. Adding a new authentication module that broadens the attack surface would likely qualify; issuing a patch to close a known SQL injection vulnerability would not.

How are products classified?

The CRA creates a three-tier hierarchy based on cybersecurity risk. The tier a product falls into determines the conformity assessment route. Which tier applies turns on the product’s core functionality; its main features and technical capabilities, without which it could not meet its intended purpose. A product has only one core functionality for classification purposes, and ancillary functions do not change the tier. 

1. Default products form the catch-all category covering the vast majority of products with digital elements. Manufacturers self-certify using the internal control procedure (Module A) with no third-party body required. A smart TV without dedicated security functionality, a connected coffee machine or a general-purpose e-commerce application would all sit in this tier.
2. Important products (Annex III) are divided into two classes:
   1. Class I covers identity management and privileged access management software, standalone browsers, password managers, antivirus tools, VPN products, network management systems, SIEM systems, boot managers, PKI software, physical and virtual network interfaces, operating systems, routers, switches and modems intended for internet connectivity, microprocessors and microcontrollers with security functionalities, and a range of consumer-facing products carrying a potential security risk: smart door locks, security cameras, baby monitors, alarm systems, internet-connected toys with social or location features, and personal health wearables marketed to children or with health-monitoring functions. A commercially sold VPN client, a consumer-grade Wi-Fi router or a smart door lock with app connectivity are therefore all Class I products. Class I manufacturers may self-certify only if they apply a relevant harmonised standard, common specification or EU cybersecurity certification scheme; otherwise, third-party assessment is mandatory. 
   2. Class II covers hypervisors and container runtime systems, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers. The heightened risk profile of these products – think of an enterprise next-generation firewall, a hardware-based intrusion prevention system deployed by a bank, or a hypervisor underpinning a cloud computing environment – makes mandatory third-party conformity assessment (Module B+C, Module H or a qualifying EU cybersecurity certification scheme at “substantial” assurance level) proportionate.
3. Critical products (Annex IV) represent the highest-risk tier: hardware devices with security boxes (devices with a tamper-responsive physical enclosure, such as secure payment terminals), smart meter gateways managing energy data for national grids and other devices for secure crypto processing (such as the HSMs banks use to protect cryptographic keys), and smartcards or similar devices, including secure elements (such as the secure element embedded in a contactless payment card). These must obtain a European cybersecurity certificate under an EU cybersecurity certification scheme, with the Module B+C or H procedures serving as a fallback in the absence of an applicable scheme.

The EU Commission retains power to amend Annexes III and IV by a delegated act, so a product sitting comfortably in the default tier today may be reclassified as important or critical as the threat landscape evolves.

Are any products excluded?

The following fall entirely outside the scope of the CRA:

• Sector-regulated products: Products subject to sector-specific EU legislation achieving at least equivalent cybersecurity protection. A pacemaker or implantable cardiac monitor falls under the EU Medical Device Regulation; the software stack of a type-approved vehicle ECU is governed by Regulation (EU) 2019/2144 and UN Regulation No 155; avionics software is certified under EASA rules. None of these are subject to the CRA. 
• National security and defence: Products procured or used exclusively for national security, defence or classified purposes.
• In-house software: Bespoke software developed in-house and never placed on the market, such as a claims-management application built by an insurer for its own internal operations.

One important qualification: a general-purpose laptop or tablet is not excluded simply because it is used in a healthcare setting. The device itself is not a medical device, and it falls squarely within the CRA’s scope. Where sector-specific rules cover only some of the risks addressed by the CRA, the CRA applies to the remainder.

What is the position of open-source software?

Non-commercial open-source software distributed outside a commercial context is out of scope. The Linux kernel, as maintained by the Linux Foundation as a broad community project with no single entity monetising it directly, illustrates the type of project that falls outside the CRA’s scope. The mere receipt of donations or financial contributions does not change that status. 

Where open-source software is monetised by a company (for example, the company commercially distributes a hardened Linux distribution system under a paid enterprise licence), that company is a manufacturer for CRA purposes and the full regime applies.

Organisations that sustainably support the development of open-source software components intended for commercial use, without themselves manufacturing products, qualify as “open-source software stewards”. An organisation employing engineers to maintain a widely used open-source cryptography library on which its commercial products depend may fall into this category. Stewards face lighter obligations than manufacturers: principally, they must put in place a security policy and cooperate with market surveillance authorities, rather than be subject to the full conformity assessment regime. How much more applies scales with the type of support provided: a steward that supplies development infrastructure must notify severe incidents, and one that contributes engineering resources must also report actively exploited vulnerabilities it becomes aware of.

When does the CRA apply?

• 11 September 2026: Vulnerability and incident reporting obligations (the 24-hour/72-hour ENISA notification regime) apply from this date.
• 11 December 2027: All remaining obligations (such as conformity assessment, CE marking, technical documentation and the full suite of manufacturer duties) apply from this date.

What does this mean for businesses?

1. Map your product portfolio. Identify every product with digital elements placed on the EU market and determine which tier it falls into. A product wrongly self-certified as default when it should be Class I or II faces significant remediation costs and potential market access issues.
2. Check sector exclusions carefully. Businesses in automotive, medical devices or aviation should verify whether their products are fully excluded or whether the CRA applies to residual risks not covered by sector-specific rules. Mixed-use products (such as a tablet sold both as a general consumer device and as a hospital bedside terminal) may require careful analysis.
3. Review your open-source strategy. If your product integrates open-source components, the CRA’s due diligence requirements apply to those components. If you support open-source projects that feed into commercial products, consider whether the open-source software steward regime applies.
4. Monitor delegated and implementing acts. The EU Commission may amend the product lists by a delegated act – adding, withdrawing or reclassifying categories between Class I and Class II in Annex III, and adding or withdrawing critical categories in Annex IV – and may specify the categories’ technical descriptions by an implementing act.