Cyber Resilience Act: How to Classify Your Product

The Cyber Resilience Act (CRA) is already in force, but for many companies its consequences are still an abstraction. According to a recent Bitkom survey, only three in ten companies say they understand what the CRA actually means for their own business, and more than a quarter haven’t heard of it at all.

That gap matters, because the CRA doesn’t ask a simple yes-or-no question. It applies to almost any product with digital elements, from consumer software to industrial control systems, and sorts each one into a risk tier with its own set of obligations. Figuring out which tier applies, and in which role, is the first concrete step toward compliance.

What Counts as a “Product With Digital Elements”?

Under the CRA, a “product with digital elements” is any software or hardware product, together with any remote data processing solution it relies on, that connects to another device or network, whether that connection is direct or indirect, physical or logical. That definition is intentionally broad. It covers everything from mobile devices and IoT sensors to network infrastructure and locally installed software, regardless of whether the product is ever meant to touch the public internet. Even air-gapped systems, such as certain industrial control systems or power plant components, typically fall within scope, because the CRA’s connectivity test focuses on the product’s design, covering scenarios beyond how it happens to be deployed today.

Not every product that fits this definition falls under the CRA. Products already regulated by other EU sector-specific rules are excluded: medical devices, in-vitro diagnostics, vehicle type-approval, civil aviation, and marine equipment, along with products built exclusively for national security or defense. The goal is to avoid duplicate regulation where a sector-specific framework already delivers comparable protection.

Standalone services fall outside the CRA’s scope, but a remote data processing solution built into a product is covered too, as long as the product can’t perform its intended function without it. A smart refrigerator with a cloud-based recipe feature illustrates this: both the device and the connected service need to meet CRA requirements. More complex software-as-a-service (SaaS) setups need to be assessed case by case.

Products already placed on the market before the compliance deadline aren’t automatically in scope. They only become subject to the CRA if a manufacturer makes a substantial modification afterward.

The CRA’s Four Risk Tiers

Once a product falls under the CRA, the next question is how strictly it’s regulated. The CRA sorts products with digital elements into four tiers based on the cybersecurity risk tied to their core function: standard products, important products class I, important products class II, and critical products. Classification follows the product’s primary purpose. A router with a firewall feature stays a router. A smartphone running an operating system stays a standard product. Since November 2025, Implementing Regulation (EU) 2025/2392 spells out binding technical descriptions for all 28 categories listed in Annex III and Annex IV.

Tier	Examples
Standard products (~90% of all products)	Smartphones, tax-filing software, robot vacuums, Bluetooth item trackers
Important products, Class I (19 categories)	Password managers, identity management systems, browsers, operating systems, routers and switches, VPN products, smart home security devices such as locks and cameras, SIEM systems
Important products, Class II (4 categories)	Firewalls, intrusion detection and prevention systems, hypervisors, container runtime systems, tamper-resistant microprocessors
Critical products (3 categories)	Hardware devices with security boxes, smart meter gateways and comparable devices for secure cryptoprocessing, smartcards and similar devices including secure elements

What Your Tier Means for Conformity Assessment

The tier a product falls into determines how a manufacturer proves compliance:

• Standard products qualify for self-assessment through internal production control.
• Class I products can also self-declare, but only against harmonized European standards; without a matching standard, manufacturers need a notified body to review the product design, plus internal production control.
• Class II products always require that external review.
• Critical products need a European cybersecurity certificate at “substantial” assurance level once a suitable scheme exists, and are treated like Class II products in the meantime.

Right now, the self-declaration route for Class I products is largely theoretical. As of September 2026, no harmonized standard for the CRA has been cited in the EU Official Journal, and no notified body is yet listed for CRA assessments. Many manufacturers currently need external assessment even for products that were designed for the lighter self-declaration path.

Who the CRA Assigns Obligations To

Beyond a product’s tier, the CRA also assigns obligations based on the role an organization plays in getting it to market. Manufacturers aren’t the only ones covered; obligations are spread across the entire supply chain:

• Manufacturer: develops a product, or has one developed, and places it on the market under its own name or brand. This applies regardless of whether the company operates from within the EU.
• Authorized representative: appointed voluntarily by a manufacturer based outside the EU, and takes on administrative duties such as keeping the declaration of conformity and technical documentation available for market surveillance authorities.
• Importer: places a product carrying a non-EU brand on the EU market.
• Distributor: makes a product available on the market without being its manufacturer or importer, and without changing its properties. Distributors still carry verification, information, and record-keeping obligations.

Importers and distributors become manufacturers themselves once they market a product under their own brand or make substantial modifications to it. For any single product, an organization typically holds only one of these three roles: manufacturer, importer, or distributor. Depending on its portfolio, though, the same organization can hold different roles for different products.

The CRA also creates a distinct role for open-source stewards: non-profit organizations, such as the Apache, Eclipse, or Linux Foundation, that sustainably provide open-source components for use in commercial products. Stewards don’t affix a CE mark. Instead, they need a cybersecurity policy and, depending on how involved they are, reporting obligations when actively exploited vulnerabilities or severe incidents surface. Open-source projects without a profit motive generally stay outside the CRA’s scope, even when commercial companies contribute significantly to them. The Linux kernel is a good example: Red Hat and Canonical contribute heavily, while the Linux Foundation’s non-profit structure keeps the project itself outside the CRA.

Where This Leaves You

Working through this in practice comes down to three questions:

1. Does your product meet the CRA’s definition without one of the sector-specific exemptions applying?
2. What is your product’s core function, matched against the technical descriptions in Annex III and Annex IV?
3. Which role does your organization hold for that product: manufacturer, authorized representative, importer, distributor, or open-source steward?

Answering these questions moves you from “I’ve heard of the CRA” to “I know what applies to us,” which helps to close the gap the Bitkom survey uncovered. Classification is the foundation everything else builds on.