Search every question across CRA sub-FAQs

The CRA expects more than just recording the issue.

Article 13(6) and recital 34 require the manufacturer to inform the person or entity manufacturing or maintaining the component, address and remediate the vulnerability, and, where applicable, provide that person or entity with the applied security fix.

That does not end the finished-product manufacturer's duties.

The Commission FAQ says the manufacturer must comply with the vulnerability-handling obligations for the duration of the product's own support period, for the product in its entirety, including integrated components. If the upstream component is no longer supported, the manufacturer may still need to patch it, replace it, disable affected functions, or mitigate the risk through other means.

Yes.

The draft guidance says the cybersecurity risk assessment must cover relevant risks that originate outside the product itself, such as external networks, environmental factors, infrastructure, or other systems on which the product relies. The CRA then requires those risks to be mitigated through product-level measures rather than by imposing obligations on the outside environment.

It depends on whether the service qualifies as a remote data processing solution.

If the relevant software is designed and developed by the manufacturer or under its responsibility, and its absence would prevent the product from performing one of its functions, it can be part of the product as RDPS. If that second condition is met but the software is a third-party solution not designed and developed by the manufacturer or under its responsibility, the draft guidance says it should be treated similarly to a third-party component: the manufacturer must assess the integration risk and exercise due diligence.

Not necessarily.

The draft guidance's cellular-network example says such a network does not qualify as RDPS and should not be treated like a third-party component where no provider software is integrated into the product. The manufacturer still has to assess the network-related risks and address them through product-level controls.

No.

The draft guidance says the CRA does not provide for transfer of cybersecurity risk or responsibility to users or third parties. Contracts, service levels, and supplier commitments can support compliance and due diligence, but the obligation to place a compliant product on the market remains with the manufacturer.

Yes, where relevant.

Annex VII requires technical documentation to contain enough information to assess compliance, including the vulnerability-handling processes and the cybersecurity risk assessment. The draft guidance adds that manufacturers should indicate in the technical documentation whether the product has RDPS or relies on third-party cloud solutions and should describe those solutions.

Yes.

The Commission FAQ says that if a vulnerability in an integrated component cannot be adequately addressed by the original component supplier, the integrating manufacturer still has to remediate it by other means, for example by switching out the component, developing a patch itself, or disabling the affected functionality where that is the appropriate product-level remedy.

Yes.

The Commission FAQ says intended purpose, reasonably foreseeable use, and conditions of use can include direct or indirect logical or physical connections to devices or networks. That means the manufacturer has to take the integration context into account in the risk assessment and provide users with the information needed for secure deployment and operation.

No, not by itself.

The draft guidance says manufacturers integrating FOSS components do not become responsible for those components' individual CRA compliance merely because they contribute source code to their maintenance. The same logic applies where manufacturers provide financial support to keep a dependency viable. The integrating manufacturer still remains responsible for its own product and still has to exercise due diligence toward the integrated dependency.

No.

The draft guidance says the fact that other manufacturers integrate a FOSS component into monetised products does not by itself change the status of that component under the CRA. Whether the CRA applies to the dependency itself depends on whether the entity publishing it places it on the market. A FOSS component published for integration by other manufacturers can therefore remain outside the manufacturer regime, or fall under the steward regime, if the publisher does not monetise that component.

Yes.

Where a legal person publishes a FOSS dependency intended for commercial activities but does not place that specific dependency on the market, it may be an open-source software steward rather than a manufacturer. The draft guidance also says the same legal entity can be a manufacturer for one FOSS and a steward for another, including being a manufacturer for a paid version and a steward for a free or community version. That changes the publisher's own CRA role, but it does not remove the integrating manufacturer's obligations for the finished product.

No.

The draft guidance's package-repository example says that merely hosting a FOSS library in a public repository does not by itself give the repository CRA obligations for that dependency. More generally, hosting or infrastructure support does not automatically make a legal person responsible for every project it hosts. A legal person may become a steward only for specific FOSS where it systematically provides sustained support and ensures that project's viability.

No.

The CRA is a horizontal product-cybersecurity regime. It adds mandatory cybersecurity rules for products with digital elements, but it does not generally replace other Union acts that regulate the same product from another angle, such as product safety, machinery, data protection, health-data systems, or AI. Depending on the product, the CRA may apply alongside those other acts, unless the CRA itself excludes the product or a later delegated act limits the CRA for a specific product framework.

Yes.

That is a normal CRA scenario. The Commission FAQ gives machinery, radio equipment, EHR systems, and connected products that are also subject to the Data Act as examples of products that may have to comply with more than one Union framework at once.

The starting point is the CRA's express exclusions and any delegated acts adopted under Article 2(5).

Some products are excluded directly by Article 2, including products to which the medical-device and in vitro-diagnostic frameworks apply, products to which Regulation (EU) 2019/2144 applies, products certified under the civil-aviation framework, and marine equipment in scope of Directive 2014/90/EU. In addition, Delegated Regulation (EU) 2025/1535 excludes products falling within the scope of Regulation (EU) No 168/2013, except L1e category vehicles designed to pedal. More generally, Article 2(5) allows the Commission to limit or exclude the CRA for products covered by other Union rules that address the same risks, but only where that is consistent with the overall framework and delivers the same or a higher level of protection.

The CRA complements them; it does not duplicate them.

Recital 3 says existing Union cybersecurity law, including Regulation (EU) 2019/881 and Directive (EU) 2022/2555, does not directly cover mandatory security requirements for products with digital elements. Recital 24 adds that the CRA is intended to facilitate compliance by digital infrastructure providers with NIS2 supply-chain requirements by making the products they use more secure and better supported. The CRA also operates without prejudice to Union-level NIS2 supply-chain risk assessments.

Where a wallet product falls within the CRA's scope, both frameworks apply.

Recital 33 says providers of European Digital Identity Wallets should comply with both the CRA's horizontal essential cybersecurity requirements and the specific security requirements in Article 5a of Regulation (EU) No 910/2014. The same recital also says that, where the Commission has specified a presumption of conformity, a European cybersecurity certification scheme under Regulation (EU) 2019/881 may be used to help demonstrate compliance with both frameworks for the covered requirements.

They are complementary, but they do not serve the same function.

The Product Liability Directive deals with compensation for damage caused by defective products. The CRA sets ex ante cybersecurity obligations for products placed on the market. The Commission FAQ explains that CRA duties such as security-update obligations can become relevant when defectiveness and damage are assessed under the Product Liability Directive.

A product can fall under both.

The CRA covers essential cybersecurity requirements for products with digital elements. The Machinery Regulation covers essential health and safety requirements for machinery and related products, including some cybersecurity-related safety issues. Recital 53 and the Commission FAQ both say manufacturers of products in scope of both regimes need to comply with both sets of requirements.