Find the exact question, open the source answer card, and copy a direct link to the anchored sub-FAQ response.
No.
Those products are excluded, as are products specifically designed to process classified information.
Article 2(7) excludes products developed or modified exclusively for national security or defence purposes and classified-information processing products.
FAQ 1.8 explains the national-security and defence exclusion.
No.
The Commission FAQ says dual-use products remain subject to the CRA when made available on the market unless they are developed or modified exclusively for national security or defence purposes.
FAQ 1.8 states that dual-use products remain covered unless exclusively developed or modified for national security or defence.
Article 2(7) sets the exclusive national-security, defence, and classified-information exclusion.
The CRA does not apply to:
- products to which Regulation (EU) 2017/745 on medical devices applies
- products to which Regulation (EU) 2017/746 on in vitro diagnostic medical devices applies
- products to which Regulation (EU) 2019/2144 on vehicle type approval applies
- products certified in accordance with Regulation (EU) 2018/1139 on civil aviation
- equipment within the scope of Directive 2014/90/EU on marine equipment
Article 2(2) to (4) lists medical-device, vehicle type-approval, certified aviation, and marine-equipment exclusions.
FAQ 1.9 explains the Article 2 sectoral exclusions and related component boundaries.
Yes. Commission Delegated Regulation (EU) 2025/1535 excludes products with digital elements falling within Regulation (EU) No 168/2013 on two- or three-wheel vehicles and quadricycles, except the L1e category vehicles designed to pedal identified in Article 3(94)(b) of that Regulation.
Article 1 establishes the exclusion for products within Regulation (EU) No 168/2013 and preserves the stated exception for L1e category vehicles designed to pedal.
FAQ 1.9 identifies the Delegated Regulation (EU) 2025/1535 exclusion for certain Regulation (EU) No 168/2013 vehicle products.
Yes.
Article 2(5) allows the Commission to adopt delegated acts limiting or excluding the CRA for products covered by other Union rules that address all or some of the same risks, where the regulatory framework remains coherent and the sectoral rules achieve the same or a higher level of protection.
Article 2(5) empowers the Commission to limit or exclude products where other Union rules cover the same risks at the same or higher protection level.
Yes.
The CRA excludes spare parts made available to replace identical components in products with digital elements where those spare parts are manufactured according to the same specifications as the components they replace.
Article 2(6) excludes identical spare parts manufactured to the same specifications as the components they replace.
Yes.
The CRA does not prevent Member States from setting additional cybersecurity requirements for procurement or use for specific purposes, including national security or defence procurement or use, as long as those requirements are consistent with Union law and are necessary and proportionate.
Article 5(1) preserves proportionate Member State cybersecurity requirements for procurement or use for specific purposes.
FAQ 1.8 discusses Member State procurement or use requirements in national-security and defence contexts.
Yes.
The draft guidance says it does not matter whether the code is uncompiled, compiled, or interpreted. If a manufacturer provides computer code to customers as part of a commercial activity, that code is placed on the market for CRA purposes even if the customer still has to adapt or compile it before use.
Draft points 20 to 22 and Example 5 address compiled, interpreted, and uncompiled source code supplied commercially.
Article 3(4) defines software in a way that includes computer code.
Yes. For the ordinary manufacturer regime, free and open-source software falls within CRA product scope when it is made available on the market in the course of a commercial activity. Recital 18 says free and open-source software that is not monetised by its manufacturer should not be considered commercial activity.
A free repository release therefore is not enough by itself. The facts that matter are who places the software on the Union market, whether that specific software is monetised by that actor, and whether the actor is instead functioning as an open-source software steward for software intended for commercial activities.
Recitals 18 to 19 and Article 3 definitions distinguish commercial market placement, repository hosting, and open-source software steward roles.
The draft open-source guidance explains product-specific manufacturer and steward role distinctions for monetised and non-monetised FOSS.
No.
The draft guidance says public sharing of free and open-source computer code in repositories is not by itself placing that code on the market. It also says unfinished code shared during design and development, and sample or demo code provided in tutorials or training materials, is not considered placed on the market.
Draft point 21 distinguishes commercial market placement from public repositories, unfinished review code, and tutorial or demo code.
Article 3(22) defines placing on the market and Article 4(3) covers limited testing availability for unfinished software.
Yes.
The Commission FAQ gives the example of an offline text editor or calculator that does not itself initiate communications but runs on a host operating system that does. In that situation, the software can still be indirectly connected within the CRA meaning.
FAQ 1.3 gives the offline text-editor and calculator examples for indirect connection through a host operating system.
Article 3(10) and recital 9 define indirect connection and explain the attack-vector rationale.
Not by itself.
The draft guidance says a data connection requires digital information to be deliberately encoded and capable of being decoded as data at the destination. Signals used only to power or trigger a function do not create a CRA data connection. The Commission FAQ's electric-toothbrush example illustrates the same boundary.
Draft points 23 to 25 explain that data must be deliberately encoded and decodable, not merely a power or trigger signal.
FAQ 1.3 includes the electric-toothbrush example for products without digital data exchange.
Article 2(1) and Article 3(7) to (10) define the connection concepts used for the data-connection boundary.
Yes.
The draft guidance says systems composed of multiple hardware and software elements that operate together to perform a certain function can be a single product with digital elements where that system is placed on the market as a single product. Their complexity, long lifecycle, or reliance on older components does not exclude them from scope by itself.
Draft points 26 to 29 discuss multi-element systems placed on the market as one product.
Article 3(1) defines products with digital elements and Article 13(3) requires the risk assessment to be considered during planning, design, development, production, delivery, and maintenance.
No. The finished-product manufacturer remains responsible for the cybersecurity of the product it places on the market, including integrated components. A component supplier may have its own CRA duties if the component is itself a product with digital elements placed on the market separately, but that does not transfer the finished-product manufacturer's obligations.
The manufacturer may rely on upstream conformity work where it is relevant, but still has to exercise due diligence, assess whether the component compromises the finished product, and address vulnerabilities in integrated components during the support period.
Article 13(5) to (6) and recital 34 require due diligence for third-party components and action on vulnerabilities in integrated components.
FAQ section 4 explains that finished-product manufacturers can integrate non-CE-marked or out-of-scope components but remain responsible for the whole product.
The draft guidance states that CRA cybersecurity risk and responsibility cannot be transferred to users or third parties by contract.
Under Article 3(2), remote data processing means data processing at a distance where the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, and the product would not be able to perform one of its functions without it.
Because Article 3(1) defines a product with digital elements as including its remote data processing solutions, qualifying RDPS is treated as part of the CRA product boundary. Recital 11 gives the example of a mobile application that needs a manufacturer-provided API or database service to perform a function.
Record the decision at the level of each remote software element and product function. Identify what fails when the remote element is unavailable, who specified or controlled its development, which product versions depend on it, and which interfaces and data flows enter the risk assessment. Do not classify an entire cloud account or corporate network as RDPS when only specific software elements meet Article 3(2).
Article 3(1), Article 3(2), and Recital 11 define products with digital elements, RDPS, and the API/database example.
Section 1.2 confirms that a product with digital elements includes remote data processing solutions.