EU Cyber Resilience Act - A Product Owner’s Approach

EU Cyber Resilience Act - A Product Owner’s Approach

Speakers: Langley Rock, Product Owner, Dell Technologies

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=Ffyq4PH2eRY

Overview

The European Union’s Cyber Resilience Act (CRA) represents a landmark legislative initiative set to profoundly reshape how software and hardware vendors operate within the EU market. In this VulnCon talk, Langley Rock, a Product Owner at Dell Technologies, offers a pragmatic, product-owner-centric perspective on navigating the complexities of the CRA. His presentation cuts through the legal jargon to provide actionable insights for organizations grappling with the impending compliance deadlines and the significant implications for product development and security practices.

Rock emphasizes that the CRA is not merely a bureaucratic hurdle but a fundamental shift requiring a proactive, organization-wide commitment to cybersecurity. With the threat of substantial fines—up to €15 million or 2.5% of annual global revenue per infraction—non-compliance is a risk no company can afford to ignore. This talk is crucial for any organization that designs, develops, or sells products with digital elements in the EU, offering a roadmap to understanding the act's core tenets and strategically preparing for its implementation.

The core message is one of urgency and strategic preparation. While many requirements for the CRA are slated for December 2027, critical aspects like vulnerability response come into effect even earlier, by September 2026. Rock's insights are particularly valuable for product owners, engineering leads, and security professionals who need to translate high-level regulatory mandates into concrete, executable tasks within their product development lifecycles, ensuring not just compliance but also enhanced product security.

Background

▶ Watch: Introduction and Product Owner's Perspective (0:00)

Langley Rock brings over two decades of experience in product security, having navigated various regulatory and certification landscapes, including Common Criteria and FIPS certifications, Secure Development Life Cycles (SDL), and Governance, Risk, and Compliance (GRC) roles. A recurring observation throughout his career, and a central theme of his talk, is that engineering teams and stakeholders inherently "want to do the right thing." However, they frequently encounter obstacles such as competing priorities, poorly communicated requirements, or a lack of understanding regarding the underlying rationale ("the why") behind security mandates. This insight forms the bedrock of his product owner's approach to the CRA: making requirements clear, actionable, and aligned with organizational goals.

The EU Cyber Resilience Act (CRA) is designed to enhance the cybersecurity of products with digital elements across their entire lifecycle. It aims to address the growing threat landscape by placing stringent cybersecurity obligations on manufacturers, importers, and distributors. While the intent is clear, the practical application is currently mired in ambiguity, primarily because the harmonized standards that will guide compliance do not yet exist. These standards are crucial, as adherence to them is expected to satisfy the legal obligations of the Act. Without them, organizations face the challenge of preparing for a moving target, necessitating a proactive and risk-based strategy.

A significant point of contention and concern for many vendors, particularly those heavily reliant on open-source software, is the CRA's stance on open-source components. While open-source stewards themselves are not held to the same direct requirements, the vendor incorporating an open-source component into their commercial product bears full responsibility for any vulnerabilities found within that component. This shifts the burden of security and remediation squarely onto the product manufacturer, demanding robust third-party risk management and strong relationships with upstream suppliers or the capacity to fix vulnerabilities internally. Furthermore, the strict enforcement of a "no known vulnerabilities" clause could severely impact a product's ability to reach market, given the continuous discovery of new security flaws. Rock highlights these critical background elements as foundational challenges that product owners must address immediately.

Key Findings

▶ Watch: Impact on Open Source and Supply Chain (2:40)

Rock's presentation distills the complex requirements of the CRA into several key findings and actionable strategies for product owners. A central finding is the urgent need for a proactive approach to compliance, rather than waiting for the finalization of harmonized standards. Organizations must begin aligning their practices with the known essential requirements of the CRA today, as the December 2027 deadline (and September 2026 for vulnerability response) is rapidly approaching.

A critical aspect of compliance involves understanding and correctly classifying products into one of four categories defined by the CRA:

• Default products: Such as alarm clocks or smart refrigerators, which require only a self-assessment.
• Important Class 1 products: Including operating systems, physical or virtual network interfaces, and web browsers. These also allow self-assessment, provided compliance with harmonized standards can be demonstrated.
• Important Class 2 products: Like hypervisors or Trusted Platform Modules (TPMs), which necessitate an external evaluation by a recognized body listed in the Nando database.
• Critical products: Such as smart cards, demanding a rigorous and often expensive Common Criteria certification.

Rock points out that the precise definitions for these product categories are still being refined, underscoring the ongoing need for vigilance and engagement with the regulatory process. He also clarifies that including an operating system or network interface in a general-purpose computing platform does not automatically elevate it to a Class 1 product, highlighting the nuances that will be crucial in final interpretations.

To navigate these complexities, Rock proposes a structured, multi-step approach:

1. Identify target products and their likely CRA classification.
2. Determine which products will be on the market by December 2027, as the regulation applies to new products.
3. Bucketize CRA requirements into logical themes (e.g., continuous testing, security updates, vulnerability response, security assessments).
4. Assess current practices: Identify areas where the organization already excels (lowest perceived risk), where plans are in motion (requiring acceleration or pivoting), and where practices are weak or non-existent (net new requirements).
5. Cross-reference net new requirements against an internal security charter, if one exists.
6. Implement risk-based reporting and socialize the CRA's impacts and required efforts across the organization, from top leadership to individual teams. This fosters collective ownership and enables informed decision-making on risk acceptance.
7. Integrate security requirements into product roadmaps, specifically into 3-year plans, ensuring that fiscal targets and delivery dates account for the increased security burden.

A significant finding is the earlier deadline for vulnerability response requirements (September 2026), which mandates timely communication, coordinated disclosure, and machine-readable advisories. Rock also stresses the paramount importance of having a security charter within the organization, as it provides "street credibility" and a foundational document for engaging stakeholders and demonstrating a long-standing commitment to product security. Finally, he advocates for industry collaboration through organizations like SafeCode and OpenSSF as a vital mechanism for sharing best practices and collectively addressing the challenges of CRA compliance.

Technical Deep Dive

▶ Watch: The Challenge: Non-existent Harmonized Standards (4:00)

The EU Cyber Resilience Act (CRA) introduces a comprehensive regulatory framework for manufacturers, importers, and distributors of products with digital elements. Its technical mandates span the entire product lifecycle, from design and development to post-market surveillance and incident response. The Act's provisions are set to become legally binding for most requirements by December 11, 2027, with a critical carve-out: vulnerability response requirements will kick in earlier, by September 2026. Non-compliance carries severe financial penalties, with fines potentially reaching €15 million or 2.5% of the organization's annual global revenue per infraction.

A cornerstone of CRA compliance is adherence to harmonized standards. These technical specifications, once developed and ratified, will provide detailed guidelines for meeting the Act's essential requirements. The challenge, as Rock highlights, is that these standards do not yet exist, leaving organizations to interpret the high-level legal text. In the interim, a proactive, risk-based approach is essential.

The CRA categorizes products based on their perceived cybersecurity risk, dictating the required conformity assessment procedures:

• Default Products: These are products with lower cybersecurity risk, such as basic smart home devices (e.g., alarm clocks, smart refrigerators). For these, manufacturers can perform a self-assessment to declare conformity.
• Important Class 1 Products: This category includes foundational software and hardware components like operating systems, physical or virtual network interfaces, and web browsers. While self-assessment is permitted, manufacturers must be able to demonstrate compliance with the future harmonized standards. Rock specifically notes that a general-purpose computing platform including an operating system or network interface is not automatically classified as Class 1, emphasizing the nuance in product definition.
• Important Class 2 Products: These are products deemed to have a higher cybersecurity risk, such as hypervisors or Trusted Platform Modules (TPMs). Conformity for these products requires external evaluation by a Notified Body, which is an independent third-party assessment organization listed in the Nando database.
• Critical Products: This highest-risk category, exemplified by smart cards, demands the most stringent assessment: a lengthy and often expensive Common Criteria certification. This internationally recognized standard evaluates security functionality and assurance levels.

Rock outlines a structured approach for organizations to prepare for these technical requirements:

1. Product Identification and Classification: Organizations must meticulously identify all products with digital elements that will be placed on the EU market by the December 2027 deadline and accurately classify them into the appropriate CRA category. This initial step is fundamental, as it dictates the entire compliance pathway.
2. Requirements Bucketing: The extensive list of CRA requirements should be grouped into logical themes to simplify management and assignment. Examples of such buckets include:

• Continuous Testing: Encompassing ongoing security testing throughout the product lifecycle.
• Security Updates: Covering secure distribution mechanisms, automatic downloads, configurable update processes, and decoupled security updates.
• Vulnerability Response: This is a critical and early-onset area (September 2026). It mandates documenting vulnerabilities and remediations, ensuring timely communication and remediation, implementing coordinated disclosure, and providing advisories in a machine-readable format.
• Security Assessments: Involving internal analysis of cybersecurity risks and maintaining comprehensive technical documentation to support good security practices.

1. Gap Analysis and Prioritization: By comparing current practices against these bucketed CRA requirements, organizations can identify:

• Lowest perceived risk: Areas where current practices are already robust.
• Accelerate/Pivot: Existing plans that need to be fast-tracked or adjusted.
• Net new requirements: Areas where practices are weak or non-existent, requiring significant new effort and potentially legal consultation.

1. Security Charter Integration: The speaker stresses the importance of an organizational security charter. This document acts as a foundational commitment to product security, providing "street credibility" and a framework for cross-referencing CRA requirements, ensuring alignment with overarching security goals.
2. Risk-Based Reporting and Socialization: Implementing a transparent, risk-based reporting mechanism is crucial. This allows for clear visibility into areas of non-compliance or high risk, enabling senior leadership to make informed decisions about risk acceptance and resource allocation. Effective socialization of these requirements—both top-down and bottom-up—ensures organizational buy-in.
3. Roadmap Integration: Product owners must integrate CRA security requirements directly into their 3-year product roadmaps. This means factoring security needs into fiscal targets, development timelines, and delivery dates, moving security from an afterthought to a core consideration.

During the Q&A, the challenge of the "no known vulnerabilities" requirement was discussed, particularly given the constant discovery of new flaws. Rock clarified that authorities are likely to prioritize due diligence. This implies demonstrating a robust process for testing vulnerabilities during build, test, and quality control phases, and having an active vulnerability response program to remediate newly discovered issues. This approach suggests that while perfection is unattainable, a demonstrable commitment to continuous security improvement and timely remediation is paramount. He also briefly mentioned that a recommended risk management framework is available, potentially from ENISA (European Union Agency for Cybersecurity), to guide organizations in their risk assessment and mitigation strategies.

Demo / Proof of Concept

▶ Watch: Key Nuance: General Purpose Computing Platforms (7:00)

While the talk did not feature a traditional live demonstration of a technical tool or a proof of concept exploit, Langley Rock presented a valuable conceptual framework that serves a similar illustrative purpose for product owners. He provided an "example of what net new requirements might look like for an organization" and how these could be logically grouped into themes or "buckets."

This conceptual "demo" showed how specific CRA requirements, such as "continuous testing," "secure distribution of updates," "automatic downloads from products," "download configuration," and "decoupled security updates," could be categorized under broader objectives like "security testing" and "security updates." Similarly, detailed requirements for "documenting vulnerabilities and remediations," "timely communication and remediation," "coordinated disclosure," and "machine-readable advisories" were grouped under a "vulnerability response" bucket. The speaker also illustrated how "analysis of cyber security risks" and "technical documentation" would fall under "security assessments."

This practical bucketing strategy, though not a code demo, is a critical tool for product owners and technical leads. It helps to translate abstract regulatory text into manageable, actionable components, making the daunting task of CRA compliance more approachable for engineering teams and facilitating the integration of these requirements into existing development workflows and security charters.

Defensive Implications

▶ Watch: Practical Steps for EU CRA Compliance (8:00)

The EU Cyber Resilience Act demands a profound shift in defensive strategies for any organization developing or selling products with digital elements in the EU. The implications extend far beyond mere compliance, necessitating a fundamental re-evaluation of product security practices throughout the entire lifecycle.

Firstly, proactive compliance is no longer optional; it's an imperative. Defenders cannot afford to wait for the finalization of harmonized standards. Organizations must immediately begin aligning their Secure Development Life Cycle (SDLC) processes with the known essential requirements of the CRA. This includes embedding security from the design phase, implementing threat modeling, security by design principles, and ensuring continuous security testing throughout development and deployment.

Supply chain security becomes a critical defensive front. The CRA explicitly holds product manufacturers responsible for vulnerabilities in any third-party components, including open-source software. This requires robust third-party risk management programs, rigorous vetting of open-source libraries, and establishing clear lines of communication and remediation agreements with suppliers. Defenders must assess the security posture of all upstream dependencies and be prepared to fix vulnerabilities themselves if suppliers cannot or will not.

Enhanced vulnerability management is paramount. The earlier deadline of September 2026 for vulnerability response requirements means organizations must accelerate improvements in this area. Defensive teams need to ensure:

• Timely discovery and documentation of vulnerabilities.
• Rapid remediation processes.
• Coordinated disclosure mechanisms with clear communication protocols.
• The ability to produce machine-readable advisories to facilitate automated consumption by customers.
• Establishing a 24-hour early notification capability for authorities after discovery, as mentioned in the Q&A.

Continuous testing is emphasized as a core defensive practice. This moves beyond periodic penetration tests or vulnerability scans to integrating security checks into every stage of the CI/CD pipeline. This includes static and dynamic application security testing (SAST/DAST), software composition analysis (SCA), and fuzz testing. The goal is to detect and address vulnerabilities as early as possible in the development cycle, reducing the cost and complexity of remediation.

Defenders must also drive the establishment and enforcement of an organizational security charter. This document serves as a foundational policy, articulating the company's commitment to product security and providing the necessary authority to implement security controls across all product teams. It fosters internal accountability and provides a framework for communicating security expectations to engineering and product stakeholders.

Finally, the CRA necessitates a shift towards a more transparent and risk-based approach to reporting security posture. Defenders must be able to articulate the organization's cybersecurity risks, the controls in place, and any remaining gaps to senior leadership. This allows for informed decisions on risk acceptance and resource allocation, ensuring that the company's overall risk tolerance is understood and managed. Leveraging existing frameworks, such as those potentially recommended by ENISA, can provide a structured approach to this risk management.

Key Takeaways

• The EU Cyber Resilience Act (CRA) is an imminent and impactful regulation for all software and hardware products with digital elements sold in the EU, imposing significant obligations and penalties for non-compliance.
• Despite ambiguities surrounding the final harmonized standards, organizations must adopt a proactive approach now, integrating CRA requirements into their product development roadmaps and security strategies to meet the December 2027 deadline for most provisions.
• Understanding and accurately classifying products into Default, Important Class 1, Important Class 2, or Critical categories is crucial, as this dictates the required conformity assessment process, ranging from self-assessment to expensive Common Criteria certification.
• Vulnerability response requirements have an earlier deadline of September 2026, demanding robust processes for timely documentation, remediation, coordinated disclosure, and the provision of machine-readable advisories and 24-hour early notifications.
• Organizations must implement continuous security testing, enhance supply chain security for open-source components, and establish a clear security charter to demonstrate due diligence and foster internal buy-in for CRA compliance.
• Baking security requirements into 3-year product plans, implementing risk-based reporting, and fostering industry collaboration are essential strategies for navigating the CRA's complexities and ensuring long-term product security and market access.

About the Speaker(s)

Langley Rock is a seasoned professional in the field of product security, currently serving as a Product Owner at Dell Technologies, a role he has held for approximately three years. His responsibilities at Dell Technologies focus on managing vulnerability response policies and standards, as well as overseeing regulatory and GRC (Governance, Risk, and Compliance) related activities.

With a distinguished career spanning 20 years in product security, Langley has a rich background that includes extensive experience with Common Criteria and FIPS certifications, the implementation of Secure Development Life Cycles (SDL), and various GRC-related roles. His expertise is rooted in understanding the challenges faced by engineering teams in balancing security requirements with competing priorities, and his approach emphasizes clear communication of the "why" behind security mandates. Langley Rock is based in Ottawa, Canada.