Find the exact question, open the source answer card, and copy a direct link to the anchored sub-FAQ response.
No.
The CRA requires manufacturers to place a compliant product on the market. Information and instructions can support secure installation, operation, integration and deployment, but the draft guidance says they cannot be used to compensate for product-design shortcomings or to justify leaving incompatible risks untreated.
Article 13(18), Annex II
points 145-147
Part I, point (2) is a structured set of product-security outcomes that the manufacturer must apply where relevant on the basis of the cybersecurity risk assessment.
It covers, among other things:
- no known exploitable vulnerabilities at placement on the market
- secure-by-default configuration
- the ability to address vulnerabilities through security updates
- protection from unauthorised access
- confidentiality and integrity protection
- data minimisation
- protection of essential and basic functions, including after incidents
- attack-surface reduction
- exploitation-mitigation techniques
- security-related logging and monitoring
- secure removal and transfer of data and settings
Annex I Part I
section 4.1.3, section 4.2.1
They apply to the whole product.
The Commission FAQ says the cybersecurity risk assessment must cover the entire product with digital elements, including remote data processing when it is in scope and supporting functions that form part of the product. The draft guidance likewise explains that risks from external services, networks and other dependencies may need to be addressed through product-level measures so that the product as a whole complies.
Article 3(1), Article 13(2)-(5), Annex I
section 4.1.1
points 151-157, 162
The CRA recognises that this can happen, but it is not a free pass.
If a requirement is not applicable because of the nature of the product, the manufacturer must clearly justify that in the technical documentation. Recital 55 and the Commission FAQ give interoperability as an example. If cybersecurity risks still arise in relation to that inapplicable requirement, the manufacturer must address those risks by other appropriate means.
Article 13(4), recital 55
section 4.1.3
No.
Harmonised standards are voluntary and do not replace the manufacturer's own duty to assess risks and demonstrate compliance. They can support conformity, but manufacturers may also use other technical means if they document how the applicable essential requirements are met.
Article 27, Article 31, Annex I
section 4.1.7, section 4.2.1
Annex I sets the substantive cybersecurity outcomes and processes that the product and manufacturer must meet. Annex II requires the manufacturer to give users the information they need to install, operate, update, integrate and decommission the product securely.
That includes, among other things, the intended purpose, security properties, significant cybersecurity-risk circumstances, support-period information, update information, secure decommissioning information, and information needed by downstream integrators.
Article 13(18)-(19), Annex I, Annex II
The CRA does not prescribe one evidence format, but it does require the manufacturer to document how the applicable essential requirements are met.
That means the manufacturer needs to show in the cybersecurity risk assessment and technical documentation:
- which Part I requirements are applicable
- how they are implemented
- how Part I point (1) and Part II are applied
- what technical means, standards, specifications or other solutions are used
- what testing, review or other evidence supports those conclusions
Article 13(3)-(4), Article 31, Annex VII
section 4.1.1, section 4.2.1
No.
The essential cybersecurity requirements in Annex I apply horizontally to all products with digital elements that are in scope. The important or critical classification affects the conformity-assessment route, not whether the Annex I requirements apply in the first place.
Article 6, Article 7, Article 8
section 4.2.1
Yes.
Recital 38 makes clear that the essential cybersecurity requirements, including the vulnerability-handling requirements, apply to each individual product with digital elements when it is placed on the market, whether the product is manufactured as an individual unit or in series. The recital gives a practical example: each individual product placed on the market should already have received all security patches or updates available to address relevant security issues at that time.
recital 38, Article 13(1)
No.
The March 2026 draft guidance says the CRA does not allow the manufacturer to transfer cybersecurity risk or responsibility to users or third parties. Information and instructions can support secure deployment, operation or integration, and can inform users about residual risks, but the obligation to place a secure product on the market and demonstrate conformity with the essential cybersecurity requirements remains with the manufacturer.
points 145-146
Article 13(18), Annex II
No.
The draft guidance says that where identified risks cannot be adequately addressed through appropriate measures, compliance may require changes to the product's design, functionality or intended purpose. Cost or commercial feasibility alone is not a sufficient reason to leave such risks untreated, and warnings cannot justify placing a product on the market where the remaining risks are incompatible with the essential cybersecurity requirements.
point 147
Article 13(2)-(4), Annex I Part I, point (1)
The CRA allows justified constraints, but not an automatic downgrade.
Where a product must interoperate with existing systems that only support an older or less secure approach, the manufacturer may rely on that approach only if it is necessary for interoperability, the associated risks are identified and documented, and other appropriate mitigation measures are implemented. The draft guidance adds that if it is technically feasible to support both the secure and the less secure option, the secure option is expected to be implemented and enabled by default, while the less secure option should be used only where interoperability requires it.
Article 13(4), recital 55
point 29 and Example 6
Yes.
The CRA definition is broad enough to cover hardware and software supplied together as one product, including cases where the hardware and software are supplied separately but are intended to operate together as a single product.
Article 3(1)
points 17-19
The draft guidance says the key question is whether the software is necessary for the product to perform its intended functions in light of the product's intended purpose and reasonably foreseeable use.
The delivery channel is not decisive on its own. What matters is whether the hardware is designed to operate together with that software as part of one product concept.
No.
Software can still be part of the same product even if it is obtained through a separate channel such as an app store, a manufacturer website or another digital link after the hardware is supplied.
Yes.
The Commission FAQ expressly lists software placed on the market together with hardware even where it is not preloaded, such as printer drivers, laptop operating systems and tools used to design and program FPGAs.
section 1.2
They can be.
The Commission FAQ gives printer drivers as an example of software that may be placed on the market together with hardware. The draft guidance then makes the point more explicit: where the printer cannot fulfil its intended purpose without the drivers, the printer and the drivers together constitute a single product with digital elements.
Yes, if it is necessary for the product's intended functionality.
The draft guidance gives the example of a fitness wearable and a companion smartphone app that together form one product because they are designed and intended to operate together to deliver the product's functionality.
Not automatically.
The draft guidance points to necessity as the decisive factor. If the device can still perform its intended functions without the app, that points away from treating the app as part of the same combined product, although the exact answer still depends on intended purpose and reasonably foreseeable use.
It is more likely to be treated as standalone software when it is supplied as software in its own right and is not necessary for a hardware product to perform its intended functions.
The Commission FAQ confirms that standalone downloadable software can itself be a product with digital elements. The draft guidance then distinguishes that case from software that forms part of a hardware-software product.