Compliance matrix

Company foundations

• F1 Prepare to submit notifications through ENISA's single reporting platform, which reaches the CSIRT designated as coordinator and ENISA at once.

  Also applies to products already on the market

  Sources: CRA Art. 14(7); CRA Art. 16

• F2 Put in place and enforce a coordinated vulnerability disclosure policy.

  Sources: CRA Annex I, Part II, point (5)

  Draft EN 40000: EN 40000-1-3, clause 5.3.3 (Policy on coordinated vulnerability disclosure)

• F3 Provide a contact address for reporting vulnerabilities, and make it easy to share information about potential vulnerabilities.

  Sources: CRA Annex I, Part II, point (6)

  Draft EN 40000: EN 40000-1-3, clause 5.4.2 (Capability to receive reports)

• F4 Optional: appoint an authorised representative in the EU by written mandate. You keep core duties such as design and vulnerability handling.

  Sources: CRA Art. 18(1) and (2)

Before development

Nothing in this stage applies to a product already on the market, unless it is substantially modified from 11 December 2027.

• B1 Find your product's class from its core functionality: Default, Important I, Important II or Critical.

  Sources: CRA Annex III; CRA Annex IV; Implementing Regulation (EU) 2025/2392

  Tool: Product class finder

• B2 Assess the product's cybersecurity risks, and record which Annex I Part I requirements apply and why any others do not.

  Sources: CRA Annex I, Part I, point (2); CRA Art. 13(4); CRA Annex VII, point 3

  Draft EN 40000: EN 40000-1-2, clause 6.4 (Risk assessment)

• B3 Decide the support period from the expected use time: at least five years, or the expected use time if shorter.

  Sources: CRA Art. 13(8)

  Tool: Support period planner

Development

Nothing in this stage applies to a product already on the market, unless it is substantially modified from 11 December 2027.

• D1 Design, develop and produce the product so that its level of cybersecurity is appropriate to the risks.

  Sources: CRA Annex I, Part I, point (1)

  Draft EN 40000: EN 40000-1-2, clause 7.4 (Cybersecurity architecture and design); EN 40000-1-2, clause 7.5 (Secure implementation); EN 40000-1-2, clause 7.7 (Secure production and distribution)

• D2 Where applicable, make sure the product has no known exploitable vulnerabilities when it is made available on the market.

  Sources: CRA Annex I, Part I, point (2)(a)

  Draft EN 40000: EN 40000-1-2, clause 7.6 (Cybersecurity verification and validation)

• D3 Where applicable, ship it secure by default, with a reset to its original state, unless you and a business user agree otherwise for a tailor-made product.

  Sources: CRA Annex I, Part I, point (2)(b)

  Draft EN 40000: EN 40000-1-2, clause 5.4 (Secure by default)

• D4 Where applicable, let vulnerabilities be fixed through security updates, including automatic updates on by default with an easy opt-out, update notices and temporary postponement.

  Sources: CRA Annex I, Part I, point (2)(c)

• D5 Where applicable, protect against unauthorised access with suitable controls, such as authentication or access management, and report possible unauthorised access.

  Sources: CRA Annex I, Part I, point (2)(d)

• D6 Where applicable, protect the confidentiality of stored, transmitted and processed data, for example by encrypting it at rest and in transit with state-of-the-art methods.

  Sources: CRA Annex I, Part I, point (2)(e)

• D7 Where applicable, protect data, commands, programs and configuration against changes the user has not authorised, and report corruptions.

  Sources: CRA Annex I, Part I, point (2)(f)

• D8 Where applicable, process only data that is adequate, relevant and limited to what the product's intended purpose needs.

  Sources: CRA Annex I, Part I, point (2)(g)

• D9 Where applicable, protect the availability of essential and basic functions, also after an incident, including against denial-of-service attacks.

  Sources: CRA Annex I, Part I, point (2)(h)

• D10 Where applicable, limit the harm the product or connected devices can do to the availability of services from other devices or networks.

  Sources: CRA Annex I, Part I, point (2)(i)

• D11 Where applicable, design, develop and produce the product to limit attack surfaces, including external interfaces.

  Sources: CRA Annex I, Part I, point (2)(j)

• D12 Where applicable, reduce the impact of an incident with suitable exploitation mitigation mechanisms and techniques.

  Sources: CRA Annex I, Part I, point (2)(k)

• D13 Where applicable, record and monitor relevant internal activity, such as access to or changes of data, services or functions, with an opt-out for users.

  Sources: CRA Annex I, Part I, point (2)(l)

• D14 Where applicable, let users remove all data and settings securely, easily and permanently, and transfer data securely where it can be transferred.

  Sources: CRA Annex I, Part I, point (2)(m)

  Draft EN 40000: EN 40000-1-2, clause 7.10 (Planning for secure decommissioning)

• D15 Exercise due diligence when integrating components, including open-source components that were not supplied in the course of a commercial activity.

  Sources: CRA Art. 13(5)

  Draft EN 40000: EN 40000-1-2, clause 7.11 (Third-party component cybersecurity management)

• D16 Provide mechanisms to distribute updates securely and, where applicable for security updates, automatically.

  Sources: CRA Annex I, Part II, point (7)

  Draft EN 40000: EN 40000-1-3, clause 5.3.11 (Mechanisms for distribution); EN 40000-1-2, clause 7.7 (Secure production and distribution)

Before release

Nothing in this stage applies to a product already on the market, unless it is substantially modified from 11 December 2027.

• R1 Identify the product's components and vulnerabilities and document them, with an SBOM in a machine-readable, commonly used format covering at least top-level dependencies.

  Sources: CRA Annex I, Part II, point (1); CRA Annex VII, point 2(b)

  Draft EN 40000: EN 40000-1-3, clause 5.3.8 (Identification of software components)

• R2 Draw up the technical documentation (Annex VII) before placing on the market, and update it where appropriate, at least during the support period.

  Sources: CRA Art. 31(1) and (2); CRA Annex VII

• R3 Conformity assessment: you can self-assess under module A, or use module B with C, module H, or a certification scheme where available and applicable.

  For Default products only

  Sources: CRA Art. 32(1)

• R4 Conformity assessment: self-assess (module A) only if you fully apply harmonised standards, common specifications or a certification scheme at level "substantial" or above; otherwise use module B with C, or H.

  For Important I products only

  Sources: CRA Art. 32(1) and (2)

• R5 Conformity assessment: use module B with C, module H, or a European cybersecurity certification scheme at level "substantial" or higher, where one is available and applicable.

  For Important II products only

  Sources: CRA Art. 32(3)

• R6 Conformity assessment: where the conditions in Article 8(1) are met, use a European cybersecurity certification scheme; otherwise use one of the procedures for Important II products.

  For Critical products only

  Sources: CRA Art. 32(4)

• R7 After conformity is shown, complete the EU declaration of conformity (Annex V) and supply a copy or a simplified declaration with the product.

  Sources: CRA Art. 28; CRA Annex V; CRA Art. 13(20); CRA Annex VI

  Tool: Declaration of conformity drafter

• R8 Affix the CE marking before placing the product on the market, once conformity is shown. Under module H, the notified body's number follows it.

  Sources: CRA Art. 13(12); CRA Art. 30

• R9 Supply the Annex II user information and instructions with the product, clearly and in a language users and authorities easily understand.

  Sources: CRA Annex II; CRA Art. 13(18)

• R10 State the end date of the support period, at least the month and year, clearly at the time of purchase.

  Sources: CRA Art. 13(19); CRA Annex II, point 7

  Tool: Support period planner

After release

• A1 Notify actively exploited vulnerabilities: early warning and notification without undue delay, within 24 and 72 hours of becoming aware; final report within 14 days of a fix or mitigation.

  Also applies to products already on the market

  Sources: CRA Art. 14(1) and (2)

• A2 Notify severe incidents affecting the product's security: early warning and notification without undue delay, within 24 and 72 hours of becoming aware; final report within one month of the notification.

  Also applies to products already on the market

  Sources: CRA Art. 14(3) and (4)

• A3 Inform the impacted users, and where appropriate all users, of an actively exploited vulnerability or severe incident and, where necessary, of mitigation and corrective measures they can take.

  Also applies to products already on the market

  Sources: CRA Art. 14(8)

• A4 Address and remediate vulnerabilities without delay, including through security updates; where technically feasible, release them separately from functionality updates.

  Sources: CRA Annex I, Part II, point (2)

  Draft EN 40000: EN 40000-1-3, clause 5.6 (Remediation)

• A5 Test and review the product's security effectively and regularly.

  Sources: CRA Annex I, Part II, point (3)

  Draft EN 40000: EN 40000-1-3, clause 5.3.10 (Planning regular test and reviews); EN 40000-1-3, clause 5.4.7 (Performing regular tests); EN 40000-1-3, clause 5.4.8 (Performing regular reviews)

• A6 Once a security update is available, share and publicly disclose information about the vulnerabilities it fixed.

  Sources: CRA Annex I, Part II, point (4)

  Draft EN 40000: EN 40000-1-3, clause 5.7.3 (Release information)

• A7 Disseminate security updates without delay with advisory messages, free of charge unless you and a business user agree otherwise for a tailor-made product.

  Sources: CRA Annex I, Part II, point (8)

  Draft EN 40000: EN 40000-1-3, clause 5.7.2 (Security update release)

• A8 Keep each security update available for at least 10 years after issue, or the rest of the support period, whichever is longer.

  Sources: CRA Art. 13(9)

  Tool: Support period planner

• A9 Report vulnerabilities you find in a component, including an open-source one, to whoever maintains it, and share your fixes.

  Sources: CRA Art. 13(6)

• A10 Keep the technical documentation, EU declaration of conformity and user information available for at least 10 years after placing on the market, or the support period, whichever is longer.

  Sources: CRA Art. 13(13); CRA Art. 13(18)

  Tool: Support period planner

• A11 Where technically feasible, show users a notice when the product has reached the end of its support period.

  Sources: CRA Art. 13(19)

• A12 Check whether each change after placing on the market is a substantial modification; if so, recheck compliance and, where applicable, reassess conformity.

  Sources: CRA Art. 3(30); CRA recital 41

• A13 If you cease operations, inform market surveillance authorities and, as far as possible, users before that takes effect.

  Sources: CRA Art. 13(23)