The strongest CRA scope assessment is a product-specific evidence record, not a yes-or-no questionnaire detached from the product architecture. Scope starts with what is supplied and how it functions, then moves through connectivity, market activity and exclusions. Classification under Annexes III and IV comes after the product has been found to be within scope.
Step 1: Identify the Exact Product Being Assessed
Begin with a named product and version rather than a company, platform or broad technology category. Record the marketed name, manufacturer, intended purpose, customer type, release or hardware revision and how the product reaches users. A company can have products that are clearly within CRA scope, products that are outside scope and internal systems that are not supplied on the market. A company-level conclusion therefore creates avoidable ambiguity.
Step 2: Define the Product Boundary
Map the software, hardware, separately marketed components and manufacturer-controlled remote functions that make up the product. Article 3 includes software and hardware products and qualifying remote data processing solutions. Identify embedded software, firmware, companion applications, APIs, databases and cloud processing where relevant. Do not automatically include every external dependency, and do not exclude essential remote functionality merely because it runs in the cloud.
Step 3: Record Intended Purpose and Reasonably Foreseeable Use
Article 2 links scope to both intended purpose and reasonably foreseeable use. Record the functions described by the manufacturer, expected deployment environment, normal users and ordinary ways in which the product can be used. Product documentation, architecture, user instructions and sales material can all help establish the factual basis. A scope conclusion should not depend solely on a narrow internal description if users can reasonably deploy the product in another connected way.
Step 4: Test the Data-Connection Requirement
Determine whether the intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Internet access is not required. Connections can include local networks, device-to-device communication, gateways, wired interfaces, wireless protocols, host operating systems and other logical or physical data relationships. Document the actual interfaces rather than using a simple connected or offline label.
Step 5: Determine Whether the Product Is Made Available on the Union Market
Identify how the product is supplied for distribution or use on the Union market. Software can be supplied through downloads, application stores, package distribution, licensing systems and other electronic channels. Hardware can move through manufacturers, importers and distributors. Record the entity supplying the product, where it is offered and whether the assessment concerns the first making available or a later supply-chain event.
Step 6: Analyse the Commercial Activity
Making available under the CRA occurs in the course of a commercial activity and can happen whether the product is supplied for payment or free of charge. Review the actual business model rather than using price as the test. Consider paid products, free commercial products, monetised platforms and the CRA's specific treatment of free and open-source software. Purely internal development presents a different market-supply question.
Step 7: Check Every Relevant Article 2 Exclusion
Run an explicit Article 2 exclusions review. Determine whether the product is governed by the Medical Devices Regulation, In Vitro Diagnostic Medical Devices Regulation or Regulation (EU) 2019/2144; is certified under the civil-aviation framework; falls within the Marine Equipment Directive; qualifies as an identical replacement spare part; or meets the national-security, defence or classified-information exclusion. Also monitor delegated acts that may limit or exclude CRA application for products subject to equivalent sectoral rules.
Step 8: Identify the Economic-Operator Roles
Once the product and market route are understood, identify who develops or has the product developed and markets it under its name or trademark, who imports it into the Union and who distributes it. Role mapping does not replace the scope test, but it identifies which organisation will carry the applicable CRA obligations after scope has been established. Own-brand arrangements and later substantial modifications can change the role analysis.
Step 9: Treat Classification as a Separate Decision
After concluding that the product is within CRA scope, determine whether it has the core functionality of a category in Annex III or Annex IV. A product can be fully subject to the CRA without being an important or critical product. Classification affects conformity assessment, not whether an otherwise covered product exists. Review the legal categories and current technical descriptions rather than classifying from the marketing name alone.
Step 10: Check the Product's Market History and Transition
For products already on the market, record when the relevant version was first placed on the Union market and whether later changes amount to a substantial modification. Article 69 provides transitional treatment for products placed on the market before 11 December 2027, while Article 14 reporting applies separately to in-scope products placed before that date. Product history therefore matters to the obligations that apply at a particular time.
Step 11: Record the Conclusion and the Facts Supporting It
The scope record should state whether the product is in scope, outside scope or requires further legal analysis. Record the product boundary, connection test, market route, commercial context, exclusion review, economic-operator roles and classification result. Cite the CRA provision relied upon for important conclusions. Where a conclusion depends on a factual assumption, state that assumption so it can be reviewed later.
Step 12: Add Scope Review Triggers
CRA scope should not be treated as a permanent label attached to a product forever. Reassess when software becomes commercially distributed, an internal tool becomes a product, a remote service becomes necessary for a function, a product enters a new market, ownership or branding changes, a component is sold separately, functionality changes substantially or relevant sectoral legislation changes. The scope record should travel with the product lifecycle and should include explicit review triggers for changes that could alter the CRA conclusion.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.