Cyber Resilience Act Compliance Checklist: 15 Steps to Prepare Before 2027

Test each product, not the company. A product is in scope if it has digital elements, connects directly or indirectly to a device or network, and is sold commercially in the EU. Separate standalone SaaS from remote data-processing solutions integral to a product’s function — the latter are in scope as part of the product.

This decision drives cost and lead time, because it determines whether you can self-assess. Most products sit in the default tier. Annex III Part A (Class I) can self-assess only where harmonised standards, common specifications or an EU certification scheme cover all applicable requirements; Part B (Class II) cannot self-assess at all; Annex IV critical products may need an EU certificate by delegated act. Classification follows core functionality, not embedded components — use Implementing Regulation (EU) 2025/2392.

Figure 2: CRA product classification tiers and the conformity assessment route each one triggers

Sell a product under your own name, or substantially modify one already on the market, and you become the manufacturer with the full obligation set. Define what substantial modification means for your products before a release forces the question, and push CRA duties into supplier contracts.

Article 13(2) requires a risk assessment per product, kept current through the support period and included in the technical documentation. It determines which Annex I requirements apply and how, so every other decision leans on it. Cover intended and foreseeable use, including misuse.

Products must be made available without known exploitable vulnerabilities and, subject to the risk assessment, must deliver secure defaults with reset, access control, confidentiality and integrity protection, data minimisation, DoS resilience, limited attack surfaces, exploitation mitigation, logging with a user opt-out, and secure permanent data deletion. Harmonised standards under request M/606 have slipped, so build against the annex text.

Under Article 13(8) the period must reflect expected use and be at least five years unless the lifetime is demonstrably shorter. Article 13(19) requires the end date, month and year, at the point of purchase, and Article 13(9) requires each update to stay available for ten years after issue. Cost it before committing publicly.

Annex I Part II(1) requires a software bill of materials in a commonly used and machine-readable format covering at the very least top-level dependencies. Generate it in CI/CD as SPDX or CycloneDX per release, covering firmware and OS packages as well as libraries, and wire it into vulnerability monitoring.

Article 13(5) requires due diligence when integrating third-party components. Annex I Part II adds that on identifying a vulnerability in one you must remediate it and report it to whoever maintains that component. Using an open-source library does not move the risk to its maintainers, so plan a route to fix, fork or replace when upstream is unresponsive.

Annex I Part II sets eight process obligations across the support period: document components and vulnerabilities; remediate without delay; test and review regularly; disclose fixed vulnerabilities with impact, severity and remediation guidance; enforce a disclosure policy; provide a reporting contact; distribute updates securely; and ship security updates free of charge with advisories.

Two requirements are visible from outside your organisation, making them a natural first check for an authority: a coordinated disclosure policy, and a contact address for reporting vulnerabilities in your product or its components. Publish at a stable URL, add security.txt, and log every report — enforcing the policy is itself the obligation.

Live since 11 September 2026 and, under Article 69(3), applicable to products already placed on the EU market. Notify through the ENISA single reporting platform to your coordinating CSIRT and to ENISA: early warning within 24 hours of becoming aware, notification within 72 hours, and a final report within 14 days of a corrective measure becoming available for a vulnerability, or one month for a severe incident. Article 3(42) defines an actively exploited vulnerability, but the CRA does not define the severity threshold, so your criteria must be written down. Article 14(8) also requires you to inform impacted users.

Figure 3: The CRA Article 14 reporting clock — 24 hours, 72 hours and the final report

Sign updates, verify signatures on the device, protect the delivery channel and support rollback. Where technically feasible, security updates must be delivered separately from functionality updates, and they must be disseminated without delay and free of charge with advisory messages — no security fix behind a support contract. Design so a failed update cannot brick a fielded device.

Default products use internal control (Module A). Class I can self-assess only with full standards coverage. Class II needs a notified body or an EU certification scheme at assurance level at least ‘substantial’. Modules B, C and H are also available. Chapter IV only applied from 11 June 2026, so notified body capacity is scarce — engage early.

Annex VII technical documentation covers the product description, design and development detail, the risk assessment, vulnerability handling, the support period, standards applied and test reports. Annex II sets the user information. Then draw up the Annex V declaration of conformity and affix the CE marking. Article 13(13) requires both to stay available to authorities for ten years after placing on the market, or the support period, whichever is longer.

Authorities can require information, order corrective action and restrict, withdraw or recall a product — what protects you is producing current evidence quickly. Assign an owner per product line, set a review cadence that keeps the risk assessment, SBOM, technical file and declaration current, and make substantial modification a release gate.

TWO RELIEF PROVISIONS

Article 64(10)(a): micro and small enterprises are not fined for missing either 24-hour early warning deadline — all other deadlines still apply. Article 64(10)(b): open-source software stewards are not subject to administrative fines — this does not extend to commercial manufacturers.

COMMON MISTAKES TO AVOID