The Сyber Resilience Act: what it means, who it applies to, and how to prepare

The Cyber Resilience Act (CRA) deadlines are approaching, and most companies still do not realize how directly it will affect them. If you manufacture or distribute products with digital components for the European market, you likely need to start preparing now. 

I have spent the last few months working with clients across industries to translate the regulation into practical next steps. This is not just another compliance checkbox. It is a fundamental shift in how product security is defined, delivered, and maintained across the product lifecycle.

The complexity isn't in the concept – mandatory cybersecurity standards make sense. The hard part is determining whether your specific product is in scope, what category it falls into, and what you need to do to comply. Get it wrong, and you could face unnecessary certification costs, delays to market, or non-compliance when enforcement begins.

The scope of the CRA is broader than you think

The Cyber Resilience Act was formally adopted by the European Parliament in March 2024, and it's arguably the most significant cybersecurity regulation for product manufacturers to date. Unlike GDPR (personal data protection) or NIS2 (critical infrastructure and essential services), the CRA targets the security of the products themselves. In practice, it introduces CE marking expectations for software and connected hardware.

What is the ‘CE’ marking and what does it mean?

• It’s a market-access requirement, not a quality award.
• The manufacturer must identify the EU regulations/standards that apply, then show the product meets them.
• That proof usually includes technical documentation (often called a “technical file”), risk assessment, and a signed EU Declaration of Conformity.
• Some product types can be self-assessed by the manufacturer; higher-risk categories require an independent third party called a Notified Body.

Why CE matters for the Cyber Resilience Act (CRA):

For many products with digital elements, the CRA effectively treats cybersecurity as part of what you need to demonstrate for EU market access, alongside the documentation and processes that support compliance throughout the product’s lifecycle.

The CRA applies regardless of where your company is headquartered. If you sell into the EU, you will likely need to comply with the requirements.

Who should be concerned?

You should pay particular attention if you are any of the following:

• A manufacturer of products with digital elements (hardware and/or software)
• An importer or distributor placing in-scope products on the EU market
• A software developer whose software is distributed to users as a product

Even open-source projects aren't entirely exempt, though there are some nuances worth understanding. If you develop software as a hobby, for research, or strictly non-profit, you are generally exempt. If you monetize your project (in any form), you are treated as a manufacturer and must comply.

In short, CX is now a lever for revenue, loyalty, and competitive advantage, not just a brand metric.

CRA timeline: Two deadlines you cannot ignore

The Cyber Resilience Act officially entered into force on December 10, 2024. From that point, the clock started ticking toward two key deadlines:

September 11, 2026: The Reporting Deadline

By this date, the affected organizations must report actively exploited vulnerabilities and severe incidents to authorities (ENISA/CSIRTs). The internal processes for detecting and escalating these issues must be operational.

December 11, 2027: The Full Compliance Deadline

All in-scope products placed on the market must comply with CRA requirements, including CE marking expectations, technical documentation, and essential cybersecurity properties.

CRA penalties: fines, recalls, and EU market access risk

Penalties under the CRA are tiered based on what you breach. The most serious failure is non-compliance with the CRA’s essential cybersecurity requirements, which can trigger fines of up to €15 million or 2.5% of global annual turnover (whichever is higher). 

Breaches of other obligations (including many market-access and documentation-related duties) can be fined up to €10 million or 2% of turnover.

Beyond fines, market surveillance authorities can require you to fix the non-compliance, and may restrict availability, withdraw, or recall products. (Imagine having to physically recall 50,000 smart thermostats from customers' homes because your firmware update process wasn't compliant!)

The additional factors are reputational damage and market access risk. If your products are flagged as non-compliant, you could be blocked from the entire EU market.

CRA product categories: Where your product fits into the risk tiers

The CRA applies broadly to Products with Digital Elements (PDEs). In simple terms, if a product relies on code or a data connection to function, it is likely in scope. 

This covers everything from connected hardware (smart devices, industrial controllers) to pure software (operating systems, firmware, and apps).

What counts as a “product with digital elements”

Common examples include: 

• Hardware: Any physical device with a data connection (logical or physical). (e.g., laptops, smart fridges, microcontrollers, IoT sensors).
• Software: Any code file or package that the user installs or executes on their own device. If the user "possesses" the file (e.g., .exe, .apk, .dmg, firmware), it is a product.

The SaaS trap: CRA vs NIS2

Many organizations ask: "We are pure SaaS, are we safe?" The answer depends on your architecture.

• If your solution is a website or platform accessed solely via a browser (e.g., online banking, webmail), you likely fall under NIS2 (as a service), not the CRA.
• If your cloud software is the "brain" of a physical device you sell (e.g., the backend for a smart doorbell), that software is caught by the CRA.

A quick applicability check

As a simple starting point, ask:

If the answer to any of these is no, the CRA doesn’t apply (or another regulation may take priority).

The CRA also does not treat all code or products equally. It uses a risk-based approach, and your CRA compliance path depends on classification (for example: Default, Important Class I, Important Class II, and Critical Products). 

Lower-risk products may allow more self-assessment, while higher-risk categories can require third-party assessment and notified body involvement. 

The higher the classification, the more rigorous the certification expectations and ongoing obligations.

How to start: gap assessment and a practical roadmap

While legislation often moves slowly, the CRA is staying on schedule. However, even companies with mature security practices often lack the documentation, process formalization, and governance that the CRA demands.

Start with a gap assessment. Map your products against the classification criteria, identify which may fall into higher-risk classes, and evaluate your current security documentation and vulnerability handling processes against the CRA’s essential requirements. Beyond regulatory obligations, this is also an opportunity to improve your security posture in ways that matter to customers and reduce long-term product risk. 

The approaching deadlines tend to make people nervous, and that's a perfectly normal response. The dates will not change, but CRA compliance need not be overwhelming – it requires a structured approach. The important thing is to start now rather than waiting for enforcement actions to force your hand.