CRA compliance checklist: every Cyber Resilience Act step, with the evidence to keep

• 10 December 2024 – the CRA entered into force.
• 11 June 2026 – the rules on notifying conformity assessment bodies (Chapter IV, Articles 35–51) apply.
• 11 September 2026 – the Article 14 reporting obligations apply. They also cover products placed on the market before 11 December 2027 (Article 69(3)).
• 11 December 2027 – all other obligations apply.

Reporting is already live. Everything else has a fixed date roughly 14 months away.

This checklist summarises the text of the regulation. It is not legal advice, and working through it does not by itself mean that a product meets the CRA.

Do one pass per product and per role. Mark each item done, open or not applicable. For “not applicable”, write down why: Article 13(4) requires a clear justification in the technical documentation where an essential requirement does not apply.

• Product has digital elements and a data connection (Article 2(1)). Evidence: a short scope note with the intended purpose and all device or network connections.
• Exclusions checked: medical devices, in-vitro diagnostics, vehicle type-approval, civil aviation, marine equipment (Article 2(2)–(4)). Evidence: the scope note names the regime that applies, or none.
• Remote data processing included where the product needs it to perform a function (Article 3(2)). Evidence: an architecture sketch that marks which backend services are in scope.
• Role defined per product: manufacturer, importer or distributor (Articles 13, 19, 20). Evidence: role recorded on each product.
• Manufacturer status checked for rebranded or substantially modified products (Articles 21, 22). Evidence: a dated decision note.
• Importers: conformity assessment, technical documentation, CE marking, EU declaration of conformity and user information verified before placing on the market (Article 19(2)). Evidence: a supplier verification record per product.
• Distributors: CE marking and required documents verified (Article 20(2)). Evidence: an incoming-goods check record.

In Attesly, each product is one record, and importers and distributors keep the evidence for their own role on it.

• Core functionality compared with Annex III (important, class I or II) and Annex IV (critical). Evidence: a classification memo naming the category, or “default”.
• Technical descriptions checked in Implementing Regulation (EU) 2025/2392. Classification follows core functionality, not every embedded component (Article 7(1)). Evidence: the memo cites the description used.
• Conformity route chosen from Article 32 (see Phase 6). Evidence: the module recorded with a reason.
• Classification re-checked after every substantial modification. Evidence: a change log entry.

Attesly suggests a product class and a conformity route on the product record. You review the suggestion, change it where needed and keep your reasoning with it.

• Cybersecurity risk assessment documented and updated during the support period (Article 13(2)–(3)). Evidence: a dated, versioned risk assessment.
• No known exploitable vulnerabilities at release (point 2(a)). Evidence: a vulnerability check of the release SBOM with triage notes.
• Secure by default, with a reset to the original state (2(b)). Evidence: the default configuration and a hardening test.
• Security updates possible, automatic by default where applicable, with opt-out and postponement (2(c)). Evidence: an update mechanism description and test.
• Protection from unauthorised access and reporting of possible unauthorised access (2(d)). Evidence: authentication design and test results.
• Confidentiality of data, e.g. encryption at rest and in transit (2(e)). Evidence: a cryptography inventory.
• Integrity of data, commands, programs and configuration (2(f)). Evidence: signing or integrity-check description.
• Data minimisation (2(g)). Evidence: a data inventory mapped to the intended purpose.
• Availability and resilience, including against denial of service, and limited impact on other networks (2(h)–(i)). Evidence: resilience test results.
• Limited attack surface and exploitation mitigation (2(j)–(k)). Evidence: a list of external interfaces and enabled mitigations.
• Security logging of relevant internal activity, with user opt-out (2(l)). Evidence: the list of logged events.
• Secure deletion of all data and settings, and secure transfer (2(m)). Evidence: a deletion procedure and test.

• SBOM in a commonly used, machine-readable format, covering at least top-level dependencies (point 1). Evidence: one SBOM per released version.
• Vulnerabilities remediated without delay; security updates separate from feature updates where feasible (2). Evidence: tickets with timestamps.
• Regular security tests and reviews (3). Evidence: test reports.
• Fixed vulnerabilities disclosed once an update is available (4). Evidence: published security advisories.
• Coordinated vulnerability disclosure policy in place and enforced (5). Evidence: the published policy.
• Contact address for vulnerability reports (6) and a single point of contact (Article 13(17)). Evidence: the contact page or security.txt.
• Secure update distribution and free security updates with advisory messages (7–8). Evidence: distribution and signing description, advisory template.
• Due diligence on third-party and open-source components; component vulnerabilities reported upstream (Article 13(5)–(6)). Evidence: component review notes and upstream reports.

Attesly imports SBOMs as CycloneDX or SPDX JSON (for example from syft, cdxgen or Trivy) or converts Excel/CSV to CycloneDX, by upload, paste or API/CI. Components with a package URL (purl) are checked against OSV.dev on import, on every rescan and daily. Components that carry only a CPE name are checked against the NVD where that check is active; everything else is documented, not checked. More in CRA evidence and SBOM per product.

• General description: intended purpose, software versions relevant to conformity, hardware photos, user information (point 1).
• Design, development and vulnerability handling: system architecture, SBOM, disclosure policy, proof of the contact address, update distribution (point 2).
• Risk assessment showing how Annex I, Part I applies (point 3).
• Support period reasoning (point 4).
• Standards applied: harmonised standards, common specifications or certification schemes, or a description of the solutions used instead (point 5).
• Test reports for Parts I and II of Annex I (point 6).
• Copy of the EU declaration of conformity (point 7).
• User information per Annex II: manufacturer contact, single point of contact, product identification, support end date, instructions for secure use, updates and decommissioning.

Evidence for all items: one versioned technical file per product. Attesly shows a gap score from 0 to 100 for what is still missing, keeps six CRA document types with revisions and exports as CSV, JSON, Markdown or print-to-PDF. Details: CRA Annex VII technical documentation.

• Default products: internal control, module A (Article 32(1)).
• Important, class I: module A only if harmonised standards, common specifications or a certification scheme are fully applied; otherwise module B+C or H (Article 32(2)).
• Important, class II: module B+C, H, or a European cybersecurity certification scheme at level “substantial” or higher (Article 32(3)).
• Critical: a European cybersecurity certificate where a delegated act requires it, otherwise as class II (Article 32(4)).
• Notified body booked early where needed. Evidence: quote or contract.
• EU declaration of conformity drawn up (Article 28) and CE marking affixed (Article 30); a full or simplified declaration with its URL ships with the product (Article 13(20)).
• Product identification and manufacturer contact on the product, packaging or accompanying document (Article 13(15)–(16)).

• “Awareness” defined: who decides that a vulnerability is actively exploited or an incident is severe (definitions: Article 3, Article 14(5)). Evidence: a written procedure with named people and a deputy.
• Account on ENISA’s single reporting platform ready, and your coordinating CSIRT determined (Article 14(7)). Evidence: account details, backup user.
• Early warning within 24 hours of awareness (Article 14(2)(a), (4)(a)).
• Notification within 72 hours (Article 14(2)(b), (4)(b)).
• Final report: for a vulnerability, no later than 14 days after a fix or mitigation is available; for a severe incident, within one month of the 72-hour notification (Article 14(2)(c), (4)(c)).
• Affected users informed about the issue and possible mitigations (Article 14(8)). Evidence: the user notice.

Attesly calculates these deadlines from the dates in a case and prepares a summary for the reporting platform. See Article 14 reporting preparation.

• Support period set: at least five years, unless the product is expected to be in use for less (Article 13(8)). Evidence: the reasoning in the technical file.
• End of support (month and year) shown at the time of purchase (Article 13(19)).
• Each security update kept available for at least 10 years or the rest of the support period, whichever is longer (Article 13(9)).
• Technical documentation and declaration kept for at least 10 years or the support period, whichever is longer (Article 13(13)).
• SBOM, vulnerabilities and risk assessment re-checked with every release (Article 13(3), (7)). Evidence: dated revisions.
• Corrective action, withdrawal or recall when a product does not meet Annex I (Article 13(21)).
• Authorities and users informed before ceasing operations (Article 13(23)).

Breaches of Annex I and of Articles 13 and 14 can lead to fines of up to EUR 15 million or 2.5 % of worldwide annual turnover, whichever is higher (Article 64(2)). Missing evidence is usually found when an authority asks, and that is the worst moment to build it.

Keep the evidence in one place. Attesly holds one record per product with SBOM, vulnerability checks, Article 14 deadlines and the technical file.