EU Cyber Resilience Act Frequently Asked Questions
Sytance · Updated
These answers explain recurring CRA questions about software, support periods and reporting. They draw on the regulation, the Commission FAQ and the Commission guidance published on 27 July 2026, with links to the detailed topic pages.
Source status
The regulation establishes the legal requirements. The Commission FAQ and guidance explain their application; those explanatory documents are not legally binding.
The replies to the FAQs do not extend in any way the rights and obligations deriving from applicable legislation nor introduce any additional requirement.
European Commission CRA implementation FAQ, introductory note
The Commission published guidance C(2026) 5252 on 27 July 2026 following the earlier consultation. It addresses scope, open-source software, substantial modifications and support periods, as well as risk assessment, remote processing and reporting.
Scope and market supply
Yes, if the CRA scope conditions are met. A product with digital elements can be software, hardware, a remote data processing solution that forms part of the product, or a software or hardware component placed on the market separately.
Software supplied as a product can be in scope when it meets the CRA definition and market conditions. This includes standalone applications and firmware. Apply the same scope conditions to development tools and software components rather than deciding from their names.
Read more in Products in Scope.
Standalone SaaS or a cloud service developed outside the manufacturer's responsibility is not automatically a product with digital elements. A cloud function matters under the CRA when it meets the definition of remote data processing.
Remote data processing belongs to the product when it takes place at a distance, the product needs it to perform one of its functions, and the processing software was designed or developed by the manufacturer or under its responsibility.
Read more in Products in Scope.
No. The CRA uses data connection concepts, not a simple internet-access rule. A connection can be logical, physical, direct, or indirect.
Relevant examples include:
- logical connections through APIs, network sockets, pipes, files, browser HTTPS sessions, or email protocols;
- physical connections through USB, Ethernet, fibre, fieldbus, Wi-Fi, Bluetooth, NFC, or other radio links;
- indirect connections through a host system that is itself connectable to a device or network.
Read more in Products in Scope.
Usually not. The Blue Guide explains that placing on the market does not take place when a product is manufactured for one's own use. The Commission FAQ applies that point to CRA examples such as development and configuration tools made by a manufacturer for its own use.
The answer changes if the tool is later placed on the market as a separate product. Then it must be assessed like any other software or hardware product with digital elements.
Read more in Placing on the Market.
Products placed on the market before 11 December 2027 are not subject to the full CRA requirements merely because that date arrives. They become subject to those requirements if they undergo a substantial modification from that date.
Article 14 reporting is different. The reporting obligations apply from 11 September 2026 to products with digital elements that fall within the CRA scope, including products placed on the market before 11 December 2027.
Read more in Placing on the Market and Vulnerability Reporting.
The Commission FAQ distinguishes units already placed on the market from units newly placed on the market. Units that were already placed on the market can continue to be made available after the declared support period expires.
Newly placed units are different. If the manufacturer places additional units on the market, the manufacturer must set a support period for those units under Article 13(8).
Read more in Support Period.
Software and open source
No. Free supply does not by itself decide the answer. The CRA separates non-commercial free and open-source development from software placed on the market in a commercial activity.
The July 2026 guidance distinguishes paid access to software or its maintenance from optional services around freely available software. Paid editions can be commercial supply; optional consultancy alone does not make the free version commercial. Monetising services through the software, or requiring personal-data processing beyond improving software security, compatibility or interoperability as a condition of use, can also make the supply commercial.
Read more in Roles and Duties and Products in Scope.
Yes, but only under the testing rule in Article 4(3). The software must be made available only for the limited period needed for testing and must visibly show that it does not comply with the CRA and will not be available for purposes other than testing.
The Commission FAQ also points to Recital 37: the manufacturer should release such software only after a risk assessment and should meet the security and vulnerability handling requirements to the extent possible.
Yes. Article 13(11) allows public software archives that improve user access to historical versions. Users must be clearly informed, in an easily accessible way, about the risks of unsupported software.
An archive is not the same as active support. The question is whether the user can understand that the archived version is no longer supported and carries security risk.
Security, support, and reporting
No. The Commission FAQ states that the CRA does not require manufacturers to ensure that a product is free from all vulnerabilities.
At the moment of placing on the market, the relevant Annex I requirement concerns known exploitable vulnerabilities, based on the manufacturer's cybersecurity risk assessment and the facts available at that point.
Read more in Essential Cybersecurity Requirements and Cybersecurity Risk Assessment.
No. A manufacturer must assess whether the vulnerability is relevant to the product and what risk it creates. The remedy must fit that risk.
A remedy can be a patch, but it can also be another measure, such as an advisory, configuration guidance, a workaround, updated user information, or a later software update. The CRA requires vulnerabilities to be addressed and remediated without delay in relation to the risks posed to products with digital elements.
Read more in Vulnerability Handling Records.
No. Five years is a minimum safeguard, not a default for every product. A longer support period may be needed when the product is reasonably expected to be used for longer.
A shorter support period is allowed only when the product is expected to be used for less than five years. In that case, the support period corresponds to the expected use time.
Read more in Support Period.
A manufacturer reports an actively exploited vulnerability contained in its product. If the vulnerability comes from an integrated component and can be exploited in the product, the product manufacturer reports it. The component manufacturer also reports it if the component was placed on the market as its own product.
If the component vulnerability cannot be exploited in the manufacturer's product, mandatory Article 14 reporting is not triggered on that basis. The manufacturer may still have upstream coordination or vulnerability handling duties.
Read more in Vulnerability Reporting.
Conformity and evidence
No. The Commission FAQ explains that a manufacturer may integrate components that do not bear CE marking, including components not placed on the market and components placed on the market before the CRA applies.
The manufacturer still has to exercise due diligence so that the component does not compromise the cybersecurity of the final product.
Read more in SBOM and Component Records.
Generally no. The Commission FAQ says there is no general duty to make technical documentation available to customers or to the public.
The important exception is free and open-source software in Annex III Class I or Class II when the manufacturer wants to use Article 32(5) self-assessment. In that case, the technical documentation must be made publicly available.
Read more in Technical Documentation and Conformity Assessment.
No. Draft standards can be useful preparation material, but they do not create presumption of conformity under Article 27. Presumption of conformity depends on a harmonised standard whose reference has been published in the Official Journal of the European Union.
The same distinction applies to the prEN 40000 drafts and product-specific draft standards. Manufacturers can use them to prepare evidence while checking their publication and citation status separately.
Read more in Harmonised Standards and Presumption of Conformity.