Vertical Summary - EU CRA
The EU CRA Summary Overview
Overview
The rapid popularity of connected devices has opened up new attack vectors into privacy, safety, and security for individuals and organizations. The EU Cyber Resilience Act (CRA) is a regulatory framework to address cybersecurity concerns associated with these devices and services provided.
The goal of this document is to educate about the CRA as Keyfactor sees it. This is not meant as a legal representation of the CRA, and does not cover every possible interpretation. It is up to the individual organizations that fall under the CRA to evaluate this against their current or future product offerings.
The goal of this framework is to have manufacturers, distributors, importers and the like be responsible for:
Assess and document 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
Perform a conformity assessment before the device is sold into the European Union. This is required for the CE mark.
Monitor, report, and correct 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 proceeding fiscal year.
Failure to comply with other Articles have other financial impacts, with the absolute minimum non-compliance penalty as € 5 000 000
As in most regulations, the CRA is not prescriptive. So, how a manufacturer meets these goals is not defined.
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 |
Scopes
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, in as far 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 11-Dec-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 11-Dec-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 use case. When installed in a government facility or a piece of critical infrastructure would be a Important (Class II) device.
Class | Description | Examples (not-exhaustive) |
|---|---|---|
General | All PEDs not listed in Annex III or IV. Must meet essential cybersecurity requirements (Annex I). Self-assessment is possible | Smart light bulbs, home thermostats, webcams, general-purpose mobile or desktop apps. Not installed in Critical Infrastructure or the like. |
Important - Class I | Products with moderate cybersecurity risk or indirect impact on other systems. Third-party assessment required if harmonized standards or EUCC not used | VPN software, operating systems, biometric readers, consumer routers, SIEM software, smart toys. |
Important - Class II | Products with direct, central cybersecurity functionality. Always require third-party conformity assessment, regardless of standards used | PKI systems, certificate authorities (CA) software, digital signing servers, firewalls, IDS/IPS, hypervisors, tamper-resistant hardware. |
Critical | Core to essential services (per NIS2). May require mandatory EU cybersecurity certification (EUCC) at "substantial" or "high" level if designated by the Commission. | Secure cryptoprocessors, HSMs, smart meter gateways, secure elements, security tokens, smartcards. |
Here is the concept visually

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 provide guidance to businesses as to 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

Standards Under Development
Annexes I and II are required across all verticals. The different Verticals a 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 sectorial 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
Distributors are obliged to verify the CE mark and CRA compliance per Article 20(2)(b).
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 11-Dec-2027, products brought into the market require no modifications. However, product design lifecycles take time. Therefore the earlier that a manufacturer begins developing the internal procedures required by the CRA, the smoother the transition.
In addition, any product brought into the market after 11-Dec-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.