Search every question across sub-FAQs

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 adds horizontal cybersecurity requirements for products with digital elements; it does not generally replace product safety, radio equipment, machinery, vehicle, aviation, marine, or other Union product rules.

The practical question is whether the other law merely overlaps with the CRA, or whether the CRA itself excludes the product. If the CRA is not excluded, the manufacturer should expect to demonstrate compliance with each applicable framework, even where the same engineering evidence supports more than one requirement.

Start with Article 2, not with a broad assumption that sector rules displace the CRA. Article 2 excludes some products directly, including products covered by the medical-device and in vitro-diagnostic frameworks, products covered by Regulation (EU) 2019/2144, certified aviation products under Regulation (EU) 2018/1139, and marine equipment within Directive 2014/90/EU.

Then check delegated acts under Article 2(5). The Commission FAQ identifies Delegated Regulation (EU) 2025/1535 as excluding products within Regulation (EU) No 168/2013 on two- or three-wheel vehicles and quadricycles, except L1e category vehicles designed to pedal. Outside those exclusions and delegated acts, the existence of another EU product law with cybersecurity provisions is not enough by itself to switch off the CRA.

For radio equipment categories covered by Delegated Regulation (EU) 2022/30, the Commission FAQ describes a transition by placement date. RED cybersecurity requirements apply to covered radio equipment placed on the market from 1 August 2025 through 10 December 2027.

For the same categories placed on the market on or after 11 December 2027, the CRA applies for the relevant cybersecurity requirements. The FAQ also says repeal of the RED delegated act from that date would not undo RED market-surveillance control for covered radio equipment placed on the EU market during the RED period.

Yes, but only for the cybersecurity risks that the RED certificate or approval decision actually covers, and only within the Article 69(1) validity rule.

Article 69(1) keeps EU type-examination certificates and approval decisions issued for cybersecurity requirements under other Union harmonisation legislation valid until 11 June 2028, unless they expire earlier or that other legislation provides otherwise. The draft CRA guidance explains that this does not equal full CRA compliance. It allows the manufacturer to rely on the certificate as evidence for already covered risks, while still performing the CRA cybersecurity risk assessment and addressing additional CRA risks such as vulnerability handling or attack-surface reduction where they are not covered by the RED certificate.

A connected machine can be subject to both regimes. The Machinery Regulation addresses essential health and safety requirements for machinery and related products, including cybersecurity-related safety requirements. The CRA addresses cybersecurity requirements for products with digital elements.

The Commission FAQ says a manufacturer of a product covered by both the CRA and the Machinery Regulation must comply with both. Compliance with one framework is not automatically compliance with the other, although the same technical measures, standards work, or risk analysis may support both where the manufacturer can show that the relevant requirements are actually covered.

Not completely. Draft CRA guidance applies the Article 69(1) rule to certificates or approval decisions issued for cybersecurity-related Machinery Regulation requirements. Those certificates can remain useful evidence for the covered cyber-safety risks during the Article 69(1) period.

The manufacturer still needs the CRA cybersecurity risk assessment. If that assessment identifies additional CRA risks not covered by the machinery certificate, those gaps must be assessed and mitigated under the CRA. The draft guidance gives Machinery Regulation examples tied to protection against corruption and the safety and reliability of control systems, but it treats them as covered-risk examples, not as a blanket CRA exemption.

The CRA and GPSR cover different risk categories. The CRA addresses cybersecurity risks for products with digital elements. The GPSR remains relevant for consumer-product safety aspects and risks that the CRA does not cover, unless those aspects are already governed by more specific Union harmonisation legislation.

For a connected consumer product, this means the CRA can govern cybersecurity while the GPSR can still matter for safety issues outside the CRA's cybersecurity scope. The correct analysis is by risk and product framework, not by choosing one law as the only applicable regime.

The Commission FAQ frames the CRA and Data Act as different in nature. The CRA concerns placing products with digital elements on the market and meeting cybersecurity requirements. The Data Act concerns making product data and related service data available to users or third parties.

Where both apply, Data Act access obligations can be relevant to the CRA cybersecurity risk assessment. The FAQ says manufacturers should take those obligations into account when assessing intended purpose, reasonably foreseeable use, product environment, and risks connected to making data available. That is a risk-assessment input, not a general statement that Data Act compliance equals CRA compliance or that every legacy product must be redesigned solely because of the Data Act.

Yes, where more than one Union act requiring an EU declaration of conformity applies to the same product. Article 28(3) requires a single EU declaration of conformity in that situation, containing all information needed to identify the Union acts concerned.

This does not reduce the substance of the obligations. A single declaration is an administrative coordination mechanism; the manufacturer still needs evidence that each listed Union act's applicable requirements are met.

Often yes, if it is structured to prove each law's requirements. Article 31(3) requires a single technical-documentation set for products covered by Article 12 where other Union acts also require technical documentation. Article 13(4) also allows the CRA cybersecurity risk assessment to be part of a risk assessment required by other applicable Union law.

The Commission FAQ adds the important limit: manufacturers may use a single risk assessment covering different legislations or separate assessments, but they must be able to demonstrate compliance with each individual legislation. A combined file is therefore useful only if it maps each requirement, risk, standard, test result, certificate, and residual gap to the specific law it is meant to support.

No. The component analysis depends on whether the component itself falls within the exclusion or is designed and marketed more broadly.

The Commission FAQ says components intended for certified aviation products may still be covered where the component itself is not certified under Regulation (EU) 2018/1139. It gives similar logic for components intended for marine equipment where the component itself is not within Directive 2014/90/EU. Draft CRA guidance adds that components designed and constructed exclusively for integration into excluded vehicle frameworks can be outside the CRA, while generic components or components sold through channels beyond that supply chain can remain in scope.

Keep an overlap matrix that starts with the product, intended purpose, reasonably foreseeable use, market channel, and each potentially applicable Union act. Record whether the product is excluded under CRA Article 2 or a delegated act, or whether the CRA applies alongside the other law.

For overlap cases, keep a requirement-to-evidence map showing the CRA Annex I requirement, the other law's corresponding requirement, the risk assessment section, standard or technical specification used, test result, certificate or approval decision, declaration entry, and any uncovered CRA risk. For Article 69 reliance, identify the issuing framework, certificate or approval decision, covered cybersecurity risks, expiry or Article 69 end date, and the CRA gaps that still require mitigation.

No. The CRA launch requirement is narrower than that.

Annex I Part I point (2)(a) says that, on the basis of the cybersecurity risk assessment and where applicable, products with digital elements must be made available on the market without known exploitable vulnerabilities. The Commission FAQ confirms that the CRA does not require manufacturers to ensure that a product is free from all vulnerabilities.

The CRA defines a vulnerability as a weakness, susceptibility, or flaw of a product with digital elements that can be exploited by a cyber threat. It defines an exploitable vulnerability as one that has the potential to be effectively used by an adversary under practical operational conditions.

The practical question is therefore not only whether a weakness exists, but whether it can be used against this product in its intended and reasonably foreseeable operating conditions.

The CRA text does not separately define when an exploitable vulnerability becomes known. The Commission's March 2026 draft guidance gives the most specific public interpretation in the grounding material.

Under that draft guidance, an exploitable vulnerability should be regarded as known when it is listed in relevant public vulnerability databases, including the European vulnerability database under NIS2 or prominent databases such as the CVE List. It may also be known through coordinated disclosure, internal testing and analysis, or prominent reporting in reliable cybersecurity or general media.