Cyber Resilience Act 2026 guide for IoT devices

There is a running joke saying that ‘S’ in ‘IoT’ stands for ‘Security’. While it is unfair to generalize this in such a way. It does not take into account well-designed projects and software engineers putting every effort to provide best possible solutions for their customers.

It is true that, due to the previous lack of imposed common regulations, users of IoT products might not have always felt confidence in the security of the products. This did not necessarily mean the products themselves were insecure. There were simply no widely adopted standards to address these issues.

Fortunately for customers, the situation is evolving. Over the past few years, several new regulations have been prepared. One of them, which we focus on here, is the Cyber Resilience Act.

What is Cyber Resilience Act?

The Regulation (EU) 2024/2847, widely known as the Cyber Resilience Act (CRA), is a new regulatory framework. It applies to products with digital elements, including both hardware and software, on the EU market.

Its main objective is to strengthen the approach regarding cybersecurity standards. And also help users take into account cybersecurity features when buying or using products that can be connected to other devices or networks.

The CRA requires a security-by-design approach. This allows manufacturers to address potential threats early. Consequently, products remain safe during normal use and even ‘foreseeable misuse’.

Furthermore, the CRA defines the roles and responsibilities of ‘economic operators’. These include manufacturers, authorised representatives, importers, and distributors. The regulation specifies who falls into each category. It also outlines the specific tasks and responsibilities assigned to every role.

Cyber Resilience Act timeline

The Cyber Resilience Act follows a phased implementation schedule. The image below illustrates the key milestones for manufacturers and operators. While the regulation entered into force in late 2024, the most critical deadlines are still ahead.

Specifically, reporting obligations for vulnerabilities will begin on September 11, 2026. By December 11, 2027, all products on the EU market must fully comply with the act. Please refer to the graphic for a detailed breakdown of these transition periods.

Counting down to Cyber Resilience Act compliance

00Days
00Hours

When does the given product fall under CRA?

Three main elements determine if a product falls under the Cyber Resilience Act:

Product Type: It must be a “product with digital elements.” This includes software, hardware, and remote data processing solutions.
Market Presence: The product or its components must be available on the EU market.
Connectivity: Its intended purpose (or foreseeable misuse) must involve a logical or physical data connection. This applies to both direct and indirect connections to devices or networks.

For example – a dishwasher with embedded firmware might not fall under the CRA. This applies if the device cannot connect to other networks or devices.

Are you unsure whether your product is subject to CRA?

Who is exempt from the Cyber Resilience Act?

Apart from these rules there are some exemptions:

Timeline: The CRA does not apply to products marketed before December 11, 2027. unless a substantial modification is performed. However, reporting obligations still apply (specified in Article 14 of the Cyber Resilience Act). If a product undergoes a substantial modification, it must then comply.
Personal Use: Products manufactured solely for one’s own use are exempt. Such cases are not considered as “placing on the market.
Unfinished products: These may be marketed temporarily for testing purposes only. They must display a visible sign indicating non-compliance.
Security and defence: Products developed exclusively for national security or defence are exempt. This also includes devices designed for processing classified information.

Products covered by other regulations

The CRA does not apply to products already regulated by specific EU frameworks, such as:

Medical Devices: Products under Regulations (EU) 2017/745 and 2017/746.
Automotive: Motor vehicles and trailers under Regulation (EU) 2019/2144.
Aviation: Civil aviation products certified under Regulation (EU) 2018/1139.
Marine: Equipment falling within the scope of Directive 2014/90/EU.
Light Vehicles: Two- or three-wheel vehicles (Regulation (EU) No 168/2013), excluding certain pedal-assisted L1e category vehicles.

How does the Cyber Resilience Act affect IoT devices?

The Cyber Resilience Act will significantly change the IoT landscape. It is meant to improve the quality of IoT devices and ensure the users that they are safe to connect those devices to their networks.

The CRA obliges manufacturers to treat security as a core foundation. Security must be an essential priority, not just an afterthought or an added feature. These requirements extend beyond manufacturers. Every economic operator listed above has specific tasks to ensure product safety.

Below, we present key obligations imposed for specific operators. Please note that this list is not exhaustive. For full details, refer to the CRA legal text in our references section.

Manufacturers

Ensure that the product meets essential cybersecurity requirements
Perform cybersecurity risk assessment
Perform due diligence with regard to third-party components used in the product
Carry out conformity assessment procedure
Preparing Software Bill of Materials (SBOM)
Prepare EU declaration of conformity
Add CE mark to the product

Reporting obligations:

Submit notifications regarding security incidents and actively exploited vulnerabilities to the Computer Security Incident Response Team (CSIRT) of the Member State and to ENISA, keeping following deadlines:

- 24 hours – early warning notification
- 72 hours – main notification
- final report – no later than 14 days after corrective/mitigating measure is available for actively exploited vulnerabilities
- final report – one month from the 72h submission for severe incidents

It’s important to note here that reporting obligations include all the products with digital elements – including those that were already placed on the market before 11th of December 2027.

Importer

Ensuring that the manufacturer has complied with the cybersecurity requirements related to this product and is prepared with the processes to handle the obligations associated with vulnerabilities
Ensure that appropriate conformity assessment procedures have been carried out
Ensure that appropriate technical documentation has been prepared and that the product has the CE marking

Distributor

Verify that the products bears the CE marking. Check if manufacturers and importers have met their obligations – e.g. adding contact details on the product, enclosing the instructions and information regarding the support period

Open-source software steward

Must adopt a cybersecurity policy for developing secure products. They are responsible for proper vulnerability handling and reporting actively exploited threats. Additionally, they must cooperate with market surveillance authorities and take appropriate corrective actions. These duties apply to the extent of their involvement in the product development lifecycle.

It’s important to note, that open-source software stewards are not subject to penalties for infringement of the CRA

Cyber Resilience Act product classification

CRA classifies products into certain categories which determine their level of severity which in turn determines the possible paths that might be taken to assess their conformity.

Default category of products: e.g. memory chips, mobile apps, smart speakers, computer games.
Important products class I: e.g. password managers, operating systems, routers, modems intended for connection to the internet, switches, microprocessors/microcontrollers with security-related functions, smart home products with security functionalities (e.g. smart door locks, security cameras).
Important products class II: e.g. hypervisors, container runtime systems supporting virtualised execution of operating systems, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors/microcontrollers.
Critical products: e.g. hardware devices with security boxes, smart meter gateways within smart metering systems, smartcards or similar devices including secure elements.

Book a technical consultation!

Conformity assessment procedures for Cyber Resilience Act

Conformity assessment is a procedure implemented by the manufacturer demonstrating compliance of the product with digital elements with CRA.

Cyber Resilience Act gives few options in regard to the choice of the procedure used to demonstrate the conformity with this regulation:

Module A – conformity based on internal control (Annex VIII, Part I and Part II)
Module B+C – EU-type examination (Annex VIII, Part II and Part III)
Module H – conformity based on full quality assurance (Annex VIII, Part IV)

Module A

Conformity assessment procedure in which manufacturer performs verification of the compatibility with essential requirements of CRA and declares compliance oneself on its sole responsibility. This procedure does not involve any notified body.

Product categories which are allowed to use this path:

default category of products (not belonging to important or critical products),
important products of class I for which harmonised standards (explained below) were applied (Article 32[2]),
important products of class I and II if they are free and open-source and technical documentation is publicly available.

Module B+C

Conformity assessment procedure in which the manufacturer performs verification of the compatibility with essential requirements of CRA and declares compliance with notified body examining the design development.

Module H

Conformity assessment procedure in which the manufacturer implements a full quality control system ensuring that the products comply with essential requirements both in design and the production phase. The notified body examines the performance of the quality control system with periodical tests and checks. The manufacturer declares compliance with CRA before placing the product on the market.

This module is intended specifically for manufacturers placing a number of different types of important/critical products on the market, as it offers a more holistic approach with regard to assessing compliance with CRA.

Modules B+C or H are mandatory for following categories of products:

Important products class I – when harmonised standard has not been applied
Important products class II
Critical products (unless European cybersecurity certification scheme is made mandatory in future)

Essential cybersecurity requirements

The most important technical requirements from the CRA are listed in the Annex I Part I to the legal text of this regulation [1]. Example points from this list are presented below:

‘(...) products with digital elements shall:

(...)

(d) ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access;

(e) protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means;

(f) protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions;’

As you can see, those requirements are a bit vague and don’t give any specific technical confines on the design of your product. Consequently, translating essential cybersecurity requirements into detailed technical specifications becomes a task for harmonised standards. These are intended to support manufacturers in the implementation of those requirements in their product.

Furthermore, products that are compliant with harmonised standards benefit from a presumption of conformity with the CRA. To facilitate this, the European Commission has adopted a request [4] for a set of 41 standards which will support the implementation of the Cyber Resilience Act.

Unfortunately, they are not ready yet. In fact, the deadline for adoption for most of these standards is set to Q3/Q4 2026 (full list available in [4]). In the meantime, ENISA has released a study in support of the standardisation efforts, which analyses the most relevant existing cybersecurity standards and identifies gaps that need to be addressed [5].

Ultimately, you can use this document and the listed standards to understand the requirements better. By doing so, you can get on the right track and be better prepared for when the relevant harmonised standards are finally defined.

How to make a step towards compliance?

Even though the requirements in the Cyber Resilience Act are not directly translated into strict technical terms yet, there are widely accepted design patterns and features that can make your application safer – which refer to the requirements defined in the CRA. A really good analysis on this topic has been performed in Secure-by-Design Handbook [6].

Secure boot – security mechanism intended to assure integrity of the device’s firmware, preventing unauthorized code to run on the device. It is based on the root of trust – public key programmed into OTP (One-Time-Programmable) memory which corresponds to private key used to sign the bootloader. After the first bootloader is confirmed to be authentic it verifies the signature of the next component and the process continues until the main application is running. If at any point it will fail to verify the signature the boot is halted
Secure OTA – this mechanism assumes signing firmware with a private key. Corresponding public key is provisioned to every device. Once the device gets the update the bootloader is able to verify the signature and determine if the update needs to be rejected.
Flash encryption – converting the contents of the flash memory to unreadable format storing the key in OTP memory. CPU is able to decrypt the instructions read from flash using this key, but the flash content is not possible to be read for the outside world
TLS – Transport Layer Security – protocol that aims to support ensuring confidentiality, authentication and integrity in the communication between devices or programs. It uses X.509 certificates to confirm the authenticity of the server and performs a TLS handshake to establish symmetric keys used in the communication. mTLS – mutual TLS – is the extended version which – apart from server authentication – involves also device authentication by verifying the client certificate

Penalties for non-compliance with Cyber Resilience Act

What happens if your product does not meet requirements of the Cyber Resilience Act? The consequences may be quite painful. Non-compliance with certain requirements from this regulation can be punishable with administrative fees that reach up to 15 000 000 € or (in case of undertakings) 2,5 % of yearly turn-over, whichever is higher.

The size of the fee is decided based on the nature of the infringement, its consequences and duration, whether administrative fees have already been applied to the same economic operator, and size and market share of the economic operator committing the infringement.

Talk to a Cyber Resilience Act expert

Summary

In this article we have presented the most important information regarding the Cyber Resilience Act, we have presented how to determine if your products falls under its scope, what roles and their obligations are defined by this regulation, how are the products classified, what paths can be followed to assess the products’ compliance and what may happen if your product is non-compliant. The amount of obligations and rules introduced by this regulation may be overwhelming but all these standards are introduced to make the products on the market better and safer.

If you would like to get to know more details about the Cyber Resilience Act, its requirements and implementation, we encourage you to take a look at the links in the references section – especially on the FAQ – you will probably find answers to a lot of your questions that may arise.