.png){kind=logo}
EU Cyber Resilience Act (CRA): Security and Compliance Across the Product Lifecycle
As connected devices and digital services become deeply embedded in every aspect of modern life, the risks to cybersecurity, privacy, and safety have grown dramatically. The EU Cyber Resilience Act (CRA) was introduced to address these concerns through a unified regulatory framework for manufacturers, importers, distributors, and software maintainers.
This guide provides an engineering-focused summary of the CRA, highlighting the core obligations, risk classifications, scope of impact, and implementation timelines. It is designed to help organizations understand what the CRA demands and how it applies to their product lifecycle, from design and development to deployment and decommissioning.
While not a legal interpretation, this guide outlines Keyfactor’s perspective on the CRA and how product teams can begin planning for compliance.
The guide is intended for product security teams, compliance officers, firmware and software engineers, and product managers responsible for connected devices, embedded systems, and digital services that may fall under the scope of the CRA. It is also relevant to organizations managing open-source components, developing secure elements, or operating in regulated markets within the EU.
At the end of this guide, we will also discuss how Keyfactor can help. The CRA introduces a broad set of cybersecurity requirements for products with digital elements, placing responsibility on manufacturers, importers, and software providers to embed security across the full product lifecycle. While the regulation is not prescriptive, it clearly demands robust mechanisms for device identity, software authenticity, secure updates, and lifecycle monitoring. Read more in How can Keyfactor help?
In this context, Public Key Infrastructure (PKI) and digital signing solutions offer a proven and scalable way to address many of the CRA’s core expectations. By establishing cryptographic trust between devices, users, and services, organizations can implement secure boot processes, sign firmware and software updates, issue device certificates, and secure remote access, all aligning with the CRA's risk-based, lifecycle-focused intent.
The following sections will give you an introduction to the CRA and some critical timelines that are useful to know.
About the Cyber Resiliance Act (CRA)
The goal of CRA is to have manufacturers, distributors, importers, and the like be responsible for:
Assessing and documenting cybersecurity risks starting early in the product’s lifecycle and continuing through product decommissioning. Thus, cybersecurity is continuously evaluated during all phases of a product’s lifecycle: ideation, design, development, manufacturing, delivery, and maintenance.
This includes both the product and the supply chain of hardware and software
Performing a conformity assessment before the device is sold into the European Union. This is required for the CE mark.
Monitoring, reporting, and correcting any cybersecurity issues discovered while the device is in service.
Failure to comply with the requirements in Article 13 and 14 has serious financial implications for organizations as outlined in the CRA Article 64(2). The minimum impact is €15,000,000. The maximum impact is 2,5% of the total worldwide annual turnover for the preceding fiscal year.
Failure to comply with other Articles has other financial impacts, with the absolute minimum non-compliance penalty as € 5,000,000
As with most regulations, the CRA is not prescriptive. Therefore, how a manufacturer achieves these goals is not specified.
Definitions
Item | Definition |
|---|---|
Products with Digital Elements (PDEs) | A hardware or software product and any remote data processing hardware or software placed onto the market |
Cybersecurity | The activities necessary to protect network and information systems, the users of such systems, and other persons affected by cyber threats |
Cybersecurity risk | The potential for loss or disruption caused by an incident expressed as a combination of loss magnitude and likelihood of occurrence |
Hardware | A physical electronic system or parts of it that can store, process, or transmit digital data |
Software | Any part of an electronic system which consists of computer code, this could be on the device or remote from the device |
Scope
The CRA defines different types of responsibility scopes:
Product
Article 2(1) states:
“…applies to products with digital elements mde available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical of physical data connection to a device or network.”
Article 3(1) states:
“ ‘product with digital elements’ means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately; “
This is a very large product reach. It implies that any directly or indirectly connected device and anything that it connects to falls under the CRA. For example, an electronic door lock falls under this regulation. Not just the door lock, the firmware and the software used to deploy or configure the device falls under this regulation.
In addition, if the lock provides any cloud-based software, then the cloud-based software also falls under the CRA, insofar as
Article 3(2) applies:
“ ‘remote data processing’ means data processing at a distance for which the software is designed and developed by the manufacturer, or under responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions. “
Also, Articles 3(22) and Recital (15) define that commercial products fall into this category and cannot be sold or provided for free into the EU without meeting the criterion established by the CRA. The provided for free clause encompasses companies that sell services but give the hardware away for free. The CRA still applies in this case. There are exemptions to this rule to allow for alpha and beta product testing, but these products must not remain in the market.
Other exemptions include spare parts, national defense exclusive products, and some medical devices. The latter fall under other EU Regulations, and the cybersecurity directives in those regulations supersede the CRA.
Who is within Scope
The CRA defines economic operators in Article 3(12). These are the entities that bear the risk associated with the CRA. This includes the entire supply chain: manufacturers, authorized representatives, importers, and distributors. Towards the end of the CRA development, the concept of open-source software (OSS) stewards Article 3(14) was included. OSS Stewards the a different set of obligations under the CRA. Ultimately, it is the manufacturer’s responsibility when incorporating OSS into their products; however, OSS stewards can assist in this effort.
Timeline
The CRA entered into force on December 11, 2024, and provides for a three-year transition phase wherein manufacturers can plan for adoption. In addition, CEN-CENELEC-ESTI are developing standards to support the adoption of the CRA. Critical timelines are shown below. Full enforcement begins on December 11, 2027.
CRA Adoption Timeline
Product Classes
There are three general classes for the CRA, and those are based on product risk: General, Important, and Critical.
Notice that one product can fall into different categories based on its use case. A notable example is the door lock use case from before. When installed residentially, it falls under the General class. When installed in a government facility or a piece of critical infrastructure, it would be an Important (Class II) device.
Class | Description | Examples (not-exhaustive) |
|---|---|---|
General | Low-risk PDEs. | Consumer smart door lock not connected to alarm monitoring. Smart thermostat. |
Critical - Class I | Moderate risk; | Consumer smart door lock in a home when connected to a remote alarm system or monitor. |
Critical - Class II | Direct cyber impact; | Smart door locks in a commercial building. |
Critical | Core to essential services; | Smart door locks in power plants, airports, or hospitals controlling access to critical areas. |
This image illustrates how to derive the assessment type for a product based on its identified class.
CRA Product classes and assessment requirements
Standards development
The EU CRA defines the law. As with other directives, harmonized standards provide assistance with the “how” to meet the law.
Harmonized standards, commonly known as EN (Europäische Norm) standards, create a common framework for technical specifications within the European Union. Conforming to these EN standards facilitates free trade and ensures a level playing field within all EU member countries. These standards guide businesses on how to meet a regulation or directive.
As of this document’s writing, harmonized (EN) standards are currently under development by CEN, CENELEC, and ESTI. These standards are grouped like this:
Annexes I and II are required across all verticals. The different Verticals are then classified by risk.
Currently, the following groups are working on these standards
CEN-CLC / JTC 13 WG 9 - Special Working Group on Cyber Resilience Act
Horizontally Aligned Standards:
Principles for cyber resilience
Generic Security Requirements
Vulnerability Handling
CEN-TC / 224 – Personal identification and related personal devices with secure element, systems, operations, and privacy in a multi-sectoral environment
Identity management systems and privileged access management software and hardware, including authentication and access control readers, including biometric readers
Hardware Devices with Security Boxes
CLC/TC 65x - Industrial-process measurement, control, and automation
Mapping EN IEC 62443-4-2 to the CRA
CEN-CLC/JTC 13 WG 6
Smart meter gateways with smart metering systems
Hypervisors and container runtime systems that support virtualized execution of operating systems and similar environments
CLC/TC 47X - Semiconductors and Trusted Chips Implementation
Tamper-resistant microprocessors/microcontrollers
Microprocessors/microcontrollers with security-related functions
ASIC or FPGA security-related functionalities
Smartcards or similar devices, including secure elements
The timeline for implementation is as follows
What are the obligations?
Economic operators have different obligations depending on who they are in the supply chain.
Manufacturers
Articles 13 and 14 target manufacturers and they are crucial in meeting the CRA. Both hardware and software sold into the EU must:
Establish cybersecurity into the entire product lifecycle. This starts at ideation and ends at field decommissioning of the product.
Perform a conformity assessment to verify that the requirements of the CRA are met
Create and maintain documentation, both non-technical and technical, and include key cybersecurity instructions for users.
After the product enters the market, the manufacturer must monitor product compliance, notify of cybersecurity incidents, and manage the vulnerability.
Importers
Importers are obligated to ensure that the imported product meets the CRA. They are required to verify that the technical documentation is complete and that the manufacturer has completed the appropriate assessment.
Distributors
Per Article 20 (2) (b), distributors are obliged to verify the CE mark and CRA compliance.
OSS Stewards
Looser standards were established for OSS Stewards in Article 24:
Documentation on how to apply the software in a secure product and how to effectively handle vulnerabilities.
Establish a means to report vulnerabilities as per Article 15, Article 14(1), Article 14(3), and Article 14(8).
What can be done now
Before December 11, 2027, products brought into the market required no modifications. However, product design lifecycles take time. Therefore, the earlier a manufacturer begins developing the internal procedures required by the CRA, the smoother the transition.
In addition, any product brought into the market after December 11, 2027, must meet the CRA. Therefore, it is critical to assess what market exposure will exist and begin evaluating and possibly re-designing products to meet the new regulations.
Companies should:
Set up a cybersecurity assessment framework
Set up a cybersecurity incident notification process
Set up a cybersecurity incident resolution process
Determine what SKUs the CRA applies to
Classify the SKUs into the non-critical, important, or critical categories.
Determine what product shortfalls exist
Implement compliance measures and project plans to address the shortfalls
Manufacturers should evaluate their individual use cases and situations to identify any missing steps for CRA compliance. This should include following the development of the harmonized standards for their product classes and verticals. Additionally, budgeting for compliance assessment through the Conformity Assessment Bodies outlined by member states would be prudent.
How can Keyfactor help?
The CRA places significant responsibility on manufacturers and software providers to ensure end-to-end cybersecurity, from initial design through deployment, maintenance, and eventual decommissioning. While the regulation does not mandate specific technologies, a well-implemented Public Key Infrastructure (PKI) and digital signing strategy are essential to meeting many of its core requirements, including trusted device identity, software authenticity, secure software update delivery, and lifecycle monitoring.
To support CRA compliance efforts, we have outlined key areas and guides where Keyfactor technology can play a critical role:
These guides map to specific CRA obligations and offer practical guidance for integrating security best practices throughout the product lifecycle. By using Keyfactor’s tools and resources, teams can implement the necessary controls to meet CRA requirements and strengthen the overall security and resilience of connected products.
Conclusions
The EU Cyber Resilience Act (CRA) marks a significant shift in how cybersecurity is regulated for connected devices and digital services. It introduces a comprehensive set of obligations for manufacturers, importers, distributors, and software maintainers, emphasizing security throughout the entire product lifecycle.
This guide outlines key requirements, risk classifications, affected product types, and upcoming enforcement timelines. While the regulation is broad and non-prescriptive, it expects strong, proactive measures such as secure software updates, device identity management, and continuous identity lifecycle monitoring, areas where Public Key Infrastructure (PKI) and digital signing are critical.
Understanding the CRA and its implications now, organizations can take the necessary steps to assess product exposure, align internal processes, and adopt the right technical foundations for compliance.
Related Content
Complementary Solution Areas and Guides
Contact us
Request a live demo with one of our experts — whether you want to explore workflows hands-on or discuss your specific needs.