Skip to main content
Skip table of contents

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

image-20250321-183342.png

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

image-20250321-182425.png

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

image-20250321-190348.png

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

image-20250321-193604.png

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.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.