Does CRA apply to your product? Product functions, boundaries, and components.
Cyber Resilience Act (CRA) (Regulation (EU) 2024/2847) is gradually coming into effect this year and all requirements in 2027. This blog post starts a series to discuss what CRA means for software and hardware product R&D work.
When CRA applies
There are three criteria when CRA applies to your product or project:
It exchanges digitally encoded data over any interface
It is not free and open source software (FOSS) excluded from CRA
It is not in sector already covered by other regulation
Three conditions when CRA applies to your Product.
CRA will be widely applied for products in the EU market. However, it does not apply to products which fall under other regulations. For example, devices covered by medical-sector regulation and products developed exclusively for the military. As a rule of thumb, unless you know your domain is excluded, it is likely included.
CRA encompasses all products which can send or receive digitally encoded data over a connection. So, if you send or receive data, updates, etc. over a connection, then CRA applies. The connection can be over the Internet, intranet, wired networks, wireless networks, USB cables, etc.
The conditions when FOSS is excluded from CRA requirements are quite complex, see e.g. Recital 15 and 18 and definitions in Article 3. The basic idea is that if your software is freely downloadable and usable without a fee and you do not monetize it e.g. by services, then CRA should not apply. But if you charge for software, hardware running it, services, support, etc. then CRA applies. You should also familiarize yourself with the CRA concept of FOSS stewards in Article 24, if you are working with open source.
The intended purpose and product function
For CRA, you must define the intended purpose of your product, its core functionality, and its essential functions. This information together with identified risks determine the level of security required from your product and the rigor of security review and testing.
The core functionality is the product's main features and technical capabilities without which it would not be able to meet its intended purpose. A product has exactly one core functionality for the purposes of CRA classification. Products typically do more than just their core functionality, but those additional functions are ancillary and do not change the classification. Depending on the core functionality your product may be categorized as default, important class I, important class II, or critical, see CRA Annex III and IV.
On other hand, essential functions are the functions your product provides to the user as experienced by them, and functions that support the product's performance. You must protect the availability of essential and basic functions even after a security incident. CRA does not provide precise separate definitions for essential and basic functions, but for example, in a smart lock product, locking and unlocking could be essential functions and managing keys a basic function.
Product boundaries
Entities in your product and its environment can be categorized to three types:
Software and hardware which is part of your product
Components which you embed into the product, but are developed by someone else
External environment, especially the dependencies which your product uses, but are not in your direct control.
Software and hardware which is part of your product — this is everything you design, develop, and produce under your own responsibility: your code, your firmware, your hardware, and any remote data processing solutions you build and operate to support the product's functions. You are responsible for implementing the CRA essential requirements across all of it.
Components which you embed into the product, but are developed by someone else — these are third-party libraries, firmware, hardware chips, or cloud services that you integrate into your product. CRA requires you to exercise due diligence: identify what security properties you need from the components, verify that components meet those needs, and address any gaps through mitigations.
Dependencies which your product uses are considered part of the external environment. These are external networks, infrastructure, services, or environments that your product interacts with, such as a cellular network or a user's local network. You do not have the level of access to dependencies as you have to your code or components, but you must still identify the risks they pose to your product and address those risks through your own product design, for example by authenticating remote commands or ensuring that a network outage does not push your product into an insecure state.
