EU Cyber Resilience Act (CRA): Complete Compliance Guide 2026

The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, establishes cybersecurity requirements for products with digital elements supplied commercially in the EU. It covers hardware and software whose intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network. A connected thermostat, a Bluetooth accessory and a commercially supplied application can all be relevant examples. A digital component alone is not a complete scope test: connectivity, commercial supply and the regulation’s exclusions matter.

The regulation entered into force on 10 December 2024. Manufacturer reporting obligations apply from 11 September 2026; the main product requirements apply from 11 December 2027. This is not simply a future IT project. A product business needs an incident reporting process now and a product compliance programme for the later phase. Our CRA Readiness Checker separates those workstreams without treating a questionnaire as certification.

Who needs to comply

Manufacturers carry the central design, vulnerability-handling and reporting duties. A company that has a product developed and sells it under its own name or trademark can be the manufacturer even if an external factory writes the firmware. Importers and distributors have their own checks and must not supply products they know are non-compliant. Rebranding or substantially modifying a product can transfer manufacturer obligations under Article 21.

Non-EU manufacturers are not exempt because the engineering team is elsewhere. The relevant issue is supplying an in-scope product to the EU market. Components supplied separately can themselves be covered. Remote data processing designed or developed by, or under the responsibility of, the manufacturer is included when its absence would prevent the product performing one of its functions. This does not make every unrelated cloud service a CRA product.

Free and open-source software supplied outside commercial activity is treated differently; a free download alone does not establish the exclusion. Assess the commercial context and the separate open-source steward provisions where relevant. For a first view across product rules, use our Quick Compliance Scan, then examine the precise CRA scope rather than assuming every electronic item is covered.

Reporting requirements already in force

Article 14 distinguishes actively exploited vulnerabilities from severe incidents affecting product security. A theoretical weakness or an ordinary service interruption does not automatically meet those tests. Assess information promptly, record when the manufacturer became aware and avoid turning an internal review into a reason to delay notification. Reporting is through ENISA’s Single Reporting Platform to the relevant CSIRT coordinator and ENISA.

For an actively exploited vulnerability, submit an early warning without undue delay and within 24 hours of awareness. Submit the vulnerability notification within 72 hours, including available information about the affected product, vulnerability, exploitation and corrective measures. The final report is due within 14 days after a corrective or mitigating measure becomes available. That last deadline is not fourteen days from first awareness.

For a severe incident, the early warning and notification deadlines are likewise 24 and 72 hours. The final incident report is due within one month after submitting the incident notification. The distinction matters when building reminders: one final deadline depends on a fix becoming available, the other on a notification already submitted. Record both triggers, the responsible owner and the evidence in an incident log.

A practical runbook identifies who can report outside office hours, who approves technical facts, how the organisation reaches suppliers and how users receive timely advice. Article 14 also requires timely information to affected users, including available mitigation measures. Our CRA readiness assessment highlights missing reporting and user-notification arrangements; it does not submit notifications on your behalf.

Full product requirements from December 2027

Annex I requires a risk-based approach to secure design and vulnerability handling. Relevant measures include secure defaults, protection against unauthorised access, confidentiality and integrity of data, reduced attack surfaces, secure update mechanisms and safe removal of user data. Evidence must connect these measures to actual use and foreseeable threats, not just a generic checklist signed by a supplier.

Vulnerability handling includes identifying components, maintaining a machine-readable software bill of materials covering at least top-level dependencies, assessing weaknesses, testing security, publishing a coordinated disclosure policy and providing a contact point. Security updates must be delivered securely and without undue delay. Link the component inventory, affected product versions and delivered update so that a later inquiry can reconstruct what happened.

The support period must reflect expected product use and normally be at least 5 years. Where expected use is shorter than five years, the period must cover that shorter expected use. A durable household device may need longer support; five years is not permission to ignore its expected lifetime. Publish the support end date for buyers and budget for vulnerability handling across the period, including third-party dependencies. Record supplier maintenance commitments and plan what happens if a dependency stops receiving security fixes.

The manufacturer must complete the appropriate conformity assessment, prepare technical documentation, issue the EU declaration of conformity and affix CE marking. An existing CE mark does not establish CRA compliance. Equally, earlier CE legislation does not concern only physical safety: cybersecurity provisions can already apply under other regimes. Assess the complete product legislation stack and the transition between regimes.

Product categories and assessment routes

The default category covers products not listed as important or critical. Internal control is an available conformity route. Do not treat “consumer device” as a shortcut to default status: security cameras, particular connected toys and certain wearables can fall within the important list.

Important Class I products in Annex III include identity-management software, password managers, VPN products, operating systems, routers and modems, and specified security-function devices. Internal control is available only under Article 32 conditions, including full application of relevant harmonised standards, common specifications or an applicable certification scheme; otherwise a third-party route is needed.

Important Class II includes hypervisors and container runtimes, firewalls and intrusion-detection/prevention systems, and tamper-resistant microprocessors and microcontrollers. These require third-party conformity assessment. Critical products are in Annex IV, including hardware devices with security boxes, smart meter gateways and smartcards or similar secure devices. Certification requirements depend on relevant delegated measures; the Class II route applies where the specific certification requirement has not been established. Match intended functionality to the annexes rather than choosing a class from the marketing name.

Timeline and legacy products

Use the Deadline Calendar to organise milestone work, but keep incident clocks in an operational runbook. Article 69 provides a transition for products placed on the market before 11 December 2027: they generally become subject to full requirements if substantially modified from that date. Article 14 reporting still applies to in-scope earlier products. “Already sold” is neither a blanket reporting exemption nor a requirement to recertify every unchanged legacy unit.

Distinguish placing a particular unit on the market for the first time from later making it available. A model launched years ago can still have new units placed on the market after the application date. Keep records of versions, supply dates and modifications so the business can justify transition treatment instead of relying on the age of the model name.

Common mistakes

• Waiting until 2027 to build reporting capability: the reporting phase is already active.
• Assuming the factory owns the legal duties because it developed the software: own-brand supply can make your company the manufacturer.
• Calling all important products third-party-only: Class I has a conditional internal-control route; Class II does not share that general option.
• Promising five years of updates without checking expected use or supplier commitments.
• Treating an SBOM as a security assessment: it identifies components but does not establish that their use is secure.
• Assuming an existing CE mark or readiness result proves conformity: evidence and the assessment procedure remain necessary.

Related product obligations

A connected consumer product may also have GPSR obligations for risks not covered by specific product legislation. Our Amazon GPSR guide explains listing information without suggesting Amazon takes over manufacturer duties. If the product contains a battery, read the EU Battery Regulation guide; cybersecurity and battery lifecycle obligations address different issues.

Next steps

Document scope, confirm the legal manufacturer and classify the product. Inventory software and support contracts, then close immediate reporting gaps before scheduling assessment work. Use the CRA Readiness Checker to prioritise missing evidence and the Compliance Cost Calculator for indicative planning costs, not a notified-body quote. Our team’s tools organise the work; qualified technical and legal review remains necessary for uncertain cases.

Primary sources

Regulation (EU) 2024/2847, Articles 2, 13, 14, 21, 32, 64, 69 and 71; Annexes I, III and IV. ENISA Single Reporting Platform guidance. Informational guidance, not legal advice.