EU Cyber Resilience Act (CRA) Guide with Practical Tips

What a change! While there was little stirring in my environment while the consultations legislation was ongoing, on the day the EU CRA came into force, the web was buzzing! I write this blog post as the founder of an embedded software company, and I can tell you that I’ve never been a supporter of bureaucrats. However, such a regulation was needed, and in this case, it is hard to question its legitimacy.

It will change not only the EU market but also the global market. Setting standards is one of the few edges that the EU has left. However, at some point, it will be necessary to avoid overregulation. For example, with medical devices or drones, innovations could be created in the States, and new products would go there first.

The majority of Scythe’s projects are medical device software that has long had strict requirements. Although the EU CRA doesn’t include such products, this fact legitimizes my analysis of this topic. Scythe had the best practices for secure design and implementation before the European Union introduced this regulation.

What are you going to find in this analysis?

Get prepared for a substantial article and meaty, caloric analysis. We’re going to start with more high-level and formal things to get a nice background. You will get a definition of EU CRA, a product with digital components, and discover whether you should comply with this resolution.

Then, we will discuss the impact of the Resilience Act on the design and development phase. We will then proceed to the impact on the product’s life cycle. You will learn what to take care of at the beginning, in the middle, and after the product is released.

Finally, we will examine the actual requirements that the European Parliament puts on the manufacturers. It’s going to be my interpretation in simple English followed by examples.
Go grab a cup of your favorite drink. You will likely get back to it more than once.

For whom is this article?

I imagine that you – the person on the other side of the screen, are somehow involved in the development of a product with digital elements. You can be either the founder, CTO, Engineering Lead, Manager, or developer. All below this point applies to you regardless of your role in the development phase. I am not a lawyer so I am going to use the language of facts and examples.

I summarize this regulation for you to save you time.

 

What is the EU Cyber Resilience Act (CRA)?

The EU Cyber Resilience Act (CRA) is a regulation (specifically Regulation 2024/2847) introduced by the European Union Parliament to strengthen cybersecurity for digital products and services. It establishes certain requirements and legal obligations for hardware and software products throughout their development and lifecycle.

The regulation’s text is not secret. Anyone can read the Cyber Resilience Act at any time in the official journal. What’s nice is that there are high-quality translations, so for convenience, you can read it in your native language. Cyber Resilience Act auf Deutsch? No problem. You will find it here.

Whenever I can I will use references in parentheses to the original text in English.

 

 

Product Security – Why was EU CRA Introduced?

Cyber Security is not a cliche. In the regulation’s introduction (1) we can read that it’s one of the key challenges for the Union. The cyber threat exists for both State organizations and individual consumers. The risks span from national security, and private data theft to real physical harm on a real human. According to this publication, the estimated global annual cost of cybercrime was 5.5 trillion euros by 2021! Let’s go then with some examples of the cyberattacks.

 

Successful Cyberattacks Examples

In July 2023 in Poland, my homeland there was an attack on railroads. Trains stopped. Railroads are crucial infrastructure. In our conditions, railroads are used for example to transfer military supplies from the west to the east border. Cybersecurity attacks through exploited vulnerabilities can lead to supplies stuck in a decisive moment.

Now a recent example of cyberattack touching individuals. In January 2025 German company D-Trust provided an e-signing solution that had their users data stolen. It’s already a serious thing. According to the company that was the victim of this attack, the final results were not tragic and the stolen data was deleted, but imagine what chaos could have occurred if the attackers had compromised the functionality of the signatures.

It’s a tough task to list all kinds of cyber attacks that can happen and to enforce adequate cybersecurity properties through Cyber Resilience Act regulation. That’s why it’s on hardware and software producers to perform risk assessments on their products! The number of successful cyberattacks will grow, but hopefully at a slower rate.

 

Who Needs to Comply with the CRA?

The first thing that hardware and software producers should do is verify whether their products fall under the Cyber Resilience Act. Let’s take a look at the original text.

EU Regulation 2024/2847 Article 2, paragraph 1

“1. 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.”

So the first question is what are products with digital elements? Let’s again take a look at CRA text:

EU Regulation 2024/2847 Article 3

‘(1) 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;

As you can read this definition is quite broad. We can distinguish here between:

• hardware products – this means any physical device, let it be wearable, smart home products, network equipment, or industrial machines that have digital elements. Basically, all smart devices fall into this definition;

• software products – it includes operating systems, security software, communication software, even video games or any data processing applications;

• remote data processing solutions – are solutions that are somehow integrated with hardware and software products explained above in a way that their absence would make the digital product unable to perform one of its functions (as stated in 2024/2847 Preamble (11)). It can mean API, databases, or services to perform some calculations.

So despite the exceptions that I will explain now, probably over 90% of hardware and software products that are available on the EU market would have to comply with this new regulation introduced in the European Union.

 

EU Cyber Resilience Act Exceptions

As stated in the 2024/2847 Preamble (18), open-source software projects are not subjects of EU CRA as long as those projects are not monetized or they are developed by non-profit organizations. The fact that open source software community/developer gets financial support or regularly releases their software doesn’t necessarily mean that it’s a commercial activity.

Moreover, according to the 2024/2847 Preamble (12), websites that do not facilitate the functionality of products with digital elements, as well as cloud services that are designed and developed independently of the manufacturer’s responsibility for such products, fall outside the scope of this regulation. Cloud services and their delivery models, including Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS), are instead governed by Directive (EU) 2022/2555.

Finally, in the 2024/2847 Article 2, paragraphs 2, 3, and 4 there are few directives specifically excluded as they already have strict requirements applying to some products with digital elements. Namely, they are:

• Regulation EU 2017/745 – Medical Devices Regulation (MDR). I already mentioned that medical device software development is my thing. If you develop such equipment and you’re now happy that the Cyber Resilience Act doesn’t bother you, I have to disappoint you and refer to our article on Medical Device Cybersecurity Requirements;

• Regulation EU 2017/746 – In-Vitro Diagnostic Medical Devices Regulation (IVDR);

• Regulation EU 2019/2144 – General Vehicle Safety Regulation (GSR);

• Regulation EU 2018/1139 – European Aviation Safety Regulation;

• Directive 2014/90/EU – Marine Equipment Directive (MED).

 

EU Cyber Resilience Act Exceptions

 

Hardware and Software Products Classes

Products with digital elements that fall under the EU Cyber Resilience Act are categorized based on their importance level, and potential harm, and therefore, cybersecurity requirements for all of them can differ. Without going into detail, let’s start with the most critical products.

Critical Class

Those are products with the most strict security requirements. In 2024/2847 Annex IV, the legislator lists a few products by name. To make it more pictorial, products in this class are for example:

 

• Hardware Security Modules – Used for secure cryptographic key management;
• Smart Meter Gateways – Secure communication hubs for energy smart meters;
• Trusted Platform Modules – Cryptographic chips in computers for secure boot and encryption;
• Secure Elements – Embedded security chips in credit cards, SIM cards, and passports;
• Cryptographic USB Tokens – Hardware-based authentication devices for secure access (e.g., YubiKey).

Products in the Critical Class are required to undergo a European Common Criteria (EUCC) cybersecurity certification assessment, which is carried out by an accredited conformity assessment body.

Important Class II

Then we have less critical, yet still important products with stricter security requirements than the default class. The so-called important class has two subclasses (I and II) and it contains products with digital elements that carry a significant risk of negative effects in terms of health, security, or safety of users.

You find a complete list of Class II products in 2024/2847 Annex III. To name a few:

 

• Hypervisors for virtualized environments – Like VMware tools or Virtual Box;
• Network security firewalls;
• Tamper-resistant microcontrollers;
• Tamper-resistant microprocessors.

Products in Important Class II must undergo a third-party conformity assessment, regardless of whether they adhere to harmonized standards, common specifications, or a European cybersecurity certification scheme. I am not going into details what are those standards, schemes, and specifications. You have plenty to read in this article already.

Important Class I

This class includes more types of devices that are used daily by individual consumers. The complete list is also available in 2024/2847 Annex III. You can find there most of all:

 

• Operating systems;
• Web browsers;
• Password Managers;
• Virtual Private Network (VPN) solutions;
• Boot managers;
• Smart home assistants;
• Smart home security products like cameras or locks;
• Internet-connected toys;
• Wearables with health monitoring functions;

Products in this class can go with self-assessment if they can apply for one of the aforementioned formulas. Namely Harmonized Standard, Common Specification, or European Cybersecurity Certification.

Default Class

All other products with digital elements available in the EU’s internal market fall into the default category. Your products are most likely in this category if you produce connected devices, software apps, video games, and everything that doesn’t match previous classes.

The default category doesn’t mean that cybersecurity requirements here are unrestrictive. Quite the opposite. Probably 90% of products fall in this category. Those essential requirements will be explained in this article later on.

Software and hardware producers falling into this category can demonstrate compliance with the EU CRA essential requirements (as specified in 2024/2847 Annex I) through self-assessment, following the protocol outlined in 2024/2847 Annex VIII.

 

Hardware and Software Products Classes

 

Is EU CRA in Force? Important Dates for Software Producers

Yes, legally speaking CRA is the current EU legal framework. It entered into force on 12 November 2024. However, it doesn’t mean your products have to comply with all the requirements from day one! European Union’s legislators set two important dates. Let’s have a look at the original text again.

EU Regulation 2024/2847 Preamble (126)

“(126) Economic operators should be provided with sufficient time to adapt to the requirements set out in this Regulation. This Regulation should apply from 11 December 2027, with the exception of the reporting obligations concerning actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements, which should apply from 11 September 2026 and of the provisions on notification of conformity assessment bodies, which should apply from 11 June 2026.”

Based on this:

 

• As of 11 September 2026, you should report all the known explorable vulnerabilities;
• As of 11 December 2027, you should comply with all the cybersecurity requirements which include completing all the assessment, design, and implementation steps and putting it in proper technical documentation followed by the assessment.

 

EU Cyber Resilience Act (CRA) Timeline

 

Business Perspective on the EU Cyber Resilience Act

Software and hardware engineers with years of experience will admit that the software development process is tough and lengthy. If you want to do things right it has to take time and it’s often a Herculean task to complete it on time and within budget.

Complex products with digital elements consist of embedded devices (often built upon several pieces), internal invisible-to-users software components, companion desktop or mobile apps, remote services, and much more. It’s often the case that all these parts use completely various digital technologies, frameworks, and programming languages. Not to mention software dependencies in each part. Hardware and software product development is complex and needs craftsmen. Now it becomes even more complex than before.

Why should manufacturers care? The difficulty of introducing new devices will surely increase. Applying all those cybersecurity rules has to be more time-consuming and a lot of teams will lack the required expertise. It’s going to lead to increased economic costs for a lot of companies. For some it can even be a nail in the coffin. That’s why it’s important to write articles like this to deal with insufficient understanding.

I also feel very sorry for startups that don’t have these resources, these skills, and this know-how to do the actual product not to mention the cyber security part. To my mind, though necessary, the Cyber Resilience Act can limit innovation.

Penalties

Article no. 64 is dedicated to penalties for being non-compliant and so on. Below is the quote from the original text. If this is not scary then I don’t know what is.

Cyber Resilience Act 2024/2847 Article 64

“2. Non-compliance with the essential cybersecurity requirements set out in Annex I and the obligations set out in Articles 13 and 14 shall be subject to administrative fines of up to EUR 15 000 000 or, if the offender is an undertaking, up to 2,5 % of the its total worldwide annual turnover for the preceding financial year, whichever is higher.”

 

Impact on the Design and Development Phase – Planning and Documentation

How do new cybersecurity rules change the regular development phase? The actual cybersecurity requirements will be explained later. Here we’re going to focus on more fixed points in EU CRA’s agenda.

Risk Assessment

As Article 13, (“Obligations of manufacturers”) states, everything should start with the risk assessment. Risk assessment is a process of identifying threats, cyber risks and their potential impact specifically in the case of your products with digital elements. It should take into account the intended purpose and anticipated use of the product, as well as its operational environment and the assets it protects. This assessment should consider the expected duration of the product’s use.

Risk assessment should be done more than once. During this process, you should determine whether a particular requirement makes sense in your case or not.

Technical Specifications

Before placing a product on the market, manufacturers must create a technical specification detailing the measures taken to make the product compliant. Depending on the product’s class it can be required to submit the documentation to a notified body. The documentation should be updated at least during the support period if changes occur.

You can read more about the expected content of technical specifications in EU Regulation 2024/2847 Annex VII.
 
As we described earlier, manufacturers are subject to different conformity assessment procedures depending on the classification of the device. Products in the default class can use self-declaration of compliance of which technical documentation is an important element. Nevertheless, it is good to consult an expert.
 

Impact on the Product’s Life Cycle – Support Period

One of the things having the most impact on a product’s life cycle is the need to evaluate and determine a support period that reflects the expected lifespan of the product. When deciding this period, manufacturers should consider user expectations, the nature of the product, and relevant EU regulations (EU Regulation 2024/2847 Preamble (59)). The next point tells us that it should be at least 5 years, but still, it depends on the expected lifespan of the product.

The Preamble point 61 suggests manufacturers consider sharing the source code with other entities after the end of the support period in case they don’t want to maintain it. It should be done in a way that IP is protected and I believe a business nature. This is something new.

If a software product has a graphical user interface, it should display information about the end of the support period (EU Regulation 2024/2847 Preamble (56)).

 

 

Essential EU CRA Requirements – Practical Tips for Cyber Resilience

Now, it’s where the EU Cyber Resilience Act gets interesting. The idea for this regulation is that it becomes a coherent cybersecurity framework addressing cybersecurity of both critical products and regular electronics, so it has to go with some requirements and I am going to explain them (or at least attempt to) in a language understood by software developers.

You can find the list of requirements on properties of software components in the original text coming straight from the official journal, namely in EU Regulation 2024/2847 Annex I – Essential Cybersecurity Requirements. I will quote Part I of this annex. Part II also describes handling discovered vulnerabilities which I will explain only in the YouTube video about EU CRA that I’m working on.

The following explanation is my understanding of the original text supported by examples I found online. I do not guarantee the completeness of these cybersecurity requirements. Some of the names of the requirements will be more or less obvious but I will try to explain all of them and give my tips.

 

Essential EU CRA Requirements

 

1. Security by Design

“(1) Products with digital elements shall be designed, developed, and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.”

You should start with a risk assessment which will define the product’s security requirements. Then design a proper solution architecture that addresses these requirements. Scythe Studio frequently works on medical device projects, where it is standard practice to prepare a Software Requirements Specification (SRS) document that includes cybersecurity requirements. We then proceed with the Software Detailed Design (SDD) document, which outlines the solution’s architecture.

Many projects begin with the mindset of “It will be done somehow.” However, the European Union insists on considering security from the very start.

 

2. No known vulnerabilities

“[…], products with digital elements shall:
a) be made available on the market without known exploitable vulnerabilities;”

It’s pretty self-exploratory. You can’t release a product if it has vulnerabilities that could be exploited and cause harm to the system or user. Before bringing it to the market, you must examine your entire system for vulnerabilities, including all the dependencies listed in your Software Bill of Material (SBoM). If any are found, they must be fixed.

 

3. Safe Default Configuration

“[…], products with digital elements shall:
b) be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state;”

If the product includes risk mitigation mechanisms they should be enabled by default. For example, if Two Factor Authentication (2FA) is reasonable required, it should be activated by default.

Also, if your hardware or software products store local users’ data (security configurations, secrets), it should be possible to reset the system to its original, factory-new state.

 

4. Security Updates

“[…], products with digital elements shall:
c) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;”

You have to implement a way to update all software elements of your system so that a potential attacker cannot spoof the updates. This requires a system that verifies the authenticity of each update.

The Cyber Resilience Act doesn’t tell you whether your updates should be performed via USB stick (still a widely used method) or over-the-air. However, it mandates that once a security update is available, it must be deployed.

If a device has a connection to the internet you can consider regular checking of updates availability. If you develop a wearable device that only connects to the Smartphone via Bluetooth, you should also check for updates from the mobile app side periodically or as soon at the device gets connected.

 

5. Protection Against Unauthorized Access and Reporting

“[…], 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;”

Implement strong authentication and access controls to prevent unauthorized access. This includes password policies, multi-factor authentication (MFA), and role-based access control (RBAC). Any unauthorized access attempts should be logged and reported. Consider stricter control mechanisms to roles with broader permissions like technicians or developers.

 

6. Data Confidentiality Protection

“[…], products with digital elements shall:
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;”

Cyber Resilience Act tells us that whenever we store or transmit data, it should be encrypted using secure encryption algorithms and we should enable secure protocols like SSL, TLS, or HTTPS. Really, do not turn it off if your certificates expire…

If you store the data locally on some kind of a hard drive you should also encrypt these data as someone can get a hammer, destroy the device’s enclosure, remove the disk, and access all the data stored on it. Some systems allow automatic disk encryption which can be helpful in this case.

All stored and transmitted data should be encrypted using state-of-the-art methods (e.g., AES-256 for data at rest, TLS 1.2+ for data in transit). Protecting personal and operational data prevents eavesdropping and unauthorized access. For example, medical imaging systems should encrypt scans before sending them over a network.

 

7. System Integrity

“[…], products with digital elements shall:
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;”

This point is about ensuring that no unauthorized changes were made to the systems. So manufacturers should implement not only secure boot but also mechanisms to verify whether particular parts of the system are legit. It can be done by checksums, encryption, and mutual handshakes. If anything is corrupted, the device should stop booting, execution, or further functioning.

For IoT devices communicating over a network, it’s crucial to implement a verification mechanism to ensure that the other party is authorized to participate in the data exchange.

 

8. Data Minimization

“[…], products with digital elements shall:
g) process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation);”

You should process and store only the data that are required for system functioning. This point is interesting in the context of data analytics. Some software products implement user behavior monitoring to analyze and improve the user experience. Even if the data is anonymized, it still constitutes collected information and should be carefully evaluated.

 

9. Protection of Critical and Core Functions

“[…], products with digital elements shall:
h) protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks;”

You should design your hardware and software products so the key features are additionally secured and isolated even if the system was somehow tampered with. It’s not an easy task to design architecture in such a way, but what would pay off is the microservices architecture, so each microservice (it can be a separate process) of the software product plays its role and communicates with others. Then the part responsible for the critical function (like driving in the case of cars, cutting in the case of meat/cheese slicer) is isolated from services with access to external interfaces and ports.

If you develop an industrial robotic system and you have a primary control system, you can consider having a backup controller just in case to take over without production stopping.

 

10. Minimizing Negative Impact

“[…], products with digital elements shall:
i) minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks;”

The Cyber Resilience Act requires that the connected devices must not disrupt the performance, availability, or security of other devices or networks. How to achieve this in practice?

I you have a fleet of connected drones in your factory, do not transmit high-frequency data to the central station not to flood the network and the receiver. Send reasonable required data and if possible aggregate them before sending. Here the microservices architecture would also make sense, but you have to design communication with data traffic in mind. Protocols such as MQTT, OPC UA, or DDS should let you listen to only the topics of messages that a particular part of the system needs.

 

11. Limiting Attack Surface

“[…], products with digital elements shall:
j) be designed, developed and produced to limit attack surfaces, including external interfaces;”

If your device has a mini-computer or carrier board with lots of physical interfaces, block them using system options or programmatically. Once upon a time, we had a medical project, and using a USB stick users could upload computer tomography scans. The USB port was needed only at that time, so unless the user intentionally entered the import screen, the port remained blocked.

Another example is remote access to the station. Some manufacturers implement such a thing in order to offer remote support. The possibility to connect remotely should be available only if it was intentionally enabled and properly authorized.

Another tip here is to stay minimalistic. Do not put too much on your head by adding unnecessary features that can be vectors of future cybersecurity attacks.

 

12. Mitigation of Consequences

“[…], products with digital elements shall:
k) be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;”

Hardware and software producers should treat cyber incidents as inevitable. Digital elements securely protected in the best way can still have an unidentified Achilles’ heel. The key is minimizing the impact of these attacks to prevent failures, business users’ data loss, or safety hazards.

You should implement a way to safely recover the system to the latest state before the incident. So for example, if your system detects an anomaly after firmware update, it should roll back the update.

Here again, the microservices architecture will be beneficial, because even if one device/part of the system is compromised, such a design prevents malware from spreading beyond this affected component.

 

13. Recording and Monitoring

“[…], products with digital elements shall:
l) provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user;”

As another measure to limit future cybersecurity attacks, legislators tell you to enable logging and monitoring of security-related activities such as data access, system modifications, and authentication attempts. Logs should be tamper-proof and stored securely.

 

14. Data Deletion

“[…], products with digital elements shall:
m) provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner.”

You should make sure that your hardware and software products allow users to remove all the stored data. It means anything related to the user including app functionalities specific local data. There should be also the possibility to remove all the data from remote cloud services and other connected devices.

If your product has a feature to copy, export, or transmit data to the other part of the system or to the other product (can be the same, but for example newer version) then such a process should also be done securely.

 

Secure Hardware and Software Services – Let’s Make Safer Future Together

This is probably the longest article and the most formal article that I’ve written, but still, it contains a lot of technical tips. If you think about handling this topic in your organization then consider hiring us to ensure your software meets Cyber Resilience Act (CRA) standards. Our deep experience in the highly regulated medical sector guarantees robust cybersecurity, compliance, and risk mitigation regardless of the industry that you represent. Stay ahead of evolving regulations—partner with us for secure, future-proof software solutions. Let’s build resilience together!