CRA engineering checklist: from scope to retention

Part of our Cyber Resilience Act guide. Reviewed on 17 October 2026.

How to use this checklist

This checklist turns the EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, into work for an engineering team, in eight areas: scope, secure design, SBOM, vulnerability handling, technical documentation, conformity assessment, support period and retention. Each item carries the relevant Article or Annex. For what the regulation is, who it covers and the full timeline, read the Cyber Resilience Act guide first.

To keep a copy, print this page or save it as a PDF from your browser's print dialog; the site menus and links are left out of the printout.

Use the list as a working aid. It is not legal advice; confirm classification and conformity route against the official text.

What already applies. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents under Article 14, and that includes products already on the market (Article 69(3)). If you have not set up the reporting process in section 4 yet, start there. Everything else applies from 11 December 2027.

1. Scope and classification

1. Confirm the product is in scope. The CRA covers products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network (Article 2(1)).
2. Check the exclusions. The CRA excludes products under the MDR (EU) 2017/745, the IVDR (EU) 2017/746 or vehicle type-approval Regulation (EU) 2019/2144, and certain aviation and marine products (Article 2(2) to 2(4)). Annex III lists a health-monitoring wearable that the MDR and IVDR do not cover as an important product (Annex III, class I, point 19).
3. Confirm your role. You are the manufacturer if you market the product under your name or trademark (Article 3(13)).
4. Check Annex III and Annex IV. Products whose core functionality matches an Annex III category are important products (class I or II); Annex IV lists critical products. The class decides your conformity route (Articles 7, 8 and 32). Integrating a component with Annex III functionality does not by itself make your product important (Article 7(1)).
5. Sort legacy products. Products placed on the market before 11 December 2027 fall under the CRA only if substantially modified from that date (Article 69(2)); Article 14 reporting applies regardless (Article 69(3)).
6. Record the decision as an approved, versioned document.

2. Secure design requirements

1. Run a cybersecurity risk assessment covering intended purpose, foreseeable use, operating environment, assets and expected time in use (Article 13(2) and 13(3)).
2. Map Annex I, Part I, point 2. For each requirement, record whether it applies, how you implement it, and a justification where it does not apply (Article 13(3) and 13(4)).
3. Work through the design requirements (Annex I, Part I, point 2):
   • no known exploitable vulnerabilities at release (a)
   • secure by default, with a reset to the original state (b)
   • security updates, automatic by default where applicable, with an opt-out (c)
   • access control, confidentiality and integrity (d, e, f)
   • data minimisation (g)
   • availability, including denial-of-service resilience, and limited impact on other networks (h, i)
   • limited attack surface and exploitation mitigation (j, k)
   • security logging with an opt-out (l)
   • secure removal of user data and settings (m)
4. Apply due diligence to third-party and open-source components (Article 13(5)).
5. Keep the risk assessment current during the support period (Article 13(3)).

3. SBOM and component tracking

1. Draw up a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies (Annex I, Part II, point 1).
2. Produce one SBOM per released software or firmware version, and link it to the hardware revision it ships on.
3. Include the SBOM in the technical documentation (Annex VII, point 2(b)), and be ready to provide it to a market surveillance authority on a reasoned request (Annex VII, point 8).
4. Decide whether to share it with users. You are not obliged to make the SBOM public (recital 77). If you do share it, the user information must say where to find it (Annex II, point 9).
5. Watch for implementing acts on SBOM format and elements (Article 13(24)).

SBOM and product data covers formats, minimum elements and revision control.

4. Vulnerability handling and reporting

Process (Annex I, Part II, unless noted):

1. Designate a single point of contact for vulnerability reports; users choose the means of communication, not only automated tools (Article 13(17)). Publish a contact address for reporting (point 6).
2. Put in place and enforce a coordinated vulnerability disclosure policy (point 5).
3. Run effective and regular security tests and reviews (point 3).
4. Remediate without delay; where technically feasible, ship security updates separately from functionality updates (point 2).
5. Distribute updates securely (point 7), without delay and free of charge, with advisory messages (point 8).
6. Once a fix is available, publish information about the fixed vulnerability (point 4).
7. Report vulnerabilities you find in integrated components to whoever maintains them (Article 13(6)).

Mandatory reporting (Article 14). Notify the CSIRT designated as coordinator and ENISA simultaneously, through the single reporting platform (Articles 14(1) and 16):

Event	Early warning	Notification	Final report
Actively exploited vulnerability	Within 24 hours of becoming aware	Within 72 hours	No later than 14 days after a corrective or mitigating measure is available
Severe incident affecting product security	Within 24 hours of becoming aware	Within 72 hours	Within one month of the incident notification

8. Inform impacted users, and where appropriate all users, of the vulnerability or incident and of mitigations they can apply (Article 14(8)).
9. Decide in advance who triages, who decides a report is reportable, and who submits it. The clock starts when you become aware.

5. Technical documentation

Draw it up before placing on the market and update it at least during the support period (Article 31(2)). Annex VII sets the minimum content:

1. General description: intended purpose, software versions affecting compliance, hardware illustrations, user information (point 1).
2. Design and development information, including drawings, schemes and system architecture (point 2(a)).
3. Vulnerability handling: the SBOM, the disclosure policy, evidence of a reporting contact and the secure update solution (point 2(b)).
4. Production and monitoring processes and their validation (point 2(c)).
5. The cybersecurity risk assessment (point 3).
6. Information used to determine the support period (point 4).
7. Harmonised standards, common specifications or certification schemes applied, or the solutions adopted instead (point 5).
8. Test reports (point 6).
9. A copy of the EU declaration of conformity (point 7).

Microenterprises and small enterprises may use a simplified documentation form specified by the Commission (Article 33(5)).

6. Conformity assessment and CE marking

1. Choose the procedure (Article 32):
   • products not listed in Annex III or IV: module A (internal control), modules B and C, module H, or a certification scheme where available (Article 32(1))
   • important, class I: module A only where harmonised standards, common specifications or certification schemes are applied in full; otherwise B and C, or H (Article 32(2))
   • important, class II: B and C, H, or a certification scheme at assurance level at least "substantial" (Article 32(3))
   • critical: a European cybersecurity certification scheme under Article 8(1), or a class II procedure (Article 32(4))
2. Draw up the EU declaration of conformity using the model in Annex V (Article 28); one declaration where several Union acts apply (Article 28(3)).
3. Affix the CE marking before placing on the market (Article 30(3)), followed by the notified body number where module H is used (Article 30(4)).
4. Identify the product with a type, batch or serial number (Article 13(15)), and provide manufacturer contact details (Article 13(16)).
5. Ship the user information in Annex II (Article 13(18)).
6. Keep series production in conformity as design and production change (Article 13(14)).

7. Support period and updates

1. Set the support period to reflect expected time in use: at least five years, or the expected use time if shorter (Article 13(8)).
2. Document how you set it in the technical documentation (Article 13(8); Annex VII, point 4).
3. State the end date, at least month and year, at the time of purchase (Article 13(19)).
4. Keep each security update available for at least 10 years after issue, or the remainder of the support period if longer (Article 13(9)).
5. Assess each change against the definition of substantial modification (Article 3(30)), and update the risk assessment and technical documentation.
6. Act on non-conformity with corrective measures, withdrawal or recall (Article 13(21)).

8. Documentation retention

1. Keep the technical documentation and EU declaration of conformity for at least 10 years after placing on the market, or the support period if longer (Article 13(13)).
2. Keep the user information and instructions available for the same period (Article 13(18)).
3. Be able to hand an authority everything needed to show conformity, on a reasoned request (Article 13(22)).
4. File records by product revision, so you can find the set for any shipped revision years later.

Where product data and document control fit

Most items on this list produce a document that your team must approve, version, tie to a product revision and keep for a decade, which is the job of document control. CRA compliance with neo shows how neo handles those documents and what it leaves to other tools, or you can talk to us about your product line.