Use this CRA FAQ to understand how Annex I Part I and Part II work, what applies to in-scope products with digital elements, and how manufacturers must justify, document, and evidence compliance.
Built for product security, engineering, legal, certification, and compliance teams interpreting the Cyber Resilience Act's core technical requirements.
Structured answer sets in this page tree.
Cited legal and guidance references.
The Cyber Resilience Act's Essential Cybersecurity Requirements are the core baseline for in-scope products with digital elements. Annex I Part I sets product-security outcomes such as secure-by-default configuration, updateability, access control, confidentiality, integrity, resilience, attack-surface reduction, logging, and secure data removal. Annex I Part II sets the manufacturer's vulnerability-handling processes, including SBOM-related documentation, testing, coordinated vulnerability disclosure, secure update distribution, and security-update communication.
The CRA splits the Essential Cybersecurity Requirements into two parts:
- Part I of Annex I covers the cybersecurity properties the product itself must have
- Part II of Annex I covers the vulnerability-handling processes the manufacturer must put in place
Article 6 ties market availability to Annex I conformity; Annex I separates product properties from vulnerability-handling requirements.
Use Research Copilot to map Cyber Resilience Act essential requirements to source citations, product decisions, owners, and evidence records.
Yes.
Under Article 6, products may only be made available on the market where the product meets the Part I requirements and the manufacturer's processes comply with the Part II requirements.
Article 6 and Article 13(1) require the product and the manufacturer's processes to meet Annex I before the product is placed on the market.
No.
Part I focuses on the product as placed on the market. Part II contains vulnerability-handling obligations that manufacturers must comply with when the product is placed on the market and throughout the support period.
Article 13 and Annex I support the distinction between product properties at market placement and vulnerability handling during the support period.
Section 4.1.3 explains that Part II vulnerability-handling requirements apply throughout the support period.
No.
The requirements are objective-oriented and technology-neutral. The CRA does not mandate one specific cybersecurity risk-assessment methodology. Manufacturers can choose their methodology, but it must support identifying, evaluating and treating the relevant risks and documenting how the essential requirements are met.
Article 13 requires a cybersecurity risk assessment but does not impose one named risk-assessment method.
Sections 4.1.2 and 4.2.1 confirm that no specific methodology or fixed list of technical measures is mandated.
Not in exactly the same way.
For Part II, manufacturers need to comply with the vulnerability-handling requirements throughout the support period. For Part I, Article 13(3) requires the manufacturer to determine through the cybersecurity risk assessment which point (2) requirements are applicable to the product and how they are implemented. If a specific Part I requirement is not applicable, Article 13(4) requires a clear justification in the technical documentation.
Article 13(3)-(4) requires manufacturers to identify applicable Part I requirements and justify non-applicability in the technical documentation.
Section 4.1.3 distinguishes mandatory vulnerability-handling requirements from risk-assessment-based product-property requirements.
It is the general product-level requirement to ensure an appropriate level of cybersecurity based on the risks.
The Commission's March 2026 draft guidance explains that this point is meant to catch additional cybersecurity risks identified by the risk assessment that are not otherwise adequately addressed by the other specific Part I requirements. In most cases, complying with the other applicable Part I requirements will also satisfy point (1), but if additional relevant risks remain, the manufacturer still has to address them at product level.
Annex I Part I point (1) is the general product-level cybersecurity outcome, applied through the Article 13 risk assessment.
Draft points 148-150 explain how Part I point (1) addresses residual product-security risks not covered by more specific points.
No.
The CRA does not require a product to be free from all vulnerabilities. For placement on the market, the relevant product requirement is that, on the basis of the cybersecurity risk assessment and where applicable, the product is made available without known exploitable vulnerabilities. After placement on the market, the manufacturer must address and remediate relevant vulnerabilities without delay in line with Part II of Annex I.
Annex I Part I point (2)(a) addresses known exploitable vulnerabilities at market placement; Part II point (2) addresses later vulnerability remediation.
Sections 4.2.2 and 4.3.1 clarify that the CRA does not require absolute vulnerability-free products or patches for every discovered vulnerability.
No.
The Commission's March 2026 draft guidance says residual cybersecurity risk is assessed against the CRA's regulatory threshold, not against the manufacturer's internal risk tolerance, commercial strategy or cost preferences. If identified risks are not adequately addressed, the product cannot simply be placed on the market anyway.
Article 13 and Annex I Part I point (1) make risk-based cybersecurity a regulatory product requirement, not only an internal risk-acceptance exercise.
Draft points 141-147 discuss residual-risk limits, cost constraints, and the need to change design, functionality, or intended purpose where risks cannot be adequately addressed.
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 they do not replace product design and vulnerability-handling duties. The Commission's March 2026 draft guidance says instructions cannot be used to compensate for product-design shortcomings or to justify leaving incompatible risks untreated.
Article 13(18) and Annex II require user information and instructions, including support, update, decommissioning, and integration information.
Draft points 145-147 address the limits of relying on users, warnings, or third parties to absorb unresolved product-security risks.
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 lists product-security outcomes including secure defaults, updates, access control, data protection, resilience, attack-surface reduction, logging, and secure removal.
Sections 4.1.3 and 4.2.1 explain that the applicable technical measures depend on the product and its cybersecurity risk assessment.
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, and Annex I require assessment and implementation at product-with-digital-elements level, including in-scope remote data processing.
Section 4.1.1 says the cybersecurity risk assessment needs to cover the entire product with digital elements, including in-scope remote data processing.
Draft points 151-157 and 162 discuss how dependencies, external services, and the wider product environment can affect product-level compliance.
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) and recital 55 support justified non-applicability where a requirement is incompatible with the product's nature, including interoperability cases.
Section 4.1.3 explains when a requirement may be treated as not applicable and how that must be justified.
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 supports presumption of conformity through harmonised standards; Article 31 and Annex VII require documentation of the solutions used.
Sections 4.1.7 and 4.2.1 confirm harmonised standards are voluntary and other documented technical means may be used.
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) and Annex II list user information needed to support secure installation, operation, updates, decommissioning, and integration.
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, Article 31, and Annex VII require technical documentation covering risk assessment, vulnerability-handling processes, standards or other solutions, and test reports.
Sections 4.1.1 and 4.2.1 explain the role of the risk assessment and technical documentation in demonstrating implemented requirements.
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 applies Annex I to in-scope products generally; Articles 7 and 8 address important and critical classifications for additional treatment.
Section 4.2.1 explains that technical measures are determined for each product, not only for important or critical categories.
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 explains that Annex I requirements apply to each individual product placed on the market, including products manufactured in series.
No.
The Commission's 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.
Draft points 145-146 discuss why instructions and third-party action do not transfer the manufacturer's product-compliance responsibility.
Article 13(18) and Annex II require information and instructions, but those duties sit alongside Annex I conformity obligations.
No.
The Commission's March 2026 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.
Draft point 147 explains that unresolved risks may require changes to design, functionality, or intended purpose rather than warnings alone.
Article 13 and Annex I Part I point (1) require product cybersecurity based on the assessed risks.
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 Commission's March 2026 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) and recital 55 support documented non-applicability where an essential requirement conflicts with interoperability, while still requiring risk treatment.
Draft point 29 and Example 6 address secure defaults and documented mitigation where interoperability requires a less secure option.
"incompatible with the nature of the product"
"less secure protocol"
"apply horizontally to all products with digital elements"