Everything you need to know about the CRA – what it is and who it covers

The Cyber Resilience Act is rolling out across the EU. We've put together a complete guide to the regulation for decision-makers in companies with digital products.

For years, product cybersecurity has worked a bit like fire safety in old buildings: everyone knew it was a problem, but few took it seriously. Manufacturers shipped products with known vulnerabilities, support dried up after a couple of years, and the consequences always landed on the user.

The EU is changing that.

The Cyber Resilience Act (CRA) introduces binding, horizontal cybersecurity requirements at EU level for products with digital elements placed on the EU market. Regulation (EU) 2024/2847 entered into force on 10 December 2024. Whether you manufacture industrial equipment, consumer electronics or software, the CRA sets out essential cybersecurity requirements that apply throughout the product lifecycle.

The timing is no accident. Europe has seen a sharp rise in cyberattacks targeting vulnerable products and components in recent years. According to ENISA, the EU's cybersecurity agency, a significant share of successful attacks exploit known vulnerabilities that were never patched. The CRA is the response: security must be built in from the start, not bolted on after the fact.

For any company with products on the European market, the CRA is already a reality – regardless of where they're based. Obligations take effect on a staggered timeline, with the first applying from June 2026 and full enforcement from December 2027.

We've compiled everything you need to know about the Cyber Resilience Act right here. And if you still have questions when you're done reading, our consultants are ready to help.

We cover:

• Who is affected – including SaaS, RDPS and open source
• The five specific requirements the regulation places on manufacturers
• How to classify your product into the right category
• The four deadlines you need on your radar
• Penalties for non-compliance
• How to move forward with CRA compliance
  
  

Who is covered? More companies than you'd expect

The CRA generally applies to companies that manufacture, import or distribute products with digital elements on the EU market as part of a commercial activity. That may sound narrow, but in practice the scope is broad. It covers hardware and software whose intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network.

The regulation distinguishes between three types of market actors, each with its own set of obligations:

1. Manufacturers design and bring products to market under their own name or brand. They carry the most extensive obligations and are the central focus of the CRA. If you develop and sell software, you are a manufacturer under the regulation, whether your product is a piece of hardware, an app or a software package.
   
   

2. Importers are companies established in the EU that bring products from non-EU manufacturers to market. If the manufacturer is not EU-based, the importer takes on a share of the manufacturer's responsibility.
   
   

3. Distributors are everyone else in the supply chain who makes products available on the market. They face fewer obligations than manufacturers and importers, but they are not off the hook – they must, among other things, ensure that products are correctly labelled and accompanied by the required documentation.

Does the CRA apply to your SaaS solution or cloud service?

This is the critical question many organisations overlook – and the answer is more nuanced than most would hope. Pure SaaS delivered entirely through a browser is not automatically in scope. But if your software is an integral part of a product, or if your cloud solution is what makes a product functional in the first place, you are very likely within scope.

This covers what the guidance refers to as Remote Data Processing Solutions (RDPS): software that processes data remotely as a precondition for a product with digital elements to carry out one of its functions. And it's not only core functionality that counts – supporting and supplementary features are included too. If your smart door lock has a cloud service that does nothing more than send a push notification when someone unlocks the door, that cloud service is still covered by the CRA, even though the lock itself works perfectly well without it.

Let’s look at a specific example: a mobile app for a smart thermostat. The app isn't a standalone product but is inextricably tied to the product and therefore in scope under the CRA. The same logic applies to backend systems, API layers and analytics platforms that a manufacturer develops as part of a product's functionality.

Selling open source software? The CRA is relevant here too, but the rules differ. If your open source software is free and non-commercial, you are typically not a manufacturer under the CRA – but if you act as a steward of an open source project that other companies build commercial products on top of, you still have obligations.

And if your company integrates open-source components into its products, it is your responsibility to ensure those components meet the requirements.

So what does this mean?

If your company develops software, sells products with network connectivity, or supplies digital components used in other companies' products, you need to set aside time to determine your CRA status.

The starting point is not whether you think of yourself as a "technology company" – it's what your product actually does.

What the regulation requires – specifically

The CRA places requirements across the full product lifecycle: from design right through to market withdrawal. For many manufacturers, this is the biggest shift in mindset: a product is not "done" in the eyes of regulators just because it has shipped.

To make the requirements more manageable, they can be grouped into five areas:

1. Security is the default, not an add-on

The most fundamental requirement is that products must be designed and developed with cybersecurity integrated from the outset.

In concrete terms, that means:

• No known exploitable vulnerabilities at the point of market placement.
• Secure default configurations – the product is secure straight out of the box.
• Minimal attack surface and protection against unauthorised access.

The principle is security by design: a direct challenge to the longstanding practice of treating security as a feature that could always be added later.

2. Risk assessment and technical documentation

Manufacturers must carry out a cybersecurity risk assessment for their product and keep it current throughout the product's lifetime. The risk assessment underpins everything else – classification, conformity assessment and documentation.

Technical documentation must also be produced to demonstrate how the product meets the regulation's essential requirements. This documentation must be retained for the full support period, with a hard floor of 10 years from the date the product was first placed on the market.

3. Vulnerability management

Under the CRA, manufacturers are required to continuously monitor, identify and address vulnerabilities in their products.

That includes maintaining a coordinated vulnerability disclosure policy, regularly testing products, promptly distributing security updates, and sharing vulnerability information with relevant authorities and users.

4. Reporting of active exploits and vulnerabilities (Article 14)

From 11 September 2026, strict reporting deadlines apply. If a manufacturer discovers an actively exploited vulnerability in its product, it must notify the national CSIRT within 24 hours.

The CSIRT (Computer Security Incident Response Team) is the national contact point that shares information with ENISA and the authorities of other affected member states via ENISA's joint reporting platform. A more detailed report must follow within 72 hours.

For incidents with a significant impact on security, a final report is due no later than one month after the initial 72-hour notification. A final vulnerability report must be submitted within 14 days of a fix becoming available.

The deadlines are tight, and processes must be in place before an incident ever occurs. This is not something you improvise when an attack is already underway.

5. Support period and end of life

One of the most underestimated requirements in the CRA is the support period obligation. Manufacturers must define and communicate a specific support period for each product – and that period must, as a baseline, be at least five years.

Throughout the declared period, the manufacturer must provide security updates. The end date for support must be visible to buyers at the point of purchase (at a minimum, month and year), and users must be notified when the support period expires.

Five years is a minimum, not a target. If you sell a product with a realistic lifespan of ten years, that lifespan – not five years – is the baseline for the support period.

For software that receives continuous updates and releases new versions, there is some flexibility. In certain cases, you may limit patches to the most recent version, provided users can upgrade free of charge and incur no additional costs, such as new hardware or fundamental infrastructure changes.

Classification: determining which category your product belongs to

Not all products face the same requirements. Beyond the baseline obligations, the CRA operates on three tiers. What places a product in a given tier is neither your industry, your company size, nor your sales volume – it is your product's core functionality.

• Standard products make up the vast majority of products with digital elements. This category covers products whose core functionality does not fall within any of the specifically defined classes. Standard products are subject to the regulation's baseline requirements and can, as a rule, use internal self-assessment as their conformity assessment procedure.
  
  

• Important products – Class I covers products with functions that may pose an elevated security risk, including password managers, VPN-enabled products, network management software, SIEM systems, and industrial control systems. Internal self-assessment remains available for Class I products, but only if the manufacturer fully applies the relevant harmonised standards. If they do not, third-party validation is required.
  
  

• Important products – Class II covers products with particularly critical functions: hypervisors and container runtime systems supporting the virtualised execution of operating systems, firewalls, intrusion detection and prevention systems (IDS/IPS), and tamper-resistant microprocessors and microcontrollers. Third-party certification is mandatory for this class.
  
  

• Critical products are a narrow category reserved for infrastructure components such as hardware security modules (HSMs), smart card chips and smart meter gateways. The strictest requirements apply here.

The EU guidance includes an example that illustrates the classification logic well:

• A manufacturer brings a security suite to market, integrating an SIEM module, an IDS module and an analytics tool.
• If those modules are sold separately via subscription, each is classified individually: the SIEM module as Important Class I, the IDS module as Important Class II, and the analytics tool as Standard.
• It is the core functionality of each individual module – not the product as a whole – that determines classification.

In practice, this means a platform with five modules can have five different conformity assessment requirements. You cannot classify your way out of it by calling it one integrated product.

Key CRA deadlines at a glance

The CRA is being phased in over three years – not because the EU is hesitant, but because manufacturers, importers and authorities all need time to prepare. Here are the four milestones to keep on your radar:

• 10 December 2024 – The CRA enters into force. The regulation is adopted and binding EU law. The countdown to full compliance has begun.
• 11 June 2026 – Market surveillance authorities gain enforcement powers. They can investigate products, demand documentation and remove non-compliant products from the market. Enforcement is live.
• 11 September 2026 – Reporting obligations kick in. From this date, manufacturers have 24 hours to report actively exploited vulnerabilities to the national CSIRT – and 72 hours to follow up with a detailed report. Processes need to be in place before an incident happens. You cannot improvise this in the middle of an attack.
• 11 December 2027 – Full compliance is mandatory. All new products with digital elements placed on the EU market must meet the CRA's requirements and carry the CE marking as proof.

Navigating multiple frameworks at once? Read on: CRA vs. AI Act vs. GDPR vs. DORA vs. ISO 27001 – a breakdown of overlaps and differences.

What happens if you don't comply?

The EU is serious about the CRA, and – as with GDPR and the AI Act – the penalties for non-compliance are substantial.

The most serious category of violation, defined as failure to meet the essential security requirements, can result in fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.

Breaches of other obligations, including inadequate documentation or labelling, carry a ceiling of €10 million or 2% of global turnover. Providing incorrect information to authorities can result in fines of up to €5 million or 1% of global turnover, whichever is higher.

Beyond financial penalties, market surveillance authorities may require a product to be withdrawn from the market or prohibit its sale until it meets the requirements. That consequence can potentially hit a business far harder than any fine.

One important point: enforcement is national. Each EU member state has its own market surveillance authority with the power to act on products sold in its market – independently of other member states.

If you sell across multiple EU countries, you can, in principle, face sanctions in multiple jurisdictions for the same product. In other words, non-compliance can get extremely expensive.

The right questions will help you move forward with CRA

The CRA can look like a lot to take on, but the practical approach is more manageable than the legal text suggests. It comes down to a structured process and the right questions.

Map your exposure. Start by identifying which of your products are in scope and whether any fall into the higher-risk categories. A product inventory and a straightforward classification exercise based on core functionality is the right place to begin.

Assess your gaps. Measured against the CRA's essential requirements: do your products have a documented risk assessment? Are there processes in place for vulnerability management? Has the support period been defined and communicated? Many organisations find at this stage that parts of the foundation are already in place – but that documentation and processes have gaps.

The right GRC platform can consolidate documents, plans, process descriptions and risk assessments in one place. Learn more about Connected Compliance here.

Prioritise Article 14. The reporting obligations apply from September 2026. They require an internal setup capable of handling and escalating security incidents within 24 hours. This is an operational change – one that takes time to build properly.

Integrate CRA into your broader GRC framework. Don't treat CRA as a one-off project. The obligations are ongoing – risk assessments need updating, documentation needs maintaining, vulnerabilities need active management. That requires clear processes and defined ownership, not a single compliance sprint.

Get clarity on your next CRA steps

Not sure which of your products are covered or where the most important gaps lie? NorthGRC’s consultants can help you map your CRA exposure, assess your current readiness and turn the requirements into a practical plan.

Talk to a NorthGRC consultant