In recent years, attackers have increasingly exploited flaws in software and connected devices, and the digital product supply chain has become one of the weakest links in the European economy. The European Union’s response is Regulation 2024/2847, better known as the Cyber Resilience Act. The CRA reshapes how manufacturers, importers, and distributors are held accountable for the security of products with digital elements throughout their entire lifecycle. This article sets out the most important CRA requirements and the practical steps companies should take before the regulation comes into full effect.
What Is the Cyber Resilience Act?
The Cyber Resilience Act is Regulation (EU) 2024/2847 of the European Parliament and of the Council, which establishes uniform horizontal cybersecurity requirements for products with digital elements placed on the EU market. The full text of the act has been published in the Official Journal of the European Union and is available on EUR-Lex.
The CRA is horizontal in scope, meaning it applies to all hardware and software products with digital elements regardless of the sector in which they are sold. Compliance is signalled by the CE marking, which until now was associated mainly with the physical and electrical safety of products. From now on, the CE mark also confirms cyber resilience. This is a first at EU level and has direct consequences for any company that designs or sells digital products to customers in member states.
Why the EU Introduced the Cyber Resilience Act
The regulation responds to several issues that the European Commission has been highlighting since 2022. The first is the rising number of vulnerabilities in everyday consumer products and the inadequate provision of security updates. The second is the lack of transparency around the security level of IoT devices and software offered to consumers and businesses.
Until the CRA was published, EU cybersecurity rules focused on entities and service operators rather than on the products themselves. The NIS2 Directive places obligations on operators of essential and important services, DORA governs operational resilience in the financial sector, but none of these acts has so far set requirements for makers of software and hardware. The CRA closes that gap by shifting responsibility for product cybersecurity onto the entities that design and supply those products. The regulation is part of the EU’s broader digital strategy aimed at building the resilience of the single digital market.
Which Products Fall Under the CRA?
The CRA has a very broad scope. The regulation defines a product with digital elements as any software or hardware, together with related remote data processing solutions, that can connect directly or indirectly to a device or network. As a result, IT product security covers everything from office software and network equipment such as routers and smart TVs to smart home devices like locks and cameras, as well as internet-connected toys. The regulation also applies to industrial control systems and mobile applications.
Not every digital product falls under the CRA, however. The regulation expressly carves out categories already covered by other EU acts.
| Products excluded from the CRA | Legal basis / reason |
| Medical devices | Regulation (EU) 2017/745 (MDR) |
| In vitro diagnostic devices | Regulation (EU) 2017/746 (IVDR) |
| Motor vehicles and their components | Regulation (EU) 2019/2144, UN regulations |
| Aviation products | Regulation (EU) 2018/1139 |
| Products developed exclusively for defence or national security | Article 2 CRA |
| Pure SaaS (a service with no product component) | The CRA is product legislation |
| Free and open-source software outside commercial activity | Recital 18, Article 3 CRA |
These exclusions reflect the principle that cybersecurity rules should not be duplicated where other acts already address the issue. Any product that does not fall into one of these categories and connects to a device or network is very likely to be in scope.
Who Must Comply With the CRA
CRA obligations are spread across the supply chain, but the bulk of responsibility rests with the manufacturer. The manufacturer of software or hardware is the entity that designs or commissions the production of the product and places it on the market under its own brand. It is the manufacturer who carries out the risk assessment, draws up the technical documentation, signs the EU declaration of conformity, and affixes the CE mark.
The importer is responsible for ensuring that a product from outside the EU complies with the CRA before it reaches the internal market. The importer checks for the CE mark and complete documentation, and halts sales if there is any doubt about CRA compliance. The distributor, the final link in the chain, verifies the CE mark and confirms that the manufacturer and importer have fulfilled their obligations. Both importers and distributors are also required to cooperate with market surveillance authorities and to notify the manufacturer of any vulnerabilities they become aware of.
A separate category is the open-source software steward. This is a legal person that provides sustained support for the development of free and open-source software intended for commercial use. Stewards are subject to selected CRA requirements, such as maintaining a cybersecurity policy and reporting vulnerabilities, but they are not exposed to financial penalties for breaches.
The CRA’s Key Requirements for Manufacturers
The detailed CRA requirements for manufacturers are set out in Annex I, which is divided into two parts. Part I covers the properties of the product itself. The manufacturer must place on the market a product that is free from known vulnerabilities, ships with a secure default configuration in line with security by default, and includes mechanisms for data protection and access control. The number of potential entry points for an attacker should be kept to a minimum. Part II covers vulnerability management throughout the product’s support period.
CRA implementation begins with a cybersecurity risk assessment that the manufacturer must carry out and apply at every stage of the product lifecycle, from planning through to maintenance. The results feed into the technical documentation, which market surveillance authorities can inspect for at least 10 years from the date the product was placed on the market. The manufacturer must also exercise due diligence over third-party components so that they do not weaken the cybersecurity of the finished product. Failure to vet suppliers is one of the most commonly underestimated risks here.
Security by Design and Security by Default as the Foundation of Compliance
Security by design means that security must be an integral part of the product from the earliest concept stage. Architectural decisions on the authentication model or how sensitive data is stored are taken with the security team in the room. Product and security teams work together from the very first draft of the specification.
Security by default means that the product, the moment it is switched on, runs in the most secure configuration its intended use allows. Default administrator passwords or unused services left enabled are exactly the kind of configuration choices the CRA seeks to eliminate at source. The user should be able to operate the product securely from the start, without having to configure basic protections by hand. Together, security by design and security by default form the foundation on which the detailed essential requirements of Annex I are built.
How Does Vulnerability Management and Security Updates Work Under the CRA?
Vulnerability management under the CRA rests on several pillars. The manufacturer must operate a vulnerability handling policy that provides for the receipt of external reports (coordinated vulnerability disclosure) and the analysis of security vulnerabilities in the product and its components. On top of that comes the obligation to deliver fixes without undue delay. Security updates must be made available throughout the support period, which the manufacturer sets but which cannot be shorter than the product’s expected useful life would justify.
The key operational tool for vulnerability management is the SBOM (Software Bill of Materials), a list of the software components used in the product. An SBOM makes it possible to quickly identify which products are exposed when a vulnerability surfaces in a widely used library. Security updates are, as a rule, supplied free of charge and accompanied by clear guidance for the user on how to install them. Where it is technically feasible, security updates should be separated from feature updates so that the user can install the fix alone, without being forced to accept changes to product functionality.
What Are the Reporting Deadlines for Incidents and Actively Exploited Vulnerabilities?
Reporting is operationally one of the most demanding obligations under the CRA. The manufacturer reports a severe incident or an actively exploited vulnerability (one that has already been used in a real attack) to the national CSIRT (Computer Security Incident Response Team) and to ENISA, the European Union Agency for Cybersecurity. A single submission through the common reporting platform run by ENISA is enough. The platform forwards the notification to the CSIRTs in other member states where the product is made available. Article 14 of the CRA sets out four different report types with different deadlines.
| Report type | Deadline | Recipient |
| Early warning | Within 24 hours | CSIRT and ENISA (Single Reporting Platform) |
| Main notification | Within 72 hours | CSIRT and ENISA |
| Final report for an actively exploited vulnerability | No later than 14 days after a fix becomes available | CSIRT and ENISA |
| Final report for a severe incident | One month after the main notification | CSIRT and ENISA |
The manufacturer must also inform users of the affected product about the incident or vulnerability, and about any available protective measures, without undue delay. The reporting obligations take effect on 11 September 2026 and apply to all products with digital elements made available on the EU market, including those placed on the market before the regulation became fully applicable. For SOC and product teams, this means putting in place procedures for detecting and triaging cybersecurity incidents, and clear escalation paths from operational staff up to the board, so that the 24-hour deadline is genuinely achievable.
Standard, Important, and Critical Products: How the CRA Categorises Risk
The CRA tailors requirements to the risk category of the product. Standard (non-critical) products make up the majority and undergo conformity assessment by way of self-assessment. Important products are listed in Annex III and split into two classes. Critical products are listed in Annex IV, and that list carries the strictest requirements.
Important products in Class I include password managers and antivirus software, among others. Class II covers products with a higher security significance, such as enterprise firewalls and HSM modules. Critical products include components of smart meters and smart cards used in authentication infrastructure. The technical descriptions of these categories are set out in Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025.
When Is Self-Assessment Enough, and When Is a Notified Body Required?
The CE marking on a digital product confirms that the manufacturer has carried out the appropriate conformity assessment and that the product meets the essential CRA requirements. The mode of conformity assessment depends on the product’s risk category.
For standard products, internal production control (Module A), in other words self-assessment, is enough. The manufacturer verifies compliance, signs the declaration, and affixes the CE mark on that basis. For important products in Class I, self-assessment is only available where the manufacturer has applied harmonised standards or relied on a European cybersecurity certification scheme. Otherwise, an assessment by a notified body is required: a notified body is an independent certification organisation designated by a member state to assess products against CE requirements. For Class II important products and for critical products, assessment by a notified body is, as a rule, mandatory.
Harmonised standards play a particularly important role here. Applying them creates a presumption of conformity with CRA requirements, which simplifies the conformity assessment and reduces the risk of disputes with supervisory authorities. The European Commission, with the support of ENISA and the European standardisation bodies (CEN, CENELEC, and ETSI), is currently developing a set of harmonised standards that will allow manufacturers to demonstrate CRA compliance in a predictable way.
CRA Implementation Timeline: The Key Dates
The CRA gives manufacturers a phased preparation period, but not every obligation kicks in at the same moment.
10 December 2024: Regulation 2024/2847 enters into force.
11 June 2026: Member states begin notifying the European Commission of the conformity assessment bodies authorised to assess products against the CRA.
11 September 2026: The reporting obligations under Article 14 take effect. Manufacturers begin reporting actively exploited vulnerabilities and severe incidents.
11 December 2027: The CRA becomes fully applicable. From this date, no product with digital elements that fails to meet the requirements may be placed on the EU market.
How to Get Your Organisation Ready for the Cyber Resilience Act
Preparing for the CRA is a multi-dimensional task that requires product teams to work hand in hand with security, legal, and procurement. The first step is a full inventory of the product portfolio. The company needs to know which of its products fall under the CRA and what risk category they belong to. The manufacturer then translates the requirements of Annex I into the processes of the product lifecycle and identifies any gaps.
The next area is rolling out an SBOM for each product, alongside a vulnerability handling policy with defined channels for external reports. Security teams must design a reporting procedure that fits within the 24-hour deadline, including escalation rules from operational staff up to the board. Contracts with component suppliers need to be updated with clauses on security and on vulnerability disclosure.
In parallel, it is worth getting the technical documentation and the cybersecurity risk assessment into a state where they can be put in front of a supervisory authority at short notice. This is where systematic compliance management earns its keep, joining requirements, evidence, and reports in one place and cutting down on manual work. Without such a system, the cost of maintaining CRA compliance grows in step with the number of products and components in the company’s portfolio.
How the CRA Will Affect Software, Hardware, and IoT Manufacturers
Software makers will feel the change above all in the area of open-source dependencies and support periods. The manufacturer must exercise due diligence over third-party libraries, including those pulled from public repositories. When a vulnerability surfaces in an external component, the manufacturer needs to know exactly what is inside its product and how to respond. Pure SaaS sits outside the CRA as a service, but software delivered for installation on the customer’s premises is in scope, which extends the obligations to a large slice of the B2B market.
Hardware manufacturers, particularly in IoT, are required to ensure product cybersecurity throughout the entire declared support period. For many low-cost devices this is a fundamental shift, because until now the support period has too often existed only on paper. Manufacturers must maintain firmware updates and keep control over component supply. In industrial IoT, IT product security has to be reconciled with sector-specific rules, for example in energy or transport.
In the open-source space, the regulation provides exemptions for non-commercial projects, while open-source software stewards face a narrower set of obligations. Companies that commercialise open-source projects gain a clear line between their commercial responsibility and the support delivered by the community.
How the CRA Sits Alongside Other EU Cybersecurity Rules
The CRA does not operate in isolation. The NIS2 Directive addresses the cybersecurity of essential and important entities, such as digital service providers, operators of critical infrastructure, and hospitals. DORA sets operational resilience requirements for the financial sector and its ICT providers. None of these acts directly regulates the cybersecurity of products placed on the market, and that is precisely the gap the CRA fills.
The CRA also intersects with other EU acts. The RED Directive (2014/53/EU), together with delegated act 2022/30, introduced cybersecurity requirements for radio equipment. Those requirements will be largely absorbed into the CRA, which makes life easier for makers of wireless devices. The GDPR remains a separate regime governing the protection of personal data and runs in parallel with the CRA, since many cybersecurity incidents involve a personal data breach. For companies, this means that a single incident may trigger reporting obligations under the CRA and under other acts at the same time, such as NIS2 or the GDPR, requiring a coordinated legal and operational response.
The Most Common Challenges in CRA Implementation
CRA implementation tends to expose the same difficulties across companies. The first is the component supply chain. A large share of products draws on libraries and modules supplied by dozens of vendors, whose security policies vary widely in quality. Demonstrating due diligence over hundreds of components calls for purpose-built tooling, because spreadsheets simply will not cope.
The second challenge is setting the support period. Manufacturers who have so far supported a product for a few years now need to revisit their business models. A poorly chosen support period exposes the company to penalties and to the loss of customer trust.
The third difficulty is evidence: being able to demonstrate compliance under inspection. Supervisory authorities can ask for technical documentation and the results of security testing. Companies that have run tests but never documented them systematically will need to build an audit trail from scratch.
A further issue concerns the status of products already on the market when the CRA becomes fully applicable on 11 December 2027. The manufacturer is not required to retrofit them to the new requirements until a substantial modification is made. Reporting obligations, however, apply to all products made available on the EU market, including those sold many years earlier. The manufacturer should therefore clearly define and announce the end-of-support date for each product, because without that it will be hard to push back against reports concerning older versions.
What the CRA Means for Businesses
The Cyber Resilience Act changes how responsibility for the cybersecurity of products with digital elements is allocated across the European Union. For manufacturers, importers, and distributors, it is both an obligation and an opportunity. Companies that start now to put their design processes, vulnerability management, and technical documentation in order will arrive in 2027 with declarations of conformity ready and uninterrupted access to the market. Those who delay risk both penalties and the loss of competitive ground to suppliers for whom cyber resilience has already become part of the product proposition. The European Commission publishes ongoing updates on CRA implementation.
