Why the EU’s Cyber Resilience Act (CRA) Makes Secure Coding Practices Critical

One of the two-sided truisms embedded in the architecture of our modern digital world is this; unbridled innovation has occurred at break-neck speed and resulted in a flourish of incredible technological gifs to the world… However, the implementation (or even consideration in many cases) of proverbial seatbelts and airbags for this unstoppable digital evolution has, largely, been playing a losing battle of catch up. Indeed, one needs only to glance at the latest headlines to appreciate the compounding repercussions of the so-called ‘move fast and break things’ era.

Fortunately, it’s not all doom and gloom, as many nations around the world have been feverishly working on ways to harness the good aspects of technological innovation and mitigate the bad, potentially catastrophic consequences of both inadequate actions. Lawmakers and technologists alike are increasingly working in concert to formulate new laws and acts that strengthen online security and increase the cybersecurity resilience of IT systems. And whilst there will always be a minority that pushes back against all things ‘regulation’ and ‘legislation’, the majority appreciate that without guide rails enshrined, overseen, and enforced by our public and judicial institutions, the risk of veering off-track and crashing exponentially increases.

One such act that aims to marry innovation with security from the get-go is the Cyber Resilience Act (CRA), proposed by the European Union in September 2022. The CRA clarifies the EU’s cybersecurity requirements for “products with digital elements” (PDEs). The goal: To improve the security of PDEs, protect them (and their users) from cyberattacks, and strengthen organizations’ cyber resilience.

Knowing that regulation may not be everyone’s cup of tea, taking the time to understand the CRA at a high level is a worthy exercise since, in the end, we are all in the same proverbial car… hoping that the manufacturer was handed an effective carrot and stick when deciding whether or not to fit seatbelts and airbags!

TL;DR

• The Cyber Resilience Act (CRA) applies to numerous products with digital elements (PDEs), including hardware and software
• It incorporates a set of “essential cybersecurity requirements” meant to improve the security of PDEs and protect PDE users from cyberattacks and data breaches
• The Act classifies PDEs as Class I or Class II products. These “critical” products must undergo third-party conformity assessments to determine their cybersecurity risk level
• Manufacturers of non-critical products must do self-assessments to certify their products comply with the CRA
• Fines for CRA non-compliance can go up to 15 million Euros or 2.5% of annual turnover (whichever is higher)

What is the Cyber Resilience Act?

At the highest level, the Cyber Resilience Act aims to protect organisations and individuals from cyberattacks. To do so, the Act seeks to impose obligations on the connected software and hardware ecosystem for those products available in the EU market, with these obligations encompassing not only the manufacturer of the PDE but also the importers and distributors. Again, at the highest level, the Act seeks to achieve this by requiring adequate security controls and practices to be incorporated from the genesis of the product lifecycle and at all stages throughout. To achieve this, the Act seeks to set the conditions to develop effective security features and practices to protect users from adverse cyber incidents.

Currently, throughout the EU, country-level regulations address cyber risks to a limited extent. Together, they also create a confusing patchwork of rules that increase both the compliance burden for product manufacturers and the uncertainty for product users (“is this product secure?”, “am I at risk of a data breach?” etc.). As a result of (and perhaps most importantly!) this complicated mass of differing guidelines, the EU’s cyber resilience remains low, and the risk of cyberattacks remains high.

The CRA aims to eliminate these challenges by considering the cross-border dimensions of cybersecurity. It unifies the bloc’s regulatory landscape and addresses cybersecurity risks at a Union-wide level. By specifying numerous technology-neutral and sector-agnostic cybersecurity requirements for PDEs, the CRA seeks to ensure that PDE manufacturers incorporate security throughout the product’s lifecycle (“baked-in security”) and release PDEs with fewer vulnerabilities.

CRA: Products Covered

The CRA’s requirements cover many types of hardware and software PDEs that could be directly or indirectly connected to a device or network (logically or physically). These products may be integrated into a larger system, such as an Internet of Things (IoT) network. They may also be connected to other products in a system via hardware interfaces (e.g., wires), logical interfaces (e.g., network sockets), or software interfaces (e.g., application programming interfaces).

The CRA also covers the following:

• Consumer PDEs, such as baby monitors
• Products that are part of critical infrastructure
• Non-embedded software

The Act does not regulate services, such as Software-as-a-Service (SaaS). One exception is remote data processing solutions related to a PDE. Free and open-source software products developed or supplied for non-commercial activities are also not regulated by the CRA (at least for now).

In addition, the CRA does not apply to PDEs that fall under the following categories since they are managed under separate legislation:

• Motor Vehicles (but we’ll keep the above seatbelt / airbag analogy in any case!)
• Military Hardware
• Medical Devices

CRA: Essential Cybersecurity Requirements

In general, the CRA and its requirements cover any kind of PDE that can be an attack vector for malicious adversaries. To this end, it proposes many “essential cybersecurity requirements” that cover a wide range of areas, including:

• Prohibition to sell products with known vulnerabilities
• Identify, document, and address vulnerabilities as early as possible
• Publicly disclose information about fixed vulnerabilities
• Add controls to prevent unauthorized product access
• Take steps to limit the product’s attack surfaces
• Protect the confidentiality and integrity of stored, transmitted, or processed data
• Build resilience against denial of service (DoS) attacks to ensure the availability of essential products
• Act early and leverage appropriate mitigation techniques to minimize the impact of a security incident

Another critical requirement included in the CRA is the requirement to ensure that products are “secure by default”. And this, dear reader, is where we step in. The only way to deliver such products is to adopt secure coding practices and incorporate security considerations at every stage of the software development lifecycle (SDLC).

Why Secure Coding of Critical Products Will Be Essential to Comply with CRA

Since the CRA mandates that hardware and software products should be secure by default, it stands to reason that secure coding practices have not only become even more important than they already are but they are obligated by virtue of the need to create secure devices with secure code. To this point, an EU-appointed body will be creating a document detailing many such practices, which will pave the way for product creators to meet the CRA’s essential cybersecurity requirements and ensure that their offerings are delivered without known exploitable vulnerabilities.

The CRA assigns critical PDEs into two classes: Class I and Class II. These products include password managers, operating systems, physical network interfaces, microprocessors, firewalls, hardware security modules (HSMs), and industrial IoT (IIoT) devices. This classification reflects the products’ cybersecurity risk level, with Class II representing a higher risk.

Third-party EU-notified (official) bodies will conduct assessments of these products to determine if their code complies with the CRA’s requirements. Such specific conformity assessment procedures reflect the cybersecurity risk level of Class I and Class II products. These assessments will be conducted based on three key criteria:

• Cybersecurity-related functionality
• Intended use
• Other criteria, such as the extent of the impact of a cybersecurity event

Furthermore, a cyber incident involving Class II products (e.g., operating systems) might have a greater negative impact than incidents involving Class I products, so that Class II products will undergo stricter conformity assessments. Thus, while both Class I and Class II products should have secure code, particular care should be taken to ensure that the code of Class II products is secure to the highest degree.

If the code of these critical products is found to be non-compliant with CRA requirements, the manufacturer may have to pay hefty fines of up to 15 million Euros or 2.5% of annual turnover (whichever is higher).

Implications of CRA for Secure Coding of Non-critical Products

A majority of hardware and software products do not fall into the CRA’s Class I or Class II categories and will, therefore, not undergo third-party conformity assessments. This “default” category includes products like games, smart speakers, and word-processing software.

But just because a product is not deemed “critical” by CRA (Class I or Class II), it doesn’t mean that the creators and developers of these products are out of the CRA spotlight. And it definitely doesn’t mean that they can ignore secure coding practices!

These creators will have to self-assess themselves to confirm – and certify – if their products comply with the CRA’s essential cybersecurity requirements. Also, like the creators of Class I and Class II products, non-critical product creators will also be fined if they fail to comply with these requirements. Fines will also be levied if they don’t do the self-assessment.

In essence, even products not falling directly in scope still must approach security proactively.

Implications of CRA for Producers of PDEs

As part of the CRA, the European Commission (EC) requires hardware and software manufacturers to identify vulnerabilities in their products, fix them before bringing them into the market, and follow secure coding practices throughout the SDLC. The companies that are already complying with these requirements and following a secure-by-default approach should not find complying with the CRA onerous.

On the other hand, companies that typically take security shortcuts to speed up time-to-market (i.e., that that ‘move fast and break things’) might find it hard to comply with the CRA, particularly because it is currently not completely clear as to which products fall under its purview and how product cybersecurity risk should be determined. Many businesses are also unsure about the technical specifications they must comply with to meet their CRA obligations.

Product distributors and importers also fall under the CRA’s scope, which means they will have to complete at least one type of assessment: i) a self-assessment if their products are non-critical, or ii) third-party assessments if their products can be categorized as Class I or Class II.

Currently, open-source products do not fall under the CRA’s purview. Even so, many open-source developers in the EU worry about future CRA compliance-related headaches. Such worries could affect the pace of open-source innovation and adoption in the EU, which is one of the primary understandable arguments raised by those uncomfortable with increased legislation in such a complex environment.

How Can Your Organisation Respond to the CRA Proposal?

In the coming months, a lot of the confusion around the CRA and its essential cybersecurity requirements will be cleared. Once the European Parliament and European Council review and finalise the Act’s text, the Act will be implemented throughout the EU. When this happens, product manufacturers, vendors, distributors – and anyone else to whom the CRA applies – will have to adapt to the new requirements. This means following secure coding practices, security testing products before release, and implementing controls to protect product functionality and data.

Secure Coding

Secure coding has widespread and long-ranging benefits, and not only for entities affected by the CRA! The best way to ensure that developers create products that are secure by default is to train them on secure coding practices. And the best way to train? With fingers to the keyboard from the very first keystroke course!

The importance of hands-on secure coding training within the EU Cyber Resilience Act is paramount, as it directly addresses the need for developers to be well-equipped to tackle emerging cyber threats.

SecureFlag, as a leading provider of hands-on secure coding training, plays a crucial role in helping organizations comply with the CRA’s requirements. With its extensive library of practical exercises and real-world scenarios, SecureFlag enables developers to gain the necessary skills and experience to identify and remediate security vulnerabilities in their code effectively.

By partnering with SecureFlag, organizations can ensure that their development teams are not only well-versed in the latest secure coding practices but also capable of implementing them in their daily work, ultimately reducing the risk of security breaches and non-compliance with the EU Cyber Resilience Act. In this way, SecureFlag contributes to a more secure and resilient digital landscape within the European Union.

SecureFlag’s platform offers 100% hands-on secure coding training to prepare coders and developers for real-world security threats and to prepare organisations for regulations like CRA. Click here to book a free, no-obligation demo and learn more about the SecureFlag coding platform.