The Cyber Resilience Act's reporting duties have applied since 11 September 2026, yet many manufacturers still cannot list which of their products are in scope, which class each falls into, or who would file a 24-hour early warning tonight. This readiness checklist is a self-assessment for manufacturers of products with digital elements: twelve checks mapped to the Regulation's article and annex numbers, each with a measure, a data source type and green, amber and red bands, plus a cadence table, a findings log and a remediation map. It is run by the product security lead with compliance, engineering and support owners, and signed off by the executive accountable for product compliance. The Regulation itself is explained in the EU Cyber Resilience Act Guide; this page tests whether you are ready for it.
Status (checked 13 November 2026): Regulation (EU) 2024/2847 applies in full from 11 December 2027 (Article 71). Article 14 reporting has applied since 11 September 2026, through the Single Reporting Platform that ENISA runs and that the European Commission states became operational that day. Under Article 69(3), reporting covers products placed on the market before 11 December 2027 as well, while the other obligations reach those older products only if they are substantially modified from that date (Article 69(2)). The Commission's implementation pages showed no amendment to these dates when checked.
What this health check covers
If you searched for a CRA readiness checklist or a Cyber Resilience Act compliance checklist, this is the working version. It covers the eight areas the plan for most manufacturers turns on: product inventory, class assignment, SBOM coverage, the vulnerability handling process, a tested 24-hour reporting path, a declared support period, the conformity route and technical file completeness. Four further checks cover component due diligence, the documented risk assessment, update delivery and the reporting scope for legacy products.
It does not repeat what each obligation means; the EU Cyber Resilience Act Vulnerability and Incident Reporting Guide and the EU CRA Product Classes Guide do that in depth. Importers, distributors and open-source software stewards have different duties and are out of scope here.
Key takeaways
- Reporting is live now: an actively exploited vulnerability or severe incident in any product on the EU market, old or new, starts the 24-hour clock under Article 14 today.
- Classification drives cost: default products can use internal control, but important class II and critical products need third-party assessment or certification under Article 32, which takes months to book.
- The SBOM is a requirement, not a nice-to-have: Annex I Part II point 1 asks for a machine-readable SBOM covering at least top-level dependencies, and it forms part of the technical documentation.
- Support periods are a product decision: at least five years unless the product's expected use is shorter (Article 13(8)), with the end month and year shown at purchase (Article 13(19)).
- The technical file is the proof: Annex VII lists eight elements; gaps there are what a market surveillance authority finds first.
How to use this template
Copy the checklist table and the findings log into your own tracker. Run checks C1 and C2 first, because the product list and its classes set the denominator and the route for every other check, then score the rest per product line. Record every amber or red result as a finding with an owner and a due date. Re-run the checklist at the cadence below until 11 December 2027 and keep each completed version: the history shows a market surveillance authority that compliance work was planned and tracked.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Reporting path test (C5) | Quarterly, and after any change of contact, tool or main establishment | Product security incident response lead | Head of product security | Exercise log with timestamps, platform account check, contact list |
| Product and class register (C1, C2) | Before each product launch and quarterly | Product compliance lead | Head of product | Product register, classification decisions with reasoning |
| SBOM and vulnerability handling (C3, C4, C9, C11) | Monthly | Product security lead | Head of engineering | SBOM inventory per release, vulnerability tracker, advisories issued |
| Full readiness run (C1 to C12) | Quarterly until December 2027, then twice a year | Product security lead | Accountable executive | Checklist workbook, findings log, sign-off record |
| Independent re-performance | Yearly | Internal audit, second line or external assessor | Audit or risk committee | Re-performed samples, variance notes |
Metrics
Each check is a readiness metric with a formula, scored per product or product family. NHI Mgmt Group recommended thresholds; adjust to your risk appetite. Where a duty already applies (C5, C12), anything below green is a compliance gap today.
| ID | Check (article) | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| C1 | Product inventory (Art 2 scope) | Products with digital elements made available in the EU that are in the CRA product register with a scope decision / such products in sales and product catalogue records | Product register; sales and catalogue data | 100% | 95% to below 100% | < 95% |
| C2 | Class assignment (Art 7, Art 8, Annexes III and IV) | In-scope products with a recorded class (default, important class I or II, critical) and reasoning against the technical descriptions / in-scope products | Classification records | 100% | 90% to below 100% | < 90% |
| C3 | SBOM coverage (Annex I Part II(1)) | Current releases with a machine-readable SBOM covering at least top-level dependencies, generated in the build / current releases | Build pipeline artefacts; SBOM store | ≥ 95% | 80% to below 95% | < 80% |
| C4 | Vulnerability handling process (Annex I Part II(2) to (8), Art 13(17)) | Annex I Part II points 2 to 8 with a documented, operating process, plus a published single point of contact / 8 | Process documents; published CVD policy and contact; vulnerability tracker | 8 of 8 | 6 or 7 | Below 6 |
| C5 | Reporting within 24 hours tested (Art 14) | Quarterly exercises in which the early warning was drafted and ready to submit within 24 hours of the awareness timestamp / exercises run | Exercise logs; platform account and role records | All exercises within 24 h; at least two named submitters | One or more exercises late, or only one named submitter | No exercise in the quarter, or no working platform access |
| C6 | Support period declared (Art 13(8), Art 13(19), Annex II(7)) | In-scope products with a determined support period, its reasoning recorded, and end month and year shown to buyers / in-scope products | Support policy; product pages and packaging captures | 100% | 90% to below 100% | < 90%, or any period below five years without an expected-use reason |
| C7 | Conformity route (Art 32) | In-scope products with a selected route (module A, B+C, H or certification scheme) matching their class, and notified body booked where needed / in-scope products | Conformity plan; notified body correspondence | 100% | Route chosen for all, bookings below 100% | Any class II or critical product without a route |
| C8 | Technical file completeness (Art 31, Annex VII) | Annex VII points present and current in the file / 8, per product | Technical documentation index | 8 of 8 | 6 or 7 | Below 6 |
| C9 | Component due diligence (Art 13(5), 13(6)) | Third-party and open-source components in current releases with a recorded due diligence check and a route to report vulnerabilities to the maintainer / such components | Component register; SBOM; supplier records | ≥ 95% | 80% to below 95% | < 80% |
| C10 | Risk assessment documented (Art 13(2) to (4)) | In-scope products with a cybersecurity risk assessment covering Annex I Parts I and II, updated in the last 12 months / in-scope products | Risk assessment records | 100% | 90% to below 100% | < 90% |
| C11 | Update delivery (Annex I Part II(2), (7), (8); Art 13(9)) | Security fixes in the quarter delivered free, through a secure channel, with an advisory, and separately from feature updates where feasible / security fixes in the quarter | Release notes; advisories; update channel records | ≥ 95% | 85% to below 95% | < 85% |
| C12 | Legacy product reporting scope (Art 69(3)) | Products already on the market before 11 December 2027 that are covered by the reporting process and vulnerability monitoring / such products | Product register; monitoring scope | 100% | 95% to below 100% | < 95% |
Deadlines and routes at a glance
| Item | Requirement | Source |
|---|---|---|
| Actively exploited vulnerability | Early warning within 24 hours, notification within 72 hours, final report within 14 days after a corrective measure is available | Art 14(2) |
| Severe incident | Early warning within 24 hours, notification within 72 hours, final report within one month of the notification | Art 14(4) |
| Where to report | Single Reporting Platform, to the CSIRT designated as coordinator in the Member State of main establishment and to ENISA at the same time | Art 14(1), 14(7) |
| Default products | Any Article 32(1) procedure, including internal control (module A) | Art 32(1) |
| Important class I | Module A only where harmonised standards, common specifications or certification were fully applied; otherwise B+C or H | Art 32(2) |
| Important class II | B+C, H, or a certification scheme at assurance level at least substantial | Art 32(3) |
| Critical | Certification scheme under Article 8(1), otherwise a paragraph 3 procedure | Art 32(4) |
| Records | Technical documentation and declaration kept at least 10 years or the support period, whichever is longer | Art 13(13) |
Article 64 sets maximum fines of EUR 15 million or 2.5% of worldwide annual turnover for breaches of Annex I and Articles 13 and 14, whichever is higher, with lower tiers for other obligations.
How to collect the data
- Start from what you sell: pull the catalogue and sales records for products made available in the EU, including firmware, apps and remote data processing that the product needs, and record a scope decision per product.
- Classify against the official descriptions: compare each product's core functionality with the Annex III and Annex IV categories and the Commission's implementing act on technical descriptions, and store the reasoning.
- Take SBOMs from the build: count releases with an SBOM produced by the pipeline, not documents assembled by hand afterwards.
- Walk Annex I Part II point by point: for C4, ask for the evidence of each point operating in the last quarter, such as an advisory published or a report received through the contact address.
- Time the exercise: for C5, start the clock when a simulated report reaches the contact point and stop it when the early warning is ready, with the platform account checked as working.
- Read the file, not the plan: for C8, open each Annex VII element in the technical documentation and confirm it is current.
Red flags that need action now
- No one in the organisation can sign in to the Single Reporting Platform, or only one person can.
- No agreed definition of the awareness moment that starts the 24-hour clock.
- Products already on the market left out of reporting because the team believes the CRA starts in December 2027.
- No published contact point or coordinated vulnerability disclosure policy.
- Class II or critical products with no notified body or certification plan.
- Support periods set by marketing without the Article 13(8) factors recorded, or shorter than five years with no reason.
- SBOMs produced only on request, or covering only some product lines.
- Security fixes shipped only inside feature releases with no advisory.
A tampered update channel is the kind of event that can make an incident severe under Article 14(5), because it can introduce malicious code. That is why update signing and build integrity belong in the readiness scope, even though no single check above names them.
Findings log
| Finding ID | Finding | Check | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-CRA-01 | [Only one platform submitter; no deputy] | C5 | [Critical] | [PSIRT lead] | [DD/MM/YYYY] | [Open] |
| HC-CRA-02 | [Router family not yet classified against Annex III] | C2 | [High] | [Product compliance lead] | [DD/MM/YYYY] | [In progress] |
| HC-CRA-03 | [Mobile app releases have no SBOM] | C3 | [High] | [Mobile engineering lead] | [DD/MM/YYYY] | [Open] |
| HC-CRA-04 | [Support end date missing from product pages] | C6 | [Medium] | [Product marketing lead] | [DD/MM/YYYY] | [Open] |
| HC-CRA-05 | [Technical file lacks test reports for Annex I Part II] | C8 | [Medium] | [Quality lead] | [DD/MM/YYYY] | [Open] |
Rate a finding critical when it affects a duty that applies now (reporting) and high when it blocks the conformity route before December 2027.
Remediation map
| Finding type | Where to fix it |
|---|---|
| Scope and obligations unclear (C1, C10) | EU Cyber Resilience Act Guide |
| Class and conformity gaps (C2, C7) | EU CRA Product Classes Guide; EU Cyber Resilience Act Harmonised Standards Guide |
| SBOM and component gaps (C3, C9) | SBOM Guide; SBOM operations |
| Disclosure and handling gaps (C4, C11) | ISO/IEC 29147 and 30111 Vulnerability Disclosure and Handling Guide; Bug Bounty and Vulnerability Disclosure Guide |
| Reporting path gaps (C5, C12) | EU Cyber Resilience Act Vulnerability and Incident Reporting Guide |
| Hardware and firmware components (C3, C9) | Hardware and Firmware SBOM Guide |
Related guides
- EU Cyber Resilience Act Guide: the obligations this checklist tests.
- EU Cyber Resilience Act Executive Briefing: the board view and investment decisions.
- EU Cyber Resilience Act Vulnerability and Incident Reporting Guide: the Article 14 process in depth.
- EU Vulnerability Database (EUVD): the EU database that sits alongside disclosure.
- NIS2 Readiness Checklist: for manufacturers that are also NIS2 entities.
References
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- European Commission: Cyber Resilience Act reporting obligations
- European Commission: Cyber Resilience Act implementation
This guide summarises obligations under Regulation (EU) 2024/2847 and is not legal advice. Related NHI Mgmt Group resources: EU Cyber Resilience Act Guide · EU CRA Product Classes Guide · SBOM Guide · EU Cyber Resilience Act Executive Briefing