What does the CRA (cyber resilience act) apply to? Is my device or software solution affected?
The CRA (Cyber Resilience Act), coming into full effect on the 11th of December 2027, has a very wide-reaching scope. In this article we will explore some of the key definitions of the CRA, to understand what products it applies to.
Background: What does the CRA aim to achieve?
Before we step into that, let’s set the stage, and investigate what the CRA aims to achieve. This direct quote from the full legal text of the CRA is helpful:
“Under certain conditions, all products with digital elements integrated in or connected to a larger electronic information system can serve as an attack vector for malicious actors.
As a result, even hardware and software considered to be less critical can facilitate the initial compromise of a device or network, enabling malicious actors to gain privileged access to a system or to move laterally across systems. Manufacturers should therefore ensure that all products with digital elements are designed and developed in accordance with the essential cybersecurity requirements laid down in this Regulation.
That obligation relates to both products that can be connected physically via hardware interfaces and products that are connected logically, such as via network sockets, pipes, files, application programming interfaces or any other types of software interface.”
In other words: products which are able to connect to other products can have a significant security impact on them. The products with a direct security impact could also be software products!
As a current example, consider OpenCLAW. OpenCLAW is an agentic AI system which is allowed full access to the computer it runs on. The data and control planes in OpenCLAW are intermixed, making OpenCLAW vulnerable to well-known prompt injection attacks.
As a result, even if the computer and its operating system are designed in a secure way – including firewalls, virus scanners, etc., OpenCLAW might divulge essential credentials stored on your computer to a malicious attacker. These credentials in turn could be used as an entry gateway to attack other systems connected on the same network.
The whole system can therefore fail because of one weak chain in the link. The CRA thus extends very broadly, trying to cover every such link in the chain. Threats to the users, their networks and secrets are going to be reduced by products compliant with the CRA.
The scope of the CRA
Article 2(1) Regulation (EU) 2024/2847 (known as the “Cyber Resilience Act” or “CRA”) is the central scope provision of the CRA:
„This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.”
There are three things to unpack here:
- Products with digital elements
- Made available on the market
- Intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.
All three must apply, for the product to fall under the CRA.
At the end of the article, we will also discuss some exceptions. These exceptions, however, typically have other restrictive regulations apply to them.
What are products with digital elements?
Article 3(1) of the CRA 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;”
Hardware products are defined by the CRA as “physical electronic information systems or parts thereof, which are capable of processing, storing or transmitting digital data”. This obviously applies to anything which has a CPU, such as single board computers, but also, for example, storage devices, such as microSD cards and equipment such as network switches.
A counter-example might be helpful: an analog thermostat uses analog mechanisms for temperature regulation. It does not process, store or transmit data, and thus does not fulfill the definition of a hardware product with digital elements. However, let’s look at the case of a digital temperature sensor which transmits the data using I2C. Due to the transmission of the data, and also processing to prepare it, it falls under this definition of hardware products, which the CRA could apply to, if the other conditions are met.
Please note that software products are also directly included in the definition of products with digital elements. Do you develop software, and are unsure about its classification under the CRA? You can inquire with us, to get clarity and understand if the CRA applies to your specific case.
The “remote data processing solutions” refer to cloud processing. There are some limitations to what falls under the CRA for that. A local product – hardware or software – is always needed, which interacts with the cloud. The cloud processing solutions need to be developed by the manufacturer of that local product, or under the responsibility of that manufacturer. If you create and consume your own APIs, or if you have another company design cloud APIs to your specification, they very likely fall under the CRA.
However, if you consume public or private cloud APIs of a vendor offering their service to the broader public, such as AWS, their cloud parts will not fall under your CRA certification.
It is, of course, still good practice to do a risk assessment of these APIs, and design your software to fail gracefully, including decoupling of key functionalities from these cloud vendors.
Finally, the cloud API needs to be an integral part of the product’s functionality. This is defined as “the absence of which would prevent the product with digital elements from performing one of its functions “.
For example, if you are using cloud APIs to simply track usage patterns on your devices, the cloud part of your software will not become part of the CRA requirements, including detailed technical documentation, etc. You will, however, still do risk assessment for the device part calling the cloud API, including documentation on how attack vectors are minimized.
Another interesting aspect of the definition of products with digital elements is the explicit mention of the components.
In case you provide components – for example software applications which can be integrated into other systems (e.g. bootloaders, BIOS, virus scanners, commercial word processors), or hardware components such as memory, SoCs, single board computers, etc., these fall under the CRA. You will have to prepare the technical documentation, and everything else which is required under the CRA certification. If you are still confused whether your product falls under this definition of “product with digital elements”, you can reach out to us, we will help you classify it under the CRA.
What does “made available on the market” mean?
The CRA Article 3 (Definitions) clarifies in (22) what this means:
“‘making available on the market’ means the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge; “
Whether you are someone who manufactures, imports, or resells products with digital elements (including software), you are responsible. You need to ensure that the products you are dealing with comply with the CE, and as part of the CE, also the CRA.
This will bring all kinds of interesting developments – for example, by uploading your app to an app store, international vendors will become responsible under the new CRA law. App marketplaces therefore might offer to restrict which countries you make your app available in.
One other interesting aspect of this is the wording – “in the course of a commercial activity, whether in return for payment or free of charge.”
This covers alternative business models, like hardware which is only rented to users not sold. A famous example for this was Xerox, which rented out their copiers to companies, charging per page, instead of selling the copiers outright. A new development in this vein is Robotics-as-a-Service (RaaS) for equipment like warehouse robots, autonomous forklifts, and inspection robots.
Other models covered are subscription payments for software which is installed locally, but, surprising to many, also completely free software which is a conduit for consulting services.
For example, Red Hat provides open-source software to enterprises, which is based on Linux. They have even acquired several proprietary software products, and released such software under open-source licenses. However, they do this with commercial intent – for example they offer subscription-based customer support, and they also offer integration and training services. Since the software is an enabler to these commercial activities, it falls under the CRA regulation.
What about making free hardware availabe on the market as part of a commercial activity? Of course: yes. For example, ISPs provide free routers, to be able to sell their broadband services. The routers fall under the CRA, as the ISP is carrying out a commercial activity from which it benefits, enabled by these routers provided to customers.
Briefly: any for-profit company which commercially benefits from releasing its products on the European market, in whatever way, will have to ensure that these products comply with the CRA.
Open-source software has a special status, in case it is not created with commercial intent. For example, the Document Foundation supports the Libre Office suite. However, they do not do this with commercial (profit) intent. It is a non-profit organization. They collect donations, in order to cover their operating costs.
We are focused on CRA support for the embedded and Linux market, which traditionally heavily relies on open-source solutions. As such, we can advise you what to pay attention to, in the case of open-source software, and elaborate on concepts like “Open-source software steward”. Reach out to us.
CC-BY 3.0 Josh Hunter / 500px – Raleigh headquarters of Red Hat – Red Hat Tower
“Placing on the market” refers to the first making available of a product with digital elements on the Union market. This is very relevant for applicability of the CRA to already produced products.
Briefly: if a European manufacturer sells a non-CRA-compliant batch of products (“places them on the market”) to a European distributor before the deadline (11th of December 2027), the distributor can continue to sell that batch of products, until they are all sold off. Further products the manufacturer produces after the deadline, will have to comply with the CRA.
What does “intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network” mean?
This is the main reason your product might not fall under the CRA, and needs to be carefully checked.
A dishwasher, for example, is a product with digital elements (a microcontroller which controls the dishwasher, and its firmware). It is also made available on the Union market (in European countries) – for example sold through Amazon, Media Markt, or via other routes.
However, typically it will not have data connections to other devices or networks. It is a standalone device, which just needs power and water connections to operate. It does not need to fulfill CRA requirements, even if some of its components might need to, like the microcontroller itself.
A more expensive dishwasher which can be controlled via Bluetooth, or can automatically reorder dishwasher tabs for you using an Internet connection, will fall under the CRA.
There are some important aspects to the wording, which I would like to unpack further:
- Intended purpose or reasonably foreseeable use
Specifically, the CRA defines reasonably foreseeable use as use, “which is likely to result from reasonably foreseeable human behaviour or technical operations or interactions “.
This means – even if you as a manufacturer do not directly intend for the device to connect to other devices, but your customers might connect the devices (“there’s a functional LAN port on it”), your device still falls under CRA.
Of course, this is true as well, if you are keeping this option open for later, or for servicing the device, or other infrequent use.
As an example, the company Cabolo designs a device to transcribe audio, specifically designed for offline usage. Sounds like the dishwasher we discussed, right? However, their device also has a possibility to connect it to networks. After all, it is based on the popular NUC compute form factor. Users could potentially connect it to access files using the network, add software updates, or remotely access website interfaces which the Cabolo solution might host. Users might also try to connect Bluetooth microphones to the Cabolo box.
As a side note, Cabolo’s AV system is also designed to be interoperable with the protocol DANTE, which is a low-latency digital protocol run over Ethernet links. This makes it clearly fall under CRA, without any need for interpretation of possible usage scenarios.
Reasonably foreseeable human behavior however excludes hardware enthusiasts (“hackers”) who might try to connect to a standalone device, for example in the famous case of the first IoT device in the world – an Internet connected toaster.
- direct or indirect logical or physical data connection
This is an important core aspect of the CRA and best explained with some examples:
A physical data connection could be many different types: an Ethernet link, a Bluetooth connection, or a USB connection, but also many others.
For example, a USB printer connecting to your computer, makes both the printer and the computer fall under the CRA. Not every computer will have a USB printer connected to it, but it is an expected behavior for general purpose computers – some users will do it. Remember the “reasonably foreseeable human behavior”?
The actual physical implementation of the data connection does not matter: „‘physical connection’ means a connection between electronic information systems or components implemented using physical means, including through electrical, optical or mechanical interfaces, wires or radio waves;“
Even products without an Internet connection in isolated environments, for example in industrial settings, will typically connect to an industrial fieldbus. An example is a PROFIBUS network connecting sensors to a PLC. This comprises a physical data connection, which then triggers the requirement for CRA compliance, to be able to obtain the CE mark for your product.
Another important example in this context is the smart door lock with an NFC tag used to unlock it – both fall under the CRA, due to the data being exchanged through the wireless NFC interface. In this case, cyber security is directly relevant to physical access, for example to a hotel room with your private belongings.
If you are confused, whether the type of connection your device has comprises a data connection under the CRA regulation, you can get in touch with us for an analysis of your device.
A “’logical connection’ means a virtual representation of a data connection implemented through a software interface; “
For example, this could be a VPN software interface, through which you connect to a different network. Not every bit transmitted on the hardware interface can reach that different network and the devices in it, only the ones transmitted through the specific VPN interface.
Other examples include MQTT connections, REST API endpoints, OPC UA interfaces (relevant for industrial automation), WebSocket Interfaces, Bluetooth GATT Services, and more.
It could be argued that every logical connection fundamentally requires a physical connection as underlying transport.
The CRA cares about the distinction, because we are interested in identifying attack surfaces. As each logical connection offers a different attack vector, it is useful to include them in the documentation and security assessment as separate attack surfaces.
When looking at a device, as a manufacturer of that device, local inter-process communication (Unix sockets, D-Bus, named pipes, shared memory APIs) can be considered a logical connection as well. They might be relevant for security assessment, but do not automatically trigger the CRA, as they are not connections to a separate network or device, but rather connections within the device manufactured by you.
However, if you look at individual software components in the device, these logical connections would trigger the CRA, in case the software is placed on the market separately.
Direct connection examples:
- A high-speed trader FPGA implementation connected to an Ethernet port (a direct physical connection)
- A web browser using the https protocol to access websites (a direct logical connection)
- An email client establishing an IMAP session to download emails (a direct logical connection)
- An operating system providing DNS host name resolution services and automatically downloading updates
- A headphone playing music using a Bluetooth connection
- A USB flash drive being plugged into a computer, to access data on it.
They are what we typically would identify as actively communicating hardware devices and software applications, and will probably be obvious to most readers. Active data exchange is happening here.
What are “indirect” connections?
These are the more surprising connection types, since they don’t look “connected” at first glance.
“‘indirect connection’ means a connection to a device or network, which does not take place directly but rather as part of a larger system that is directly connectable to such device or network; “
Concrete examples include:
- A text editor running on an Android smartphone, which does not use network connections or cloud functionality in any way
- A standalone calculator application running on Microsoft Windows.
In other words, can your base operating system, or device, connect to other devices, or networks? Then all software which runs, or could run on such a system, falls under the CRA. This is a very broad definition which covers all Android and iOS application software.
The background of this will become clear by keeping the security aspects of the CRA front and center, and by looking at some historical ways attackers were able to execute code remotely, and ultimately gained access to higher system privileges.
An example for this was the GDI+ JPEG vulnerability in 2004 and 2005 (MS04-028). This was a heap buffer overflow in Microsoft’s Graphics Device Interface (gdiplus.dll).
Users opening a website with a malicious JPEG file allowed attackers to execute arbitrary code with user privileges. For example, a Trojan downloader, which would then install adware, spyware and backdoor access tools. Also, these corrupted JPEGs were embedded into Microsoft Word documents and Excel sheets, and mailed to defense contractors, government agencies, and corporate executives, in a technique called spear-phishing. Naturally, with malicious intent.
A modern equivalent is the 2023 WebP heap buffer overflow vulnerability, which was widely exploited to deploy spyware to high-profile targets, journalists and politicians.
These software components were not designed to interact with the network directly. They are not web-browsers, e-mail applications, or VPN gateways. However, since they are indirectly accessible from the network, they impact the security of the whole system. Therefore, the CRA regulates them.
In summary, most devices connecting to other devices – whether in the form of networks, or other connections, Internet connections, local connections, Bluetooth, or NFC – fall under the CRA.
The software running on such devices also directly falls under the CRA, if it is sold separately as a component. This is the case, for example, in app stores, and in other ways software products are available on the European Union market (“made available on the market”).
The same is true for individual hardware components, which process, transmit or store digital data. For example, sensors, SoCs, memory components. All of them will need to be certified under the CRA, in order to be CE-certifiable.
Do you have doubts, whether the CRA applies to your product? We will be happy to look at your particular product / situation, and give you a first indicative assessment. Get in touch with us here.
Exceptions
To finish this article off, let us explore some situations where the CRA does not apply. Let’s take cases and situations outside of the scope of the CRA first, and then discuss the exceptions the CRA legal text defines separately.
The CRA does not apply in the following cases:
- In case there are no digital elements – no digital data being processed, stored or transmitted.
- This would be the case for analog wristwatches, for example.
- In case the device / solution is not being made available on the EU market (yet).
- If the hardware is being manufactured in the EU for sale exclusively outside the EU, no CRA certification is needed.
- If the hardware is a prototype, to be shown on exhibitions, and clearly marked as not CRA / CE certified
- If the software is an alpha-release for a limited time, strictly just to get testing feedback from users. It also needs a visible sign indicating that it does not comply with the CRA
- If the product is manufactured for one’s own internal use
- (open-source software is a mixed bag – contact us for more details)
- In case the solution is a purely cloud-based software / SaaS software (might however fall under NIS2), unless the software is developed by the same manufacturer as a standalone device or software, and its functionality is essential to a function of this device. (Think remote API)
- In case the device is a stand-alone hardware solution (which may, of course, integrate firmware), and has no connections with other devices or networks.
Some examples of the latter:
- The aforementioned dishwasher, with no capability to connect to other devices or networks
- A basic calculator with embedded firmware, with no capability to connect to other devices or networks
- An electronic toy with embedded firmware playing pre-recorded light and sound effects, but no capability to connect to other devices or networks
- A coffee machine with embedded firmware which has a control panel, but no capability to connect to other devices or networks
- An electric toothbrush with a wireless charging station, but with no capabilities to connect to other devices or networks.
If firmware for these devices is placed on the market separately, the CRA will likely apply to the firmware. The firmware might be used on a device which is connected to networks or other devices.
No grandfathering of products
The CRA does not have a concept of grandfathering. Individual units of products placed on the EU market need to comply with all regulations which are applicable at the date of placing them on the EU market.
Thus, the CRA does not apply to individual units of devices which are placed on the Union market before the deadline of the 11th of December 2027.
If a manufacturer continues to produce products of a certain type on or after the 11th of December 2027, they will need to be compliant with the CRA.
You have to be careful, even with products placed on the market before the deadline of the 11th of December 2027, though! If these devices are substantially modified, for example with firmware updates from the manufacturer, which unlock new functionalities, they will subsequently fall under the CRA. Even though they have been sold already.
Manufacturers have to be aware of this, and plan software updates, and their products accordingly. That is why we recommend to get acquainted with CRA requirements today, and prepare your hardware to be able to meet the requirements.
Talk to us to find out more, on how you can prepare. We can also help to support you with what you need to pay attention to in software updates.
The only exception for this is: unmodified spare parts can continue to be commercially available on the market beyond the deadline of 11th of December 2027. See further below for some more details on this.
Reporting obligations
One further point of note: there is no exceptions for reporting obligations. Manufacturers will need to fulfill them for all products, which would fall under the CRA (digital elements, made available in the EU, network / device connections).
Even if these products are sold before the deadline of the 11th of December 2027.
Our recommendation:
In order to find out whether the CRA applies to your product or not, determine first whether it has any possibility of connection with other networks or devices. If it does not, your product does not fall under the CRA. If it does, evaluate the other points carefully. Are you, or your partners, placing it on the EU market, as per the definition? Does it include digital elements?
You can contact us for some guidance and assistance with this process.
CRA Exceptions
Exceptions to the CRA are defined in the remainder of Article 2 (Scope) of the CRA legal text. Products with digital elements falling under the following legal acts are excepted from the CRA Regulation:
- Regulation (EU) 2017/745; (MDR – medical device regulation) – medical devices for human use, including medical software and accessories.
- Regulation (EU) 2017/746; (IVDR – in vitro diagnostic medical devices) – in vitro diagnostics diagnose specimens from the human body, for example pregnancy tests, but also instruments and software as related components.
- Regulation (EU) 2019/2144 (type-approval requirements for motor vehicles). – Vehicles and their systems and components
- Regulation (EU) No 168/2013 (approval and market surveillance of two- or three-wheel vehicles and quadricycles, with the exception of L1e category vehicles designed to pedal)
Further exceptions:
Products which have been certified in accordance with Regulation (EU) 2018/1139 (common rules in the field of civil aviation) are excepted. This Regulation refers to aeronautical products, parts and equipment. As background for this: The European Union Aviation Safety Agency (EASA) has integrated information security aspects into its certification rules, starting in 2020.
However, the majority of drones in the open category – leisure drones, low-risk commercial activities, whilst falling under the scope of this Regulation, are not certified under that Regulation. Therefore, they may still be covered by the CRA.
The same is true for components which are built into products certified under that Regulation, but which themselves are not certified under that Regulation. These components may be covered under the CRA, if they are made available on the market separately. Contact us for details.
Also excepted is equipment which falls within the scope of Directive 2014/90/EU (MED, directive on marine equipment for safer and less polluting equipment on EU ships).
An important distinction: this exception doesn’t apply automatically, if the target market is “boats”. Only if the equipment in question bears the MED marine wheel mark conformity symbol, it is excepted from the CRA. Generally, this is the case, if it is required under international maritime conventions (SOLAS, MARPOL, COLREG, etc.) and installed on ships within the Directive’s scope. Otherwise, for example for a hobbyist yacht GPS tracker, CRA would apply. Also, same as for Aviation, components which do not directly fall within the scope of that Directive may fall under the CRA.
Products with digital elements developed or modified exclusively for national security or defense purposes, or products specifically designed to process classified information are excepted. This exception does not apply to “dual use” goods, which also have civilian purposes, unless they have been modified exclusively for national security / defense purposes.
As already mentioned, spare parts are excepted, if they are made available on the market to replace identical components in products with digital elements, and they are manufactured to the same specifications as the components they are intended to replace.
This provision about the spare parts is intended to allow users to keep using the devices which are already on the market, even if they would not be CRA compliant anymore, should they have been released later on the market. It allows to prolong the lifetime of these legacy products.
Notes on some special regulatory situations and additional laws:
Machinery Regulation (MR, Regulation (EU) 2023/1230)
The Machinery Regulation will apply from the 20th of January 2027. It covers an assembly of interconnected parts with at least one moving part, powered by a source other than direct human effort, performing a specific application.
Heavily influenced by AI, robotics and cybersecurity concerns, this regulation already covers some aspects of cyber security. Machines falling under that regulation will additionally have to comply with the CRA fully.
Compliance with the cybersecurity requirements of only one of the Regulations can’t be considered to automatically fully satisfy the requirements of the other Regulation. Furthermore, if AI safety functions are involved, the machines may also fall under the AI Act.
RED – Radio Equipment Directive 2014/53/EU, Commission Delegated Regulation (EU) 2022/30
Starting from the 1st of August 2025, the RED Delegated Regulation, covering certain radio equipment placed on the market on or after 1st of August 2025, has several essential requirements on Cybersecurity.
To avoid overlaps with the CRA and ensure legal certainty, it is planned to repeal this Delegated Regulation (EU) 2022/30 on cybersecurity on the 11th of December 2027, once the Cyber Resilience Act becomes fully applicable.
Our services
We offer CRA compliance support services. We can help you with the choice of components, with assessment of the risk, and develop solutions for critical security challenges.
Our engineers can also work with you to prevent prompt injection attacks into your AI systems, to comply with the CRA.
Reach out to us to learn more about the CRA, and how to design products in a way which make them compliant with the CRA.
English 
Deutsch (Sie)