A product is generally within the Cyber Resilience Act when it is a software or hardware product made available on the EU market and its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. That test also reaches separately marketed software or hardware components and, in defined circumstances, remote processing that is necessary for a product function. Scope can still be changed by the commercial context, free and open-source software rules, or a specific exclusion in the Regulation.
For manufacturers, the useful question is therefore not simply "does it contain software?" A defensible CRA scope decision needs a clear product boundary, a market analysis, a connectivity analysis, and a check for sector-specific rules.
The four-part CRA scope test
Article 2 and Article 3 of Regulation (EU) 2024/2847 can be turned into a practical sequence.
- Identify the product with digital elements. Determine the software product, hardware product, separately marketed component, and any remote data processing that belongs to the product boundary.
- Check whether it is made available on the Union market. The CRA uses the concept of supply for distribution or use in the course of a commercial activity, whether in return for payment or free of charge.
- Check the connection. The intended purpose or reasonably foreseeable use must include a direct or indirect logical or physical data connection to a device or network.
- Check exclusions and sector rules. Some products are excluded because other EU legislation applies, while additional sector rules can limit how the CRA applies.
If all four steps are documented, product teams have a much stronger basis for deciding which lifecycle, evidence, conformity-assessment, vulnerability-handling, and reporting processes must be attached to the product.
What is a "product with digital elements"?
The CRA definition is deliberately broad. A product with digital elements is a software or hardware product and its remote data processing solutions, including software or hardware components that are placed on the market separately.
That means the scope is not limited to finished consumer devices. Depending on how they are supplied and connected, it can include:
- connected hardware products;
- standalone software products;
- embedded software supplied as part of a product;
- software components placed on the market separately;
- hardware components placed on the market separately; and
- manufacturer-controlled remote processing that is necessary for one of the product's functions.
The component point matters for engineering organisations. A library, firmware package, module, processor, interface component, or other digital element should not automatically be treated only as an internal dependency. If it is itself placed on the market separately, it can have its own CRA product context.
Conversely, identifying a component inside an in-scope product does not automatically mean that every upstream developer is the manufacturer of a separately regulated product. The legal role depends on who makes the relevant product available on the market, under whose name or trademark, and under what commercial circumstances.
Connectivity is broader than an internet connection
Article 2 does not require a public internet connection. It refers to a direct or indirect, logical or physical data connection to a device or network.
The Regulation defines a logical connection as a virtual representation of a data connection implemented through a software interface. A physical connection is implemented through physical means such as electrical, optical or mechanical interfaces, wires, or radio waves. An indirect connection can exist where the product connects as part of a larger system that is itself directly connectable to a device or network.
This makes several shortcuts unreliable. A product is not necessarily outside scope because it has no Wi-Fi, no Ethernet port, or no permanent cloud connection. USB, serial links, field buses, removable interfaces, radio links, software APIs, or integration through a larger connected system can all be relevant to the connectivity analysis, depending on the product design and reasonably foreseeable use.
The correct evidence is a product-specific architecture record: interfaces, supported deployment modes, network relationships, intended integrations, and reasonably foreseeable technical interactions.
Intended purpose and reasonably foreseeable use both matter
Manufacturers should not scope a product only against the narrowest wording in a user manual. The CRA considers both the intended purpose and reasonably foreseeable use.
The intended purpose is the use specified by the manufacturer in instructions, sales and promotional material, statements, and technical documentation. Reasonably foreseeable use extends beyond that documented purpose to uses likely to result from reasonably foreseeable human behaviour, technical operations, or interactions.
For scope work, this means engineering and product teams should compare at least four sources:
- the product specification and architecture;
- user and installation documentation;
- sales and marketing descriptions; and
- integrations and deployment patterns that customers can reasonably be expected to use.
If those sources describe different connectivity assumptions, the scope record should resolve the inconsistency rather than simply selecting the most convenient description.
When cloud functionality becomes part of the product boundary
The CRA includes remote data processing solutions in the product-with-digital-elements definition, but not every cloud service associated with a company becomes part of every product.
Remote data processing means processing at a distance where the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, and where the absence of that processing would prevent the product from performing one of its functions.
The Regulation's recitals give a useful distinction. A manufacturer-provided service that allows a smart-home device to perform a remote-control function can fall within the product boundary. A mobile application that depends on a manufacturer-provided API or database can likewise involve remote processing that belongs to the product context. By contrast, a website that does not support product functionality, or a cloud service designed and developed outside the responsibility of the product manufacturer, is not brought into the product boundary merely because the manufacturer uses it.
A practical cloud-boundary review should therefore ask:
- Is the remote software designed or developed by the manufacturer, or under its responsibility?
- Which product function depends on it?
- Would that function stop working if the remote processing were absent?
- Which APIs, databases, identity services, or other remote dependencies are part of that function?
- Which cloud services are ordinary business infrastructure rather than part of the product functionality?
Documenting this boundary is useful beyond legal classification. It also determines which assets, vulnerabilities, dependencies, and evidence belong to the product-security lifecycle.
"Free of charge" does not automatically mean outside the CRA
The CRA definition of making a product available on the market covers supply in the course of a commercial activity whether in return for payment or free of charge. A zero-price commercial product can therefore still be made available on the market.
This is important for software business models built around free tiers, bundled applications, companion software, or products distributed without a separate licence fee. The relevant question is the commercial activity surrounding the supply, not the presence of a price tag alone.
Free and open-source software has more specific treatment. Recital 18 and the Commission's implementation material explain that free and open-source software that is not monetised by its manufacturer should not be considered supplied in the course of a commercial activity merely because it is openly developed or regularly released. Financial support from manufacturers or contributions to an open-source project do not, by themselves, make the activity commercial. The CRA also creates a separate, lighter regime for qualifying open-source software stewards.
For product teams integrating open-source components, this distinction does not remove the manufacturer's responsibility for the cybersecurity of its own product. The scope question for the upstream project and the due-diligence question for the manufacturer integrating the component are separate analyses.
Important exclusions to check before assigning CRA obligations
Article 2 contains explicit exclusions. The CRA does not apply to products with digital elements where specified EU legal acts apply, including the Medical Devices Regulation, the In Vitro Diagnostic Medical Devices Regulation, and the motor-vehicle type-approval framework identified in Article 2. It also excludes products certified under the EU civil-aviation framework identified there and equipment within the scope of the Marine Equipment Directive.
Other exclusions include:
- spare parts made available to replace identical components when they are manufactured according to the same specifications as the parts they replace;
- products developed or modified exclusively for national-security or defence purposes; and
- products specifically designed to process classified information.
The Regulation also allows its application to products covered by other Union rules to be limited or excluded where the sectoral framework addresses the relevant cybersecurity risks at an equivalent or higher level and the required legal conditions are met. The Commission has already adopted additional measures under the CRA framework, so organisations in regulated sectors should verify current delegated and implementing acts rather than relying on a static exclusion checklist.
An exclusion should be recorded with the same discipline as an inclusion decision: exact product, applicable legal act, responsible legal entity, rationale, evidence, reviewer, and review date.
Scope is different from product classification
Once a product is in scope, a second question is whether it falls into the default product population or has the core functionality of an important or critical product category under Annex III or Annex IV.
Do not combine these two decisions. Scope asks whether the CRA applies to the product at all. Classification affects the conformity-assessment path and related requirements for an in-scope product. A normal connected software product does not become "out of scope" simply because it is not listed as an important or critical category.
Keeping separate records for scope and classification prevents teams from using the Annex III and Annex IV lists as if they were a complete list of products covered by the CRA.
Existing products need a separate transition analysis
A product can be within the CRA's material scope even though particular obligations do not yet apply to it.
The main CRA provisions apply from 11 December 2027. The Article 14 reporting obligations apply earlier, from 11 September 2026. The Commission's summary also explains that products placed on the market before 11 December 2027 are generally subject to the main CRA requirements from that date only if they undergo a substantial modification, while the reporting obligations apply to products with digital elements already made available on the Union market.
This distinction is operationally important. A manufacturer should not label a legacy product "out of scope" merely because the transition provisions delay some obligations. Instead, the product record should distinguish:
- material scope;
- date first placed on the market;
- current support and availability status;
- whether a substantial modification occurs after the main application date; and
- which earlier reporting obligations apply.
That structure reduces the risk of losing reporting coverage for older supported products or accidentally applying the wrong conformity workflow to an unchanged legacy product.
A practical scope record for each product
A one-page legal conclusion is not enough if the product evolves. The scope decision should be connected to the engineering facts that support it.
A useful record contains:
- product name, family, variant, and responsible legal entity;
- whether the organisation acts as manufacturer, importer, distributor, or another relevant role;
- what is supplied on the Union market and how;
- commercial-activity rationale;
- intended purpose and reasonably foreseeable use;
- hardware and software boundaries;
- separately supplied components;
- direct and indirect logical and physical connections;
- required remote data processing and its ownership;
- applicable sector legislation and any exclusion analysis;
- open-source status where relevant;
- market-entry and transition dates;
- scope conclusion and classification conclusion as separate decisions;
- evidence links, approver, decision date, and review trigger.
Useful review triggers include a new product variant, a new cloud dependency, a change in distribution model, a new integration interface, a substantial modification, or a change in applicable sector legislation.
Use scope as the start of lifecycle governance
The scope decision should become an input to product-security governance rather than disappear into a legal folder. Once a product is identified as in scope, teams need to attach the right cybersecurity risk assessment, technical documentation, vulnerability-handling process, support-period evidence, reporting responsibilities, and conformity-assessment path to the same product boundary.
This is where traceability becomes difficult in organisations that keep product definitions, requirements, evidence, vulnerability decisions, and release context in different systems. AA-sec is designed around traceability between product context, requirements, security evidence, and decisions so that scope rationale can remain connected to the relevant product or lifecycle context. It does not determine CRA conformity or replace legal analysis.
Scope decisions should be revisited, not rediscovered
For Austrian manufacturers and software companies selling into the EU, the most useful outcome is a repeatable scope method that can be applied product by product and revisited when the architecture or market model changes.
Start with the four-part test: define the product, confirm that it is made available on the Union market, analyse direct and indirect connectivity including required remote processing, and check exclusions. Then preserve the evidence behind the decision and define the events that trigger a review.
The CRA is a product-lifecycle regulation. A scope decision made once and never revisited is unlikely to remain useful as software, cloud dependencies, interfaces, variants, and distribution models change.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- The Cyber Resilience Act - Summary of the legislative text — European Commission
- Cyber Resilience Act implementation - Frequently asked questions — European Commission
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- Cyber Resilience Act - Open source — European Commission