What Is the Cyber Resilience Act?

The Cyber Resilience Act (CRA) was first proposed by the European Parliament in September 2022. It proposes regulations to monitor and provide security oversight for products with digital elements within the EU. 

The Cyber Resilience Act has sparked controversy among the IT industry, as it looks at the practical and broader scope of designing digital products – including open source software – to be compliant with EU regulations. In this blog, we provide an overview of the Cyber Resilience Act and discuss its intent, implications, controversy, and what organizations need to know. 

What Is the Cyber Resilience Act? 

The Cyber Resilience Act proposes cybersecurity requirements for “products with digital elements throughout their whole lifecycle,” providing cybersecurity rules for software and hardware manufacturers that aim to protect consumers and organizations from security vulnerabilities. 

This legislation was first brought forward in September 2021 by Ursula von der Leyen, president of the European Commission (EC), and the first proposal was published in September 2022. The EU addressed the proposal in July 2023, making some amendments. The legislation continues to make its way through the EU’s law-making system. 

Under the Cyber Resilience Act, any manufacturer of products with digital elements that are made or sold/licensed into the European Union would be subject to these regulations. It’s worth noting that software and hardware companies that are already doing their due diligence with detecting bugs, patching security vulnerabilities, and releasing regular updates are likely already addressing security concerns. What the Cyber Resilience Act will require is a form of self-certification and reporting structure/cadence, more of which we’ll discuss later in this article. 

It's also important to consider that, as the Apache Software Foundation pointed out in their article on this topic, the Cyber Resilience Act may not be the most weighty legislation out there. The EU’s Product Liability Directive, the United States’ Executive Order 14028, “Improving the Nation’s Cybersecurity”, and its “Securing Open Source Software Act of 2023” present significant regulations. Apache points out: “…The US legislation could set standards for that nation through the National Institute of Standards and Technology (NIST), which is typically faster than standards developed by the EU (and thus may well set the global standard).”

The actual security requirements may not be unfamiliar to software and hardware developers; but the exact requirements and standards have not been finalized by the EU at the time of this writing. 

Calling for more security and resilience for software, hardware, and digital products is a positive thing. However, regulations change industries, and they change how work gets done. While the Cyber Resilience Act has the potential to significantly alter digital goods in general; at OpenLogic, we are focused on how it may impact open source software’s development and maintenance, and how OSS communities operate. 

Cyber Resilience Act Objectives

The Cyber Resilience Act (CRA) is focused on improving cybersecurity and resilience on hardware and software, or any product with digital elements. The European Commission outlines the following problems that the CRA is designed to address: 

1. "A low level of cybersecurity, reflected by widespread vulnerabilities and the insufficient and inconsistent provision of security updates to address them;
2. An insufficient understanding and access to information by users, preventing them from choosing products with adequate cybersecurity properties or using them in a secure manner."

It goes on to cite that existing internal (EU) market legislation applies to some products with digital elements, but fails to cover the majority of hardware and software cybersecurity – and points out that current laws do not address non-embedded software.       

The European Commission states that it desires to create conditions for development of secure products, with few vulnerabilities and that manufacturers “take security seriously” throughout the complete lifecycle. It also wants to create conditions that enable end users to take cybersecurity into account when purchasing and using products.       

Based on that, the European Commission specifices four primary objectives of the Cyber Resilience Act, and we quote: 

• “Ensure that manufacturers improve the security of products with digital elements since the design and development phase and throughout the whole life cycle;
• Ensure a coherent cybersecurity framework, facilitating compliance for hardware and software producers;
• Enhance the transparency of security properties of products with digital elements, and
• Enable businesses and consumers to use products with digital elements securely.”

Where the Cyber Resilience Act Applies 

The Cyber Resilience Act applies to member countries of the European Union (which the United Kingdom is not), and to any manufacturer of products with digital elements selling into or licensing into countries within the EU. This means US-based open source software foundations, communities, and commercial vendors would be liable to comply with the CRA. 

Cyber Resilience Act Requirements

The Cyber Resilience Act will require the application of industry security best practices in designing, building, releasing, and maintaining software – from conception through end of life. At the simplest, it’s managing bugs and fixing security vulnerabilities, which most commercial vendors of open source do; but communities and foundations are not always up to date. Best practices may include registering CVEs, doing release notes, and formalized versioning.       

The CRA intends to ensure that any and all software in the EU meets a minimum security level by using self-certification documented in a CE conformity declaration. For more critical software, an actual certificate and audit by a third party will be required. The CRA will define monitoring, oversight, and reporting for compliance.       

Industry best practices for security are not yet well defined, and much of the CRA will likely look to international standards organizations (like NIST) to create standards for self-auditing or external auditors.       

The Cyber Resilience Act continues to be modified as it moves through its legislative process, and what the final Act will be remains to be seen. If it passes in its current form, it will impact most, if not all, manufacturers selling into or producing products with digital elements in the EU. 

Cyber Resilience Act Controversy

Open source foundations and communities have voiced numerous concerns over the potential impact of the Cyber Resilience Act on open source software. The Apache Foundation has been actively involved in discussions with EU lawmakers and expressed the controversy over the CRA within the open source community. To summarize, multiple open source foundations have been working to try to refine the wording in the CRA so that open source software might be exempt from the Act until it enters the commercial supply chain. They have also asked that the CRA stop applying when something like a security fix re-enters the open source commons. 

According to Apache, their meeting with EU lawmakers on July 7, 2023 did not prove successful. They report that the EU has made it clear that the Cyber Resilience Act would apply to open source foundations. Apache interprets their reasoning by saying that while policy makers are aware that open source is crucial to the IT industry, they also realize that open source is around 95% or more of a typical software stack on which European Small and Medium Enterprises operate or are licensed. 

Apache reports that in their discussions they understood that policy makers assume process improvements and self certification will be costly. Looking at the whole stack (95% open source, 5% proprietary) would not be feasible for most small and medium enterprise engineering staff. The EU believes these businesses should be liable for their 5-10% proprietary code and intends that open source foundations be liable for complying with the Cyber Resilience Act. 

According to Apache, the only exceptions are for code that is not used in real life, pure hobbyists, and for mirrors and package repositories like Maven Central. 

The European Commission is presuming commercial intent if the software is used anywhere in a commercial environment. 

Cyber Resilience Act's Impact on Open Source

So, what does this mean for open source? There are some major implications that will alter and deeply effect how open source is created, maintained, and used. As outlined by Apache, and understood by OpenLogic, the current draft includes:

• The Cyber Resilience Act does not discern between commons and commercial. It is all inclusive of foundations, volunteers, and commercial vendors. The CRA implies that “where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature,” quotes Apache.
• So, the CRA applies to anyone that touches open source code that is commercially employed (even by a company that is not in the IT industry). For example, if a sporting goods sales rep commits code in free time, that person would be subject to the CRA because they are employed by a commercial business. Open source projects depend on volunteers, individual contributors, and small teams that are not necessarily well funded or resourced. The CRA’s current draft holds any open source developer whose components end up in commercial products liable for security issues. This could heavily discourage anyone from contributing to the code base.
• The CRA self-certifications are designed to ensure that what is released is adequately secure for its intended purpose. It expects software creators and vendors to understand what components are in their software and to be able to recall software that is affected by a vulnerability. This is very difficult for open source creators as they have no control over how code is used downstream – or what commercial products their components get used in.
• It appears that open source foundations stand to be heavily impacted despite largely already having mature security practices in place; whereas companies further downstream that place products on the market (end use) often need more security standards, but won’t be as impacted.
• Open source and commercial companies will need to be far more mindful in deciding who can work on code, what funding they take, and what patches they can accept – needing to vet any and all committers.
• The CRA requires disclosure of serious unpatched and exploited vulnerabilities to EU-commission ENISA within hours, before they are fixed – rather than the industry best practice of disclosing fixes and workarounds after they are fixed. This will distract from and delay fixes, and leave implementers more vulnerable, as exploits will be revealed publicly before patches or workarounds are available.

These are some of the major concerns within the open source community, and these concerns continue. 

Final Thoughts

At this point, most organizations are keeping an eye on this important legislation and will soon need to start planning for how they will address the implications and move into compliance. The legislation is moving into its final form and then will be voted upon. 

Organizations need to evaluate how the Cyber Resilience Act may impact their production or use of software, and begin to understand and prepare for the compliance implications. 

Concerned About the Impact of the Cyber Resilience Act on Your Organization? 

Our professional services consultants can assist you in exploring how the Cyber Resilience Act may impact your use of open source software and what compliance measures will need to be made. 

Talk to an Expert

Additional Resources

• Blog - Open Source Compliance Overview 
• Blog - Debunking Open Source Security Myths 
• Blog - Gartner Report on Open Source Governance 
• Blog - Software Bill of Materials Overview and Your Open Source Options
• Blog - Why You Need a Software Bill of Materials
• Blog - 5 Reasons Companies Choose OpenLogic for OSS Support
• Video - Risks of Ignoring EOL
• Video - Open Source Security
• On-Demand Webinar - Why You Needed an Open Source Governance Policy...Yesterday