Frequently Asked Questions
The Commission FAQ and draft guidance answer many practical questions that sit across scope, market supply, software, support, reporting, and conformity assessment. The short answers below keep the most common boundaries in one place and link to the full topic pages when the answer needs more detail.
Source status
The regulation is the binding source. The Commission FAQ and draft guidance are useful because they address recurring implementation questions, but they do not replace the legal text.
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 draft guidance published in March 2026 focuses on the scope of the CRA, free and open-source software, support periods, substantial modification, remote data processing, reporting, vulnerability handling, and interplay with other EU laws. It is helpful source material, but it remains guidance material rather than the regulation itself.
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.
Standalone software, mobile apps, firmware, drivers, operating systems, SDKs, and downloadable tools can therefore be in scope. The key point is not whether the item is called software. The key point is whether it meets the CRA definition and is made available on the Union market.
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.
The central question is whether the remote processing is at a distance, whether the product could not perform one of its functions without it, and whether the software for that processing was designed or developed by the manufacturer or under the manufacturer's 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 draft guidance gives examples in which monetised supply can make free and open-source software commercial, such as paid editions, paid access to related services, or use that depends on processing personal data for purposes outside security, compatibility, or interoperability.
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.
This distinction matters for prEN 40000 drafts and product-specific draft standards. They can help a manufacturer prepare evidence, but the page should not call them harmonised standards until the legal status changes.
Read more in Harmonised Standards and Presumption of Conformity.