Does the current grounding also identify an additional vehicle-related exclusion outside the core Article 2 list?
Yes.
The Commission FAQ says Delegated Regulation (EU) 2025/1535 also excludes products with digital elements falling within the scope of Regulation (EU) No 168/2013 on two- or three-wheel vehicles and quadricycles, except L1e category vehicles designed to pedal.
Are there other products that may later be limited or excluded because sectoral rules already cover the same risks?
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.
Are identical spare parts excluded from the CRA scope?
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.
Can Member States still impose additional cybersecurity requirements when procuring or using CRA products for specific purposes?
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.
Can source code itself be a product with digital elements when it is supplied commercially?
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.
Is publicly shared source code, unfinished review code, or tutorial and demo code automatically in scope as a CRA product?
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.
Can software that is offline by itself still be indirectly connected and therefore in scope?
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.
Does wireless charging or a simple electrical on/off signal count as a CRA data connection?
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.
Can a complex system made up of multiple hardware and software elements still be one CRA product?
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.
What does the CRA's secure-by-default requirement mean?
The CRA requires products with digital elements to be made available on the market with a secure-by-default configuration, based on the manufacturer's cybersecurity risk assessment and in light of the product's intended purpose and reasonably foreseeable use.
This is not a generic slogan. It is a concrete Annex I requirement.
Does secure by default mean the same default settings for every product?
No.
The default configuration has to be determined through the risk assessment for the specific product. What is secure by default for one product category may not be secure by default for another.
Does secure by default mean the product always has to ship in the most restrictive technically possible state?
No.
The CRA ties the default configuration to the product's intended purpose, reasonably foreseeable use, and the manufacturer's cybersecurity risk assessment. So the legal test is not whether the product is maximally locked down in the abstract, but whether its default configuration is secure for the way the product is meant and reasonably expected to be used.
What kinds of settings or product states may need to be secure by default under the CRA?
That depends on the product, but the CRA and Commission materials point toward defaults that reduce cybersecurity risk at first use.
The Commission FAQ gives examples such as insecure or deprecated cryptographic algorithms being disabled by default, certificate validation being enabled by default, or network interfaces being disabled by default until needed.
Does the CRA require automatic security updates to be enabled by default?
Where applicable, yes.
Annex I Part I, point (2)(c) says vulnerabilities must be addressable through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe and enabled as a default setting. That default setting must come with a clear and easy-to-use opt-out mechanism and the option to postpone updates temporarily.
Can users turn off CRA automatic security updates?
Yes.
The CRA requires a clear and easy-to-use opt-out mechanism and an option to postpone updates temporarily. Annex II also requires instructions on how the default automatic-installation setting can be turned off.
Are CRA automatic security updates required for every product?
No.
Recital 56 says the automatic-update expectations do not apply to products primarily intended to be integrated as components into other products. It also says they do not apply to products for which users would not reasonably expect automatic updates, including products intended for use in professional ICT networks and especially in critical and industrial environments where automatic updates could interfere with operations.
If CRA automatic updates are not appropriate, does the manufacturer still have update obligations?
Yes.
Recital 56 says that irrespective of whether a product is designed to receive automatic updates, the manufacturer should inform users about vulnerabilities and make security updates available without delay.
If a user opts out of CRA automatic updates, is the manufacturer then compliant automatically?
Not automatically, but the manufacturer is not responsible under the CRA for the user's refusal to install updates.
The Commission FAQ says the manufacturer is not responsible if the user does not install security updates, including where the user opts out. But the manufacturer still must design the product and its processes so updates can be distributed, notified, and installed as required.