CRA Check

This questionnaire is intentionally manufacturer-focused. If you import a product from a third country into the EU market under the original supplier's identity, you are usually acting as an importer rather than as the manufacturer. Importer obligations are addressed separately in Article 19.

The CRA can still push an importer into the manufacturer role if the importer places the product on the market under its own name or trademark, or if later guidance treats a change as a substantial modification. If that is your situation, re-run this assessment from the manufacturer perspective.

A distributor usually makes a product available further down the supply chain without being the manufacturer or importer. That is a narrower role than the manufacturer role described in Article 3.

The CRA can still be relevant for distributors, but this assessment is designed for manufacturers only.

Article 24 creates a lighter regime for open-source software stewards. That path is different from the full manufacturer path and is aimed at legal persons that systematically support open-source software intended for commercial activities without themselves placing the product on the market as the manufacturer.

If you also market a product with digital elements under your own name or trademark, you may still be a manufacturer under Article 3 and should use the manufacturer path.

The CRA starts from role definitions such as manufacturer, importer, distributor and open-source software steward. Those definitions sit in Article 3, with additional role-specific obligations in provisions such as Article 19 and Article 24.

If you cannot tell whether you place the product on the market under your own name or trademark, you should resolve that point before relying on the rest of the classification logic.

Article 2 applies the CRA to products with digital elements that are placed on the market. If the product is not being placed on the EU market in the course of a commercial activity, the regulation does not apply.

This should be revisited if the distribution model changes, for example if the product later becomes available to customers or business users in the EU.

The central scope concept in Article 2 is the product with digital elements. Article 3 explains that this covers software products, hardware products with software or firmware, and related remote data-processing solutions when they are necessary for the product to perform its functions.

If your product truly has no software, no firmware and no necessary remote digital functionality, it is usually outside the CRA.

The CRA is aimed at products with digital elements, not at every digital service. Article 2 and the product definition in Article 3 are still relevant, because some remote data-processing solutions remain inside the CRA when they are necessary for the product to perform its functions.

If the offering is only a website, hosted service or SaaS product and no regulated product depends on that remote processing to function, the CRA manufacturer path usually does not apply.

Article 2(2) excludes several areas from the CRA.

If your product is fully inside one of those exclusions, you should follow the sector-specific rules instead of relying on the CRA manufacturer path.

Article 8 and Annex IV describe critical products with digital elements. These are the highest-risk categories in the CRA framework, such as certain secure hardware devices, smart meter gateways and smartcards or similar secure elements.

Critical classification does not change the basic manufacturer duties: you still need the lifecycle risk assessment from Article 13, the essential cybersecurity requirements from Annex I, and the technical documentation described in Annex VII. It does change the conformity assessment path under Article 32, which is the most demanding tier.

Article 7 and Annex III split important products with digital elements into class I and class II. Class II contains the smaller set of higher-sensitivity categories such as hypervisors, container runtimes, firewalls, IDS/IPS products and certain tamper-resistant chips.

The core idea is still the same: the CRA applies because the product is in scope, and the manufacturer must perform the same foundational work on cybersecurity risk, essential requirements, vulnerability handling and documentation. The difference is the conformity assessment route in Article 32, where class II sits above the default path and above the easier class I path.

Under Article 7 and Annex III, the product appears to fall into an important class I category. Class I covers categories such as operating systems, browsers, password managers, VPN products, routers, smart home security products and other products listed in Annex III.

If applicable harmonised standards are used for the CRA requirements, Article 32 allows the easier conformity assessment path inside class I. That does not remove the underlying manufacturer duties: you still need the risk assessment, essential requirements, vulnerability handling, support-period thinking and technical documentation.

The product appears to be in scope under Article 2, but it does not obviously match the important-product categories in Annex III or the critical-product categories in Annex IV. That usually means the product remains in the default CRA tier.

Even in the default tier, the manufacturer still has substantial duties: the lifecycle cybersecurity risk assessment in Article 13, the essential requirements in Annex I, the documentation in Annex VII, and the conformity assessment path in Article 32.

The early answers suggest that the CRA may matter, but the product class is still unclear. Under the CRA, classification should follow the core function of the finished product and then be checked against Annex III and Annex IV.

If you cannot confidently identify whether the product belongs to a critical category, an important class II category, an important class I category, or none of them, you should treat this as a legal and technical classification issue rather than guessing.