Independent information resource Product security · EU CRA
CRA fundamentals / Pillar

Cyber Resilience Act Explained: Scope, Dates, Requirements and 2027 Readiness

A practical overview of the EU Cyber Resilience Act, including product scope, key duties, phased application dates and what organisations should prepare before December 2027.

IN BRIEF

The Cyber Resilience Act is Regulation (EU) 2024/2847. It sets cybersecurity requirements for relevant products with digital elements and assigns duties across the product lifecycle. Some provisions are already applicable in 2026, while the main CRA requirements apply from 11 December 2027.

01 / 06

What the Cyber Resilience Act Changes

The CRA creates a horizontal EU cybersecurity framework for relevant hardware and software products made available on the Union market. Its focus is the security of the product itself across design, development, production, market placement and post-market support. That makes it different from rules that primarily regulate the cybersecurity risk management of an organisation. A company assessing the CRA should therefore begin with the product, its components, its connections and the way it reaches the EU market. The Regulation also connects cybersecurity to product compliance: manufacturers may need to perform a cybersecurity risk assessment, meet applicable essential requirements, prepare technical documentation, follow the correct conformity assessment route and provide required information to users.

02 / 06

Which Products Can Fall Within CRA Scope

The CRA uses the concept of a product with digital elements. In broad terms, that can include software or hardware products and certain remote data processing solutions, as well as software or hardware components placed on the market separately. Scope cannot be decided from a product label alone. Teams need to examine the legal definition, the product's intended or reasonably foreseeable use, its direct or indirect data connection to a device or network, the circumstances in which it is made available on the Union market and any applicable exclusion or special rule. A desktop application, connected device, embedded component or cloud-connected product may therefore require different analysis even when all are described informally as digital products.

  • Define the product and its core functions.
  • Map hardware, software, separately supplied components and necessary remote functions.
  • Check the route by which the product is made available on the EU market.
  • Review exclusions and sector-specific interactions before assuming coverage.
03 / 06

Who Has Responsibilities Under the CRA

The CRA assigns responsibilities according to economic-operator roles. Manufacturers carry the central product-security duties, but importers, distributors and authorised representatives also have role-specific responsibilities. The legal role may not match a company's everyday job title. A business can become especially important under the Regulation when it markets a product under its own name or trademark, changes a product in a way that affects compliance, imports a product from outside the EU or makes a product available further down the supply chain. This means CRA preparation should include a role-mapping exercise alongside product classification. Contracts can allocate operational work between parties, but internal or commercial arrangements do not automatically change the role that the Regulation assigns.

  • Identify the manufacturer for each product.
  • Map importers, distributors and authorised representatives where relevant.
  • Review own-brand, modification, OEM, ODM and outsourced-development arrangements.
  • Document who owns product-security evidence and post-market actions.
04 / 06

The Main Requirement Areas

For manufacturers, CRA readiness reaches beyond a single security checklist. The product's cybersecurity risk assessment informs the design and implementation of applicable essential cybersecurity requirements. Teams also need processes for vulnerability handling, security updates, component and dependency management, user information, technical documentation and conformity assessment. Product classification can affect the assessment route. Post-market responsibilities continue during the support period, and Article 14 adds reporting duties for specified actively exploited vulnerabilities and severe incidents affecting product security. These areas should be connected to the same product record so that engineering evidence, version information, risk decisions, update history and regulatory decisions remain traceable rather than being maintained as separate compliance documents with no operational link.

  • Cybersecurity risk assessment and security requirements.
  • Secure development and vulnerability handling.
  • Security updates and support-period planning.
  • Technical documentation and user information.
  • Conformity assessment, declaration and CE marking where applicable.
  • Article 14 reporting for qualifying events.
05 / 06

What Is Already Applicable in 2026

The Regulation entered into force on 10 December 2024, but its obligations do not all apply on the same date. Chapter IV, covering conformity assessment bodies, has applied since 11 June 2026. Article 14 reporting obligations have applied since 11 September 2026. ENISA's Single Reporting Platform became operational on that same September date for the mandatory notifications described by the CRA. The main CRA provisions apply from 11 December 2027. This distinction matters for any article, checklist or product plan published in 2026: saying simply that the CRA is either fully in force or not yet applicable would hide the phased timetable. Current-status wording should identify the specific provision and its application date.

06 / 06

How to Prepare for 11 December 2027

A practical readiness programme starts by building an inventory of products that may fall within CRA scope and assigning an owner to each product assessment. From there, teams can document the product boundary, economic-operator role, intended use, support period, components, cybersecurity risks and applicable Annex I requirements. Engineering and compliance work should then converge: security controls need verification evidence, vulnerabilities need an intake and remediation workflow, updates need an operational process, and technical documentation needs to reflect the actual product rather than a generic policy library. Conformity planning should begin early enough to identify whether self-assessment is available or external assessment may be needed. The goal before December 2027 is a repeatable product-security system, not a last-minute document exercise.

  • Build and maintain a CRA product inventory.
  • Perform scope and role assessments.
  • Map Annex I requirements to product controls and evidence.
  • Prepare vulnerability handling and Article 14 escalation workflows.
  • Plan technical documentation and conformity assessment.
  • Track official guidance, standards and implementation changes.
REFERENCE DESK

Official sources

Read the full legal text and Commission material for precise wording, qualifications and updates.

Editorial review: 26 September 2026. Regulatory material can change; follow the official sources for current guidance.