Find the exact question, open the source answer card, and copy a direct link to the anchored sub-FAQ response.
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.
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.
The Commission's March 2026 draft CRA guidance frames the Article 3(2) definition around three checks: the processing is at a distance, the product cannot perform one of its functions without that processing, and the relevant software was designed and developed by the manufacturer or under its responsibility.
All three checks matter. A cloud-hosted function can be outside RDPS if the manufacturer did not design or commission the relevant software, and remote telemetry can be outside RDPS if the product still performs its functions without that processing.
Article 3(2) provides the legal definition that the three-part test applies.
Points 164 and 168-186 explain the draft interpretation of the three RDPS elements and cloud service models.
No. The draft guidance says the function test is not limited to the product's core functionality or narrow intended purpose. It can include functions that directly serve users and functions that support the product's overall performance.
Examples can include remote configuration, synchronisation, remote commands, onboarding, authentication, identity and access management, or updates if the product offers those as functions and the other RDPS criteria are met.
Points 173-175 explain that RDPS functions are not limited to core functionality and can include supporting product functions.
No. The location and hosting model do not decide the outcome by themselves. The draft guidance says remote processing can happen over wired or wireless connections and can run in public cloud, private cloud, edge environments, or on local servers on the manufacturer's premises.
The practical question is whether the relevant software part performs data processing at a distance for a product function and falls under the manufacturer-design or manufacturer-responsibility test.
Points 169-171 explain the draft meaning of processing at a distance across public cloud, private cloud, edge, and local-server scenarios.
Recital 11 explains that processing or storage at a distance is in scope only where necessary for product functions.
No. Recital 11 says RDPS requirements do not turn the manufacturer's network and information systems as a whole into the CRA product. The draft guidance also treats RDPS as the software elements of remote data processing, not the underlying hardware infrastructure.
For conformity assessment, the draft guidance points to the parts of the system where data needed for product functions is stored or processed. Other backend systems can still create risks that the manufacturer must assess, but they are not automatically part of the product scope as RDPS.
Recital 11 limits RDPS scope and excludes measures for the manufacturer's network and information systems as a whole.
Points 164, 189, and 190 distinguish RDPS software scope, relevant data-processing parts, underlying hardware, and surrounding environment risks.
Usually not if they only provide information and do not support product functionality. Recital 12 says websites that do not support the functionality of a product with digital elements do not fall within CRA scope as products with digital elements.
A website or portal can be different if it actually supports a product function and meets Article 3(2). For example, a manufacturer-controlled authentication portal, command interface, or configuration portal may need RDPS analysis, while a static instruction page normally does not.
Recital 12 distinguishes websites that do not support product functionality from remote processing that meets the CRA definition.
Section 1.2 explains that websites supporting product functionality may fall in scope to the extent they meet the RDPS definition.
Point 178 supports the distinction between informational web pages and portals that enable product functions.
The draft guidance treats this as broader than in-house development but narrower than buying or licensing a standard third-party service. It covers remote processing software built for the manufacturer based on the manufacturer's designs and specifications.
That means outsourced development can still be under the manufacturer's responsibility, but a general-purpose SaaS product normally is not RDPS merely because the manufacturer configures or integrates it.
Points 179 and 180 explain tailor-made software, outsourced development, licensing, and the distinction between design responsibility and day-to-day operation.
The cloud service model helps identify which software the manufacturer designed or controls, but it is not a substitute for the Article 3(2) test.
In the draft guidance, the manufacturer's own software running on third-party IaaS may qualify as RDPS if the other criteria are met. On third-party PaaS, the manufacturer's application layer may qualify, while provider platform functions may not. A third-party SaaS application that the manufacturer did not design or commission is generally not RDPS, even if the product depends on it.
Recital 12 names SaaS, PaaS, and IaaS as cloud service models while keeping RDPS tied to the CRA definition.
Points 181-185 apply the RDPS test to third-party IaaS, PaaS, and SaaS examples.
No. If the product needs the service for a function but the relevant software was not designed and developed by the manufacturer or under its responsibility, the draft guidance says the service should be handled similarly to a third-party component rather than classified as RDPS.
That does not make the dependency irrelevant. The manufacturer still needs to assess the risks created by integrating or relying on that service and apply due diligence or product-level mitigations where needed.
Section 1.2 distinguishes standalone SaaS or cloud solutions developed outside the manufacturer's responsibility from RDPS.
Points 184-186 and 190 explain third-party SaaS, component-like treatment, due diligence, and risk assessment.
Usually not, where the product can still perform its functions without that remote processing. The draft guidance gives remote analysis of telemetry for statistical purposes or future product development as an example of processing that is not RDPS when it is not needed for a product function.
Internal organisational systems such as HR, payroll, CRM, CI/CD, threat-hunting, penetration-testing, or red-team tooling are also not normally RDPS for the product. They may still matter to security posture and risk assessment, but they are not automatically part of the product with digital elements.
Points 165-167 and 176-177 address internal organisational systems and telemetry or analytics that are not needed for product functions.
No, not merely because the product uses connectivity. The draft guidance's cellular-network use case treats the network as a communication channel in that scenario, not as remote data processing whose absence prevents the product from performing a function in the Article 3(2) sense.
The manufacturer still has to consider network-related risks in the product risk assessment and mitigate them through product-level controls where relevant.
Article 13(2)-(3) requires cybersecurity risk assessment for the product, including its conditions of use and operational environment.
Section 8.3.5 applies the RDPS analysis to a cellular network use case and distinguishes connectivity from component-style software integration.