EU CRA TL/DR for PSIRTS - What Product Security Needs To Do To Be Compliant with the CRA

EU CRA TL/DR for PSIRTS - What Product Security Needs To Do To Be Compliant with the CRA

Speakers: Probe, Vulnerability Coordination Expert, Open Source Security Foundation (a project of the Linux Foundation)

Conference: VulnCon

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

Overview

In this insightful talk at VulnCon, Probe, a seasoned vulnerability coordination expert from the Open Source Security Foundation (a project of the Linux Foundation), demystifies the European Union’s groundbreaking Cyber Resilience Act (CRA). The presentation, titled "EU CRA TL/DR for PSIRTS - What Product Security Needs To Do To Be Compliant with the CRA," provides a focused analysis of the new legislation's implications for Product Security Incident Response Teams (PSIRTs) and manufacturers, with a particular emphasis on open source software. Probe, drawing on 15 years of experience in upstream open source security, articulates the critical shifts the CRA introduces, transforming cybersecurity best practices into legal obligations.

The EU CRA is not merely another regulation; it represents a significant paradigm shift in how software and hardware products with digital elements are secured and maintained. Designed primarily as a consumer protection law, it aims to empower European citizens by ensuring they can be made whole after a cybersecurity breach. What makes the CRA particularly impactful is its explicit inclusion of open source software, a first among major global cybersecurity laws. The legislation imposes stringent requirements on manufacturers, including mandatory "secure by design" principles, rigorous vulnerability management, and unprecedented reporting timelines, backed by severe penalties for non-compliance, such as fines up to 2.5% of annual turnover per incident.

This talk is crucial for any organization developing, manufacturing, or selling products with digital elements into the European Union, especially those heavily reliant on open source components. Probe underscores that while many of the CRA's requirements align with existing cybersecurity best practices, their codification into law, coupled with tight deadlines and significant financial consequences, demands immediate and proactive attention. The core message is clear: the time for informal security practices is over; formal, auditable processes are now a legal necessity.

Background

▶ Watch: Speaker introduction, legal disclaimers, talk overview. (0:00)

The Cyber Resilience Act (CRA) emerges from a century-long tradition of EU law, but stands out as one of the first pieces of legislation globally to explicitly address open source software within a cybersecurity context. Unlike the United States, which often influences vendor security through government procurement requirements, Europe has chosen to enshrine these obligations directly into law. This legislative approach is rooted in the principle of consumer protection, aiming to provide redress for European citizens harmed by cybersecurity incidents involving products with digital elements (PDEs).

The scope of CRA is broad, encompassing both hardware and software products, including their remote data processing solutions. For example, a smartphone application that relies on cloud infrastructure to function is entirely within scope. The law distinguishes between "placing on the market" (the first time a product is sold in the EU) and "making available on the market" (any subsequent commercial activity involving money exchange). Crucially, the CRA primarily targets manufacturers (commercial vendors) but also introduces a new role: the open source steward, a legal entity (like the Apache or Linux Foundations) that stewards open source projects. While individual open source developers are generally not directly liable, the manufacturers incorporating their code are.

The CRA interacts with a complex web of existing EU legislation, including the Product Liability Directive (which governs legal recourse for damaged consumers) and the Blue Guide (a comprehensive dictionary for EU legislation terms). Other adjacent laws cover specific sectors like aircraft or marine equipment, establishing precedence hierarchies. Probe’s discussion focuses on Annex 1 of the CRA, which outlines 21 specific requirements for manufacturers. These are broadly categorized into two areas: classic cybersecurity (secure by design, SDLC) and vulnerability disclosure/coordination, which is the core business of PSIRTs. Many of these concepts, like secure software development lifecycle (SDLC) and vulnerability management, are considered "CISSP 101" or "mom and apple pie" practices, but their legal mandate and associated penalties are new. Non-compliance can lead to penalties up to 2.5% of a company's annual global turnover, or 1% for providing misleading information, per incident.

The CRA's provisions will come into effect in phases, with most obligations, including "secure by design" and "secure by default" requirements, becoming legally binding in December 2027. However, crucial vulnerability reporting obligations will take effect earlier, in October or September 2026, demanding immediate attention from organizations. This staggered implementation means PSIRTs have less time to prepare for the most time-sensitive aspects of the law.

Key Findings

▶ Watch: Understanding severe financial penalties for CRA non-compliance. (3:20)

The talk highlights several critical findings regarding the EU CRA's impact on product security:

• Legal Mandate for Cybersecurity: The CRA elevates cybersecurity best practices from recommendations to legal obligations. Concepts like "secure by design" and "secure by default" are no longer aspirational promises but enforceable requirements, necessitating robust documentation and demonstrable evidence for market surveillance authorities or CE mark auditors.
• Open Source Software is Explicitly In-Scope: A groundbreaking aspect of the CRA is its direct inclusion of open source software. Manufacturers are now accountable for the security of open source components within their products and are "encouraged" to engage upstream by contributing fixes and supporting maintainers. This is particularly significant given that 70% to 96% of commercial software includes open source components.
• Strict Vulnerability Reporting Timelines: The CRA imposes extremely tight deadlines for reporting vulnerabilities. Manufacturers must notify ENISA (the EU Agency for Cybersecurity) and a national CSIRT within 24 hours of becoming aware of an actively exploited vulnerability. For severe incidents (those impacting the confidentiality, integrity, or availability of sensitive/important data), an early warning is also due within 24 hours, followed by more detailed information and ideally workarounds or patches within 72 hours. A final report is required within 14 days for actively exploited vulnerabilities and one month for severe incidents.
• No Charging for Security Updates and Extended Support: Manufacturers are forbidden from charging for security updates. Furthermore, products must be supported for at least five years from the last major change, with this timer resetting upon "substantive modifications." Patches must remain accessible for 10 years. This fundamentally alters traditional software licensing and revenue models.
• Retroactive Application: The CRA's obligations apply not only to new products launched after December 2027 but also retroactively to any product still available for sale within its designated support window. This poses a significant engineering burden for maintaining compliance on older products.
• Need for Formalized Processes and Evidence: Informal security practices will no longer suffice. Organizations must implement and document formal risk assessments (preferably following ENISA's framework), be able to produce Software Bill of Materials (SBOMs) upon request, provide evidence of regular testing (pentests, code audits), and establish clear Coordinated Vulnerability Disclosure (CVD) policies.
• Widespread Unpreparedness: Research by the Linux Foundation, cited by Probe, indicates alarmingly low awareness: 62% of surveyed open source maintainers, projects, and manufacturers were either unfamiliar or only slightly familiar with the CRA. This highlights a critical gap between the impending legal requirements and the industry's readiness.

Technical Deep Dive

▶ Watch: Defining 'products with digital elements' and scope. (4:05)

The core of Probe's presentation delves into Annex 1 of the CRA, outlining 21 specific requirements that product security teams must address. These are broadly categorized into two areas: foundational cybersecurity hygiene and stringent vulnerability handling.

Foundational Cybersecurity Requirements:

1. Secure by Design and Secure by Default: Manufacturers are legally required to design and architect their solutions to be as secure as possible before release. This includes providing documented evidence of secure design choices and architectures to market surveillance authorities or CE mark auditors.
2. No Known Exploitable Vulnerabilities: Products cannot be placed on the market with any known exploitable vulnerabilities. PSIRTs must provide evidence at launch that scans (source code analysis, etc.) have been performed and no such vulnerabilities were identified.
3. Risk Assessments: Regular, comprehensive risk assessments are mandatory throughout the product lifecycle. The talk strongly encourages following ENISA's toolbox framework (which aligns with ISO 27005 principles) and maintaining a formal risk register. These assessments, including threat modeling and control implementation, must be shared with regulators (Article 13.4).
4. Regular Testing and Review: Manufacturers must regularly test and review their products, including penetration tests, code audits, and automated scanning using various tools. Evidence of these activities and their results must be producible upon request.
5. Secure Update Distribution: All security updates must be distributed securely, utilizing protocols like HTTPS and TLS, ensuring their integrity and preventing tampering.

Vulnerability Handling and Disclosure Requirements:

This section is particularly critical for PSIRTs, as it codifies and significantly tightens existing vulnerability management practices:

1. Software Bill of Materials (SBOMs): Manufacturers are required to generate and provide SBOMs upon request to legal authorities (e.g., market surveillance authorities, ENISA). While not mandated for public release or customer distribution, the capability to repeatedly create SBOMs (potentially leveraging various types like build SBOMs) is essential. Standardization efforts are ongoing, but it's expected to align closely with CISA and NTIA's minimum required elements.
2. Remediation Without Delay: Organizations must have the capability to remediate vulnerabilities without delay and provide security updates promptly. While "without delay" is not precisely defined, the subsequent reporting timelines indicate a need for rapid response.
3. Upstream Engagement: A standout requirement encourages manufacturers to engage with upstream open source projects. If a manufacturer develops a fix for an open source component, they are encouraged to contribute that fix back upstream. This acknowledges the reality that 70-96% of commercial software uses open source and aims to strengthen the software supply chain.
4. Formal Support Policy: Manufacturers must publish a formal support policy outlining the duration their product will be supported. This period must be at least five years from the last major change. Crucially, a "substantive change" (e.g., a service pack) resets this five-year timer, creating a rolling obligation. This poses a significant challenge for products reliant on open source components that typically lack such formalized support lifecycles.
5. Free Security Updates: The CRA explicitly forbids charging for security updates. This has profound implications for business models reliant on maintenance contracts for security patches.
6. 10-Year Patch Accessibility: All security updates and patches must remain accessible for 10 years if a customer requests them. While not necessarily requiring public hosting, the ability to retrieve and provide these patches for a decade is mandatory.
7. Retroactive Compliance: Products placed on the EU market before December 2027 that are still within their support window must also comply with the CRA's obligations. This means manufacturers may need to backport fixes and ensure compliance for older, potentially less actively maintained products.
8. Coordinated Vulnerability Disclosure (CVD) Policy: A formal CVD policy is required, outlining how vulnerabilities can be reported to the company and detailing the response process and timelines.
9. Information Sharing: Manufacturers must have a process for sharing information about potential vulnerabilities in their products, including those in third-party components. This requires public channels like mailing lists, blogs, websites, or APIs.
10. Single Point of Contact: Companies must establish a single point of contact for engaging with regulators and consumers on security matters. This contact must be able to ingest inquiries through various "preferred means" (email, web form, phone), necessitating robust internal routing for split CSIRT/PSIRT structures.
11. Actively Exploited Vulnerabilities – Strict Reporting:

• 24-hour notification: To ENISA and a national CSIRT upon awareness.
• 72-hour vulnerability notification: A security advisory with a patch or workaround.
• 14-day final report: A comprehensive report after initial awareness.
• The definition of "actively exploited" is still being refined, but typically refers to evidence of ongoing cyber breaches, ransomware, or DoS attacks. The law does allow for embargos in certain circumstances for "regular" vulnerabilities, but not for actively exploited ones.

1. Severe Incidents – Timelines:

• 24-hour early warning: To ENISA and a national CSIRT.
• 72-hour more information: Including workarounds or preferred patches.
• 1-month final report.
• A "severe incident" is defined as one that "negatively affects or is capable of negatively affecting the ability of the product to protect availability, authenticity, integrity, confidentiality of sensitive or important data or functions," such as PII or PHI. This broad definition could encompass many vulnerabilities.

1. National CSIRT Buddy: If a manufacturer does not have an office within the EU, they must select a national CSIRT (e.g., BSI in Germany, NordicERT) to establish a relationship. The choice is often dictated by the country where the most product is sold.
2. Inform Impacted Users: For actively exploited vulnerabilities, manufacturers are obligated to inform affected users, which could involve advisories, emails, or blog posts.

Demo / Proof of Concept

▶ Watch: Understanding manufacturer, steward, and developer roles in CRA. (6:00)

While the talk did not feature a live demonstration or a proof of concept of a specific vulnerability or exploit, Probe did highlight several initiatives and tools under development to aid in CRA compliance.

The Linux Foundation, through its security baseline project, is actively working on a compliance crosswalk that maps CRA Annex 1 requirements against well-known cybersecurity frameworks such as NIST CSF, SSDF, Open Chain, Open CR, PCI DSS, and NIST 2. This crosswalk helps organizations understand how existing security controls can fulfill multiple compliance regimes simultaneously. Probe stated that following the baseline criteria can address 19 of the 21 items in Annex 1, with the remaining two pertaining to sensitive data management and data removal—areas typically handled downstream by product implementers rather than upstream open source projects.

Furthermore, Probe revealed that the Linux Foundation is in the process of automating compliance checks. They are developing a baseline checker tool designed to run against a software repository, identify areas of compliance or non-compliance with the baseline requirements, and even file Pull Requests (PRs) to help projects implement necessary changes. This tool aims to streamline the process for open source projects, making it easier for them to meet CRA obligations, particularly concerning documentation, governance, and security assessment processes. This conceptual tool, once released, could serve as a valuable "proof of concept" for automated CRA compliance assessment.

Defensive Implications

▶ Watch: Navigating the CRA: important articles and definitions. (8:50)

The EU CRA presents a profound challenge and opportunity for product security teams, demanding a strategic overhaul of existing practices:

1. Proactive Program Overhaul and Codification: PSIRTs must move beyond informal best practices to formally codify every aspect of their security program. This includes the entire Secure Development Lifecycle (SDLC), risk management methodologies, vulnerability handling, and incident response. Documentation of these processes, and the artifacts they produce (e.g., risk assessments, testing results), is paramount, as evidence will be required by market surveillance authorities.
2. Strategic Open Source Engagement: Given the deep reliance on open source software (70-96% of commercial software), manufacturers must develop a robust strategy for engaging with their upstream dependencies. This involves not only consuming open source but actively contributing fixes back upstream, supporting maintainers, and understanding the security posture and release cadences of critical projects. Relying solely on upstream projects to provide timely fixes for CRA compliance is a risky strategy, as they have no legal obligation to do so.
3. Accelerated Vulnerability Response: The 24-hour and 72-hour reporting deadlines for actively exploited and severe vulnerabilities are exceptionally stringent. PSIRTs must drastically reduce their mean time to detect (MTTD) and mean time to respond (MTTR), requiring significant investment in threat hunting capabilities, automation, and streamlined incident response playbooks. This may necessitate re-evaluating internal team structures, tooling, and communication protocols.
4. Financial and Legal Model Re-evaluation: The prohibition on charging for security updates and the requirement for 10-year patch accessibility demand a fundamental re-evaluation of product revenue models and long-term support strategies. Companies should engage legal counsel to explore alternative subscription or usage fee models that comply with the CRA while ensuring financial sustainability. Furthermore, the retroactive application of the law necessitates a review of all products currently within their support windows for potential compliance gaps and associated engineering burdens.
5. Formalized Risk Management and SBOM Generation: Implementing a standardized risk assessment framework (like ENISA's) and ensuring the capability to generate Software Bill of Materials (SBOMs) on demand are non-negotiable. These artifacts will be key components of compliance audits.
6. Establish Clear EU Communication Channels: Companies must designate a single point of contact for CRA-related inquiries and be prepared to engage with ENISA and a national CSIRT (especially if no EU office exists). This requires clear internal routing for security inquiries and potentially establishing new relationships with national cybersecurity authorities.
7. Leverage Community Resources: PSIRTs should actively engage with and leverage resources provided by organizations like the Open Source Security Foundation, the Linux Foundation (e.g., CRA 101 class, security baseline), ENISA, and BSI. These resources offer guidance, frameworks, and tools to navigate the complexities of CRA compliance and foster collaborative solutions.

Key Takeaways

• The EU Cyber Resilience Act (CRA) transforms cybersecurity best practices into legal mandates, with severe penalties (up to 2.5% of annual turnover) for non-compliance.
• Manufacturers are legally responsible for the security of all components within their "products with digital elements," including open source software, and are encouraged to engage upstream.
• Strict vulnerability reporting timelines mandate notification within 24 hours for actively exploited vulnerabilities and severe incidents, with patches or workarounds expected within 72 hours.
• Manufacturers are forbidden from charging for security updates, and patches must be accessible for 10 years, with a minimum five-year support period from the last major change.
• Proactive formalization of security processes, including risk assessments, SBOM generation, and documented testing, is crucial, as the law applies retroactively to products within their support window.
• Organizations must develop a single point of contact for EU regulators and prepare to collaborate with ENISA and designated national CSIRTs.

About the Speaker(s)

Probe is a highly experienced Vulnerability Coordination Expert currently working with the Open Source Security Foundation (OpenSSF), a key project of the Linux Foundation. With approximately 15 years of experience in upstream open source vulnerability coordination, Probe brings a deep understanding of the intricacies of open source security, its challenges, and its critical role in the broader software supply chain. He is actively involved in initiatives aimed at helping the open source ecosystem and downstream manufacturers prepare for new regulations like the CRA, including developing educational materials (such as the Linux Foundation's CRA 101 class and a forthcoming risk assessment course) and security baselines. Probe explicitly states that he is not a lawyer and emphasizes that his insights are his opinions, encouraging attendees to consult legal counsel for specific advice on CRA obligations.