But wait, there's more!
No items found.

Cyber Resilience Act (CRA): The full overview of scope, requirements and timeline

If you work with EU regulation within cyber and operational resilience, your attention is probably already split. NIS2 is in motion, DORA is reshaping expectations for financial entities, and many CER questions are still unresolved.

On top of that, the Cyber Resilience Act (CRA) sits in a grey zone. Product teams know it is coming, leadership hears about it in fragments, and conversations circle around timing and scope.

If you need to understand where this regulation fits - and why it is different - this overview is for you.

What is the Cyber Resilience Act (CRA)?

At its core, the CRA is a product regulation, not an organizational measure. It establishes mandatory cybersecurity requirements for commercial products with digital elements. The purpose is to ensure that hardware and software placed on the EU market meet a consistent level of cybersecurity throughout their lifecycle.

Unlike earlier EU cyber legislation, which primarily addresses how organizations manage risk, the CRA focuses on the security characteristics of the product itself. Cybersecurity becomes a legal prerequisite for market access, enforced through conformity assessment and CE marking.

The regulation applies directly in all EU member states and introduces requirements covering secure design, vulnerability handling, post-market monitoring and incident reporting.

The CRA focuses on the security characteristics of your product - not on enterprise level security.

Who is in scope?

The CRA applies to economic operators involved in placing or making digital products available on the EU market. Which obligations apply depends on whether you manufacture, import or distribute digital products in the EU.

Manufacturers

Manufacturers carry the primary obligations under the CRA. This covers any organization that places a product on the EU market under its own name -regardless of whether development or production was handled in-house or by a third party. If your name is on the product, the full weight of the regulation applies to you.

Importers

Importers must verify that products originating outside the EU comply with the CRA before those products are placed on the EU market.

Distributors

Distributors are responsible for ensuring that products they make available in the EU carry the required markings and documentation and are not known to be non-compliant.

While responsibilities differ by role, the CRA creates shared accountability across the supply chain. Products that do not meet CRA requirements cannot be legally marketed in the EU.

What products are in scope?

Separate from questions of responsibility, the CRA also defines which products fall within scope.

If you are trying to determine whether your product is covered, the starting point is broad: any hardware or software product that can connect - directly or indirectly - to another device or a network is in scope, unless it is already regulated under a sector-specific EU framework (for example, medical devices or type-approved vehicles).

This includes:

  • connected hardware
  • embedded software
  • standalone software products

The regulation is technology-neutral. If your product can send or receive data beyond its physical enclosure, it is likely to be covered. This applies across consumer and industrial contexts - from smart thermostats and fitness trackers to industrial control components and embedded software used in manufacturing environments.

In practice, this broad rule often leads to follow-up questions - especially when products rely on cloud infrastructure, open-source components or long-standing designs.

What about SaaS products?

Purely cloud-based services are not regulated as services under the CRA. But if you place software on the market as a product - downloadable applications or firmware, for instance – it may still fall within scope, even if it depends on cloud infrastructure to function.

What about open-source software?

Open-source software developed or supplied outside a commercial context is generally excluded. If you incorporate open-source components into a commercial product, the product as a whole remains subject to the CRA.

What about products designed long before the CRA applies?

The CRA doesn't retroactively regulate the design of products that are already on the EU market. So you don’t need to change your product if it was introduced before the regulation takes effect. But – and this is crucial - the reporting obligations of the CRA apply to all products, regardless of age. Here’s how it breaks down.

The regulation has two main types of requirements: security requirements that shape how a product is built, and reporting obligations that kick in when vulnerabilities are actively exploited or severe incidents occur.

For security requirements, you're in the clear - as long as you don't substantially modify your product after the CRA application date. If you do, the modified product needs to comply in full.

For reporting, there's no such distinction. If a vulnerability in your product is being actively exploited, you need to report it (see specifics below). The age of your product doesn't get you off the hook.

Reporting obligations apply to all digital, commercial products on the EU market - regardless of age.

Core CRA requirements

At a high level, the CRA sets out what is expected of products with digital elements once they are placed on the EU market.

The regulation requires that products:

  • are designed and developed in line with secure-by-design and secure-by-default principles.
  • include processes for identifying, documenting and remediating vulnerabilities.
  • provide security updates for the expected product lifetime or a minimum defined period.
  • support mandatory vulnerability and incident reporting within specified timeframes.
  • are supported by technical documentation demonstrating compliance - maintained for ten years or the full support period of your product (whichever is longer).

Rather than prescribing specific technical controls, the CRA defines outcomes and responsibilities. How you meet these requirements is left to you, but you remain accountable for meeting them throughout your product’s lifecycle.

The fines for non-compliance range based on severity: up to €5 million or 1% of global annual turnover for minor non-compliance cases and up to €15 million or 2.5% of global annual turnover for the most serious violations.

Product categories and conformity assessment

Products covered by the CRA are grouped into categories that determine how conformity is assessed. These categories affect how compliance must be demonstrated - not whether the CRA requirements apply.

  • Critical products: Products based on their critical dependencies by essential entities (NIS2) and the potential for incidents.
  • Important products - class II: Products essential for critical infrastructure or with a high cybersecurity impact.
  • Important products - class I: Products with significant cybersecurity functions.
  • General Products with Digital Elements: Any other product with a digital element, not designated in CRA annex III-IV.

For lower-risk products, you may rely on internal conformity assessment. Higher-risk or critical products may require assessment by a third-party notified body before CE marking:

Product category Examples Compliance
Critical Products Hardware security boxes, smart meter gateways, smartcards (cf. annex IV to the CRA). Third-party conformity assessment; may require "substantial" assurance.
Important Products (Class II) Firewalls, IDS, IDP, hypervisors, container runtimes, tamper-resistant processors/controllers. Mandatory third-party conformity assessment by a notified body.
Important Products (Class I) VPNs, SIEMs, identity/access management, smart home products. Self-assessment using harmonised standards; otherwise third-party assessment.
General Products with Digital Elements Standard consumer electronics, basic software applications. Self-assessment procedures.

Notified bodies are designated by EU member states and authorized to perform these assessments.

Knowing which category your product falls into matters early, as it affects both timelines and the level of external scrutiny involved.

CRA timeline: key dates

At first glance, the December 2027 deadline makes the Cyber Resilience Act feel distant.

In reality, some obligations take effect much earlier and may require your organization to change how digital product security is owned, governed and maintained. When incident and vulnerability reporting becomes enforceable in September 2026, you must already have detection, escalation and notification processes in place.

The following dates apply across all EU member states:

  • September 11, 2026 – strict notification duties apply for all in-scope products on the EU market. Manufacturers must report actively exploited vulnerabilities and severe security incidents - with a 24-hour early warning, a 72-hour full notification and a final report within 14 days.
  • December 11, 2027 – From this date, products with digital elements must meet the CRA’s essential cybersecurity requirements, complete the conformity assessment and demonstrate compliance.

Where this leads

While some implementation detail will continue to mature through standards and guidance, the core CRA obligations are already defined. Unlike the early days of DORA, the direction is clear enough to act on.

What remains is not interpretation, but deliberate choices about how your product security is owned, maintained and sustained once your products are on the market.

Need even more?
Sebastian Bille-Just
Management Consultant