Search every question across sub-FAQs

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 system architecture, vulnerability-handling processes, the SBOM, test reports, the support-period basis, 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.

Maintain one dependency record that distinguishes items inside the product boundary from outside dependencies. For each item, record the exact version or service, function, owner or maintainer, whether it is an integrated component or remote data processing solution, why it is necessary, its privilege and exposure, support status, known-vulnerability monitoring, and the evidence used for due diligence.

Connect that record to the cybersecurity risk assessment, SBOM where applicable, support-period rationale, tests, mitigations, user information, and the response plan if the supplier stops support or no upstream fix is available. Contracts and service levels can supply evidence and remedies, but they do not transfer the finished-product manufacturer's CRA responsibility.

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.