The EU Cybersecurity Resilience Act (CRA) - Boring, Scary or Exciting?

The EU Cybersecurity Resilience Act (CRA) - Boring, Scary or Exciting?

Speakers: Mike Bessel, Co-chair of OpenSSF Global Cyber Policy Working Group, Executive Director of Confidential Computing Consortium

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=U-b6R4JlhHw

Overview

Mike Bessel, a prominent figure in the open-source community as the co-chair of the OpenSSF Global Cyber Policy Working Group and Executive Director of the Confidential Computing Consortium, delivered a critical talk at VulnCon dissecting the European Union's Cybersecurity Resilience Act (CRA). The presentation, titled "The EU Cybersecurity Resilience Act (CRA) - Boring, Scary or Exciting?", provided an insightful, albeit often humorous, analysis of this groundbreaking legislation, aiming to clarify its scope, impact, and the practical steps organizations must take to comply.

Bessel's talk focused on the fundamental question of "who, what, why, and when" regarding the CRA, particularly through the lens of the open-source ecosystem. He meticulously outlined the distinct roles defined by the Act—manufacturers, open-source stewards, and maintainers—and the varying obligations each entity faces. The core message underscored the EU's assertive move to address systemic cybersecurity vulnerabilities within "products with digital elements" (PDEs) and to enhance consumer protection across the bloc.

The significance of the CRA cannot be overstated. It represents a monumental shift in regulatory oversight, extending beyond traditional software and hardware to encompass nearly any device with embedded digital components. For the cybersecurity community and industries operating within or exporting to the EU, understanding and proactively adapting to the CRA's mandates is not merely a compliance exercise but a strategic imperative to mitigate risks, avoid substantial penalties, and foster a more secure digital landscape. Bessel's presentation served as a vital guide for navigating this complex, yet ultimately essential, regulatory journey.

Background

▶ Watch: Introduction to speaker and CRA talk overview (0:00)

The genesis of the EU Cybersecurity Resilience Act (CRA) can be traced back to a fundamental and widely acknowledged problem: the pervasive inadequacy of cybersecurity practices across a vast array of digital products. As Mike Bessel bluntly put it, "Cybersecurity is currently rubbish." This candid assessment reflects a reality where many products with digital elements (PDEs), from seemingly innocuous baby monitors and webcams to sophisticated industrial control systems, are often brought to market with inherent vulnerabilities. The EU observed a growing trend of these insecure devices being exploited as "jumping off" points for broader cyberattacks, a phenomenon exemplified by incidents like the Mirai botnet which leveraged compromised IoT devices for large-scale distributed denial-of-service (DDoS) attacks.

The EU's primary motivation for enacting the CRA is rooted in its commitment to protecting its citizens and consumers. Recognizing that individual products, even those with "low to medium" vulnerabilities, can be chained together to escalate attacks and cause significant harm, the CRA aims to introduce a baseline level of cybersecurity resilience across the entire product lifecycle. This proactive stance seeks to shift the burden of security from the end-user to the manufacturers, ensuring that products are "secure by design" and "secure by default."

While the CRA is a broad and comprehensive regulation, it does not operate in a vacuum. Bessel highlighted that certain sectors, such as aviation, medicine, and automotive, already possess existing, stringent cybersecurity legislation. In such cases, the CRA is designed to complement rather than supersede these established frameworks, often deferring to the sector-specific rules where they are more prescriptive. However, for the vast majority of products that fall outside these highly regulated niches, the CRA establishes a new, overarching standard. The Act’s ambition is to create a harmonized regulatory environment across the EU, ensuring that all products placed on the market meet common security requirements, thereby reducing fragmentation and enhancing overall digital resilience. The core challenge the CRA addresses is the systemic failure of the market to adequately incentivize cybersecurity, leading to a landscape ripe for exploitation and consumer risk.

Key Findings

▶ Watch: Defining the critical role of Open Source Stewards (2:30)

The EU Cybersecurity Resilience Act introduces several fundamental shifts, defining new roles and imposing significant obligations, particularly for those involved in the open-source ecosystem. Mike Bessel's talk meticulously outlined these key findings, providing clarity on who is affected and what is expected.

A central tenet of the CRA is the categorization of stakeholders into three distinct groups: manufacturers, open-source stewards, and maintainers.

• A manufacturer is broadly defined as any entity that sells or otherwise makes commercially available a "product with digital elements" (PDE) in the EU market. This includes not only direct sellers but also those whose products are introduced via importers or distributors. Manufacturers bear the primary and most extensive obligations under the CRA, including liability for security flaws.
• Maintainers are individuals or groups who look after one or more open-source projects. Crucially, the CRA places no direct obligations or liability on individual open-source maintainers. This distinction acknowledges the voluntary and often informal nature of open-source contributions, preventing a scenario where individual contributors could be held liable for vulnerabilities in code they freely provide.
• Open-source stewards represent a novel concept introduced by the CRA to bridge the gap between manufacturers and maintainers. These are typically legal entities, such as the Linux Foundation, Eclipse Foundation, or Apache Foundation, that explicitly commit to providing support for specific open-source projects. Their role is to act as a buffer, offering a formal point of contact and a commitment to support commercial use of open-source components, thereby giving manufacturers a reliable entity to engage with regarding vulnerabilities and incidents. While stewards have certain obligations, Bessel emphasized that their direct liability is limited, placing the onus back on the community and manufacturers to resource these entities adequately.

The scope of the CRA is exceptionally broad, encompassing virtually all "products with digital elements" (PDEs) sold within the European Union. This includes both hardware and software, recognizing that most modern hardware contains embedded software (microcode, firmware) that can introduce vulnerabilities. The Act covers products intended for both businesses and consumers, though Bessel noted a particular emphasis on consumer protection. Specific examples of PDEs range from highly sensitive Hardware Security Modules (HSMs) to everyday items like baby monitors and webcams. While the CRA generally applies to all PDEs, certain highly regulated sectors (e.g., aviation, medical devices, automotive) may see their existing, sector-specific legislation take precedence, as explicitly called out in the Act.

The application of the CRA to services (SaaS) is nuanced. Bessel clarified that while standalone services are generally not covered, a service is included if it is "required by a physical PDE or an application... to function correctly and it's kind of integrated." This means if a web server provides an API for updates to a nanny cam or a phone app that is integral to a PDE's operation, then that service, regardless of its global hosting location, falls under the CRA's purview.

Regarding timeline, the CRA is set to be fully enforced by December 2027. However, critical provisions related to vulnerability and incident management will come into effect a year earlier, by December 2026. Bessel stressed the urgency for organizations to act now, emphasizing that compliance is about establishing robust processes for risk assessment, vulnerability management, and incident response, which take time to embed within an organization's culture and operations.

Finally, the talk highlighted the CRA's core pillars: risk assessment, vulnerability and incident management, and dependency management. These are not isolated activities but interconnected processes crucial for demonstrating compliance. Furthermore, the Act mandates conformance testing and the application of a CE mark for all covered products. The level of testing required varies significantly with the product's security class, ranging from self-attestation for low-impact items to rigorous external audits for high-security products like HSMs or firewalls. This conformance mechanism is designed to provide assurance that products meet the stipulated security standards before they enter the EU market.

Technical Deep Dive

▶ Watch: What are 'Products with Digital Elements' (PDEs)? (4:20)

The EU Cybersecurity Resilience Act (CRA) delves into the intricate technical landscape of digital products, establishing a framework that demands a profound understanding of product architecture, supply chain dependencies, and ongoing security management. Mike Bessel's discussion provided critical insights into these technical aspects, particularly concerning the definition and treatment of "products with digital elements" (PDEs) and associated services.

The foundational concept of the CRA is the Product with Digital Elements (PDE). This definition is intentionally broad, encompassing virtually any item containing software, firmware, or microcode. Bessel highlighted that this includes everything from consumer-grade IoT devices like baby monitors and webcams to enterprise-grade Hardware Security Modules (HSMs) and network infrastructure like firewalls. The implication is that manufacturers must consider the security posture of all digital components, no matter how small or deeply embedded, throughout their product lifecycle. This broad scope reflects the EU's recognition that even seemingly minor digital elements can introduce critical vulnerabilities, as demonstrated by past incidents where insecure IoT devices were weaponized.

The treatment of services (SaaS) under the CRA is a point of significant technical nuance. While standalone cloud services are generally outside the Act's direct scope, an "it depends" clause brings many integrated services into play. If a service is "required by a physical PDE or an application... to function correctly and it's kind of integrated," it falls under the CRA. Bessel gave the example of a web server providing an API for updates to a nanny cam. In such a scenario, the service is considered an integral part of the PDE's functionality. Crucially, the geographical location of the service's hosting (e.g., US, Canada, UK) does not exempt it if it is functionally tied to a PDE made available in the EU. This extends the CRA's reach globally for any manufacturer supplying such integrated solutions to the EU market.

At the heart of CRA compliance are three interconnected technical and procedural pillars: risk assessment, vulnerability and incident management, and dependency management.

• Risk assessment is not a one-time exercise but an ongoing, iterative process. It requires manufacturers to systematically identify, analyze, and evaluate cybersecurity risks associated with their PDEs throughout their entire lifecycle. This involves understanding potential threats, assessing the likelihood and impact of exploitation, and implementing appropriate mitigations. Bessel stressed that this needs to be deeply embedded into organizational processes, influencing design, development, and deployment decisions.
• Vulnerability and incident management is another critical area, with an earlier implementation deadline (December 2026). This necessitates robust processes for identifying, reporting, triaging, and remediating vulnerabilities in a timely manner. It also covers the management of security incidents, including detection, response, recovery, and post-incident analysis. The CRA implicitly demands a proactive security posture, moving beyond reactive patching to continuous monitoring and improvement.
• Dependency management is paramount, particularly for products leveraging open-source components. Bessel, an application engineer by background, highlighted that this is fundamentally about understanding and tracking the entire "supply chain" of software and hardware components. Manufacturers must maintain a comprehensive inventory of all dependencies, often facilitated by Software Bill of Materials (SBOMs), and be able to track their respective vulnerability and incident management processes. Without a clear understanding of these upstream dependencies and their associated risks, effective risk assessment and vulnerability management for the final product become impossible.

The CRA mandates conformance testing and the affixing of a CE mark, a familiar symbol for products meeting EU standards. The rigor of this testing is directly proportional to the "class" of the product, which is determined by its security impact and criticality. Products with lower security risks may qualify for self-attestation, where the manufacturer declares conformity based on internal assessments. However, high-security products, such as HSMs or firewalls, will face the highest level of conformance requirements, necessitating submission of extensive design documentation, risk assessments, and vulnerability management plans to designated EU bodies. Bessel confirmed that spot checks are anticipated, akin to existing CE marking regimes, to ensure ongoing compliance. A crucial detail is that the detailed security documentation submitted for conformance is intended for these regulatory agencies and will not be made public, addressing concerns about exposing sensitive product security information.

Finally, the CRA imposes a significant maintenance period: manufacturers are required to provide free security updates for a minimum of five years from the last substantial change to the product. This long-term commitment aims to address the issue of products becoming insecure due to a lack of ongoing support, ensuring sustained protection for consumers and businesses. This requirement underscores the need for manufacturers to integrate long-term security planning into their product development and support strategies.

Demo / Proof of Concept

▶ Watch: Origins of CRA: IoT concerns and broad applicability (5:30)

This talk was a high-level overview of the EU Cybersecurity Resilience Act's impact and implications, rather than a demonstration of a specific tool, exploit, or proof of concept. Mike Bessel's presentation focused on explaining the regulatory framework, its practical consequences for different stakeholders within the open-source ecosystem, and the strategic adjustments organizations need to make. Therefore, no technical demo or proof of concept was presented during the session.

Defensive Implications

▶ Watch: CRA's application to services and SaaS products (6:30)

The EU Cybersecurity Resilience Act (CRA) presents a formidable challenge and a significant opportunity for organizations involved in the development, distribution, or use of "products with digital elements." For defenders, understanding and proactively responding to the CRA's mandates is paramount. Mike Bessel's talk outlined several critical defensive implications and actionable strategies:

For Manufacturers (the primary obligated entity):

1. Understand Your Role and Obligations: The first step is to definitively determine if your organization qualifies as a manufacturer under the CRA. If you sell or make commercially available any PDE in the EU, directly or indirectly, you are a manufacturer. Subsequently, classify your products according to the CRA's risk categories (e.g., standard, critical, highly critical) as this dictates the level of conformance testing required.
2. Embed Security Processes Now: Do not wait for the December 2027 (or December 2026 for V&I management) deadlines. The CRA demands systemic changes to how security is managed. This means integrating risk assessment into every stage of the product lifecycle, from design to end-of-life. Implement robust vulnerability and incident management programs, including clear reporting mechanisms, timely patching, and effective incident response plans. These are processes that require cultural shifts, training, and significant lead time to mature.
3. Master Dependency Management: Given the pervasive use of open-source components, manufacturers must gain full visibility into their software supply chain. This translates to generating and maintaining Software Bill of Materials (SBOMs) for all PDEs. Understanding the dependencies, their known vulnerabilities, and the security posture of upstream projects is crucial for effective risk management and demonstrating due diligence.
4. Resource Open-Source Stewards and Projects: Acknowledging that open-source maintainers have no direct CRA obligations and open-source stewards have limited liability, manufacturers consuming open-source projects must proactively invest resources (human and financial) into the stewards and the projects they rely on. This is a strategic defensive move: by contributing to the security and maintenance of critical open-source components, manufacturers indirectly strengthen their own product's security and ensure the continued availability of support.
5. Prepare for Conformance and Audits: Manufacturers must gather and maintain comprehensive documentation, including design specifications, risk assessments, vulnerability management plans, and evidence of security testing. This information will be required for conformance declarations and potential audits by EU agencies. For higher-risk products, engaging with accredited conformity assessment bodies will be necessary.
6. Commit to Long-Term Security Updates: The requirement to provide free security updates for five years post-last substantial product change mandates a significant shift in product lifecycle planning. Manufacturers must budget for and implement sustained security maintenance, even for older product versions, to avoid non-compliance and potential penalties.
7. Engage with the Ecosystem: Talk to suppliers, distributors, and open-source communities. Understand their CRA readiness and work collaboratively to ensure a secure supply chain. This collaborative approach is essential for navigating the complexities of shared dependencies.

For Open-Source Stewards:

1. Clearly Define Commitments: Stewards must precisely articulate which projects they support, the scope of that support, and the specific commitments they are making to commercial users. This transparency manages expectations and provides clarity for manufacturers.
2. Advocate for Resources: Actively engage with manufacturers that consume their supported projects to encourage financial and human resource contributions. The CRA creates a strong incentive for manufacturers to support stewards, and stewards should leverage this.

For Open-Source Maintainers:

1. Maintain Best Practices: While not directly liable, maintainers whose projects are widely used in commercial PDEs can contribute to overall ecosystem security by adhering to established security best practices. Tools and guidelines like the OpenSSF Security Baseline can help improve project hygiene and make projects more attractive for commercial adoption under the CRA.

Ultimately, the CRA pushes organizations towards a state where cybersecurity is not an afterthought but a core, continuous process integrated into every facet of product development and maintenance. The penalties for non-compliance, which can reach up to 2% or 2.5% of global turnover (similar to GDPR), underscore the severe financial risks of ignoring these new regulations. Proactive implementation of robust security processes is the most effective defensive strategy.

Key Takeaways

• Broad Scope and New Definitions: The CRA applies to virtually all "products with digital elements" (PDEs) sold in the EU, encompassing hardware, software, and integrated services. It introduces distinct roles: manufacturers (primary liability), open-source stewards (legal entities providing support with limited liability), and maintainers (no direct CRA obligations).
• Core Pillars of Compliance: Compliance hinges on robust, continuous processes for risk assessment, vulnerability and incident management, and comprehensive dependency management (including the use of SBOMs) throughout the entire product lifecycle.
• Mandatory Conformance and CE Marking: All covered products must undergo conformance testing, with requirements varying by product security class (from self-attestation to rigorous external audits), and bear the CE mark to signify compliance.
• Long-Term Security Commitment: Manufacturers are obligated to provide free security updates for a minimum of five years from the last substantial product change, shifting the responsibility for long-term product security onto the producer.
• Incentive for Open-Source Funding: While open-source stewards have limited direct liability, the CRA indirectly incentivizes manufacturers to provide financial and human resources to these stewards and the open-source projects they rely on, ensuring the ongoing security and support of critical dependencies.
• Act Now, Not Later: Key provisions, particularly for vulnerability and incident management, come into effect by December 2026, with full enforcement by December 2027. Organizations are strongly urged to establish and embed security processes immediately to avoid significant penalties, which can reach up to 2% or 2.5% of global turnover.

About the Speaker(s)

Mike Bessel is a prominent and active voice within the open-source and cybersecurity policy communities. He currently serves as the co-chair of the OpenSSF Global Cyber Policy Working Group, an initiative under the Linux Foundation dedicated to addressing cybersecurity policy challenges impacting open-source software globally. In addition, Bessel holds the position of Executive Director of the Confidential Computing Consortium, also part of the Linux Foundation, focusing on advancing technologies that protect data in use. With a background primarily as an application engineer, evolving into an architect, Bessel brings a practical, engineering-focused perspective to complex policy discussions, making him a highly qualified expert to discuss the intricacies of legislation like the EU Cybersecurity Resilience Act.