EU Cyber Resilience Act: Product Security Obligations for Software Vendors

What the Cyber Resilience Act Requires

The CRA establishes essential cybersecurity requirements for products with digital elements — a category that encompasses virtually all software, firmware, and connected hardware sold in the EU. The regulation applies to manufacturers (including software developers), importers, and distributors, creating obligations throughout the supply chain.

Core requirements fall into two categories. Product security requirements mandate that products are designed, developed, and maintained with appropriate cybersecurity measures: secure by default configurations, protection against unauthorised access, data confidentiality and integrity, minimal attack surface, and the ability to receive security updates. Vulnerability handling requirements obligate manufacturers to identify and document vulnerabilities, provide security updates free of charge for the product's expected lifetime (minimum five years), and report actively exploited vulnerabilities to ENISA^[2] within 24 hours.

Products are classified into default, important (Class I and II), and critical categories based on their risk profile. Default-category products can be self-assessed by the manufacturer. Important and critical products require third-party conformity assessment, with critical products subject to European cybersecurity certification. Most commercial software will fall into the important category, necessitating independent assessment by a notified body.

The Software Supply Chain Dimension

The CRA's most far-reaching impact may be on the software supply chain. Manufacturers must conduct due diligence on third-party components integrated into their products, including open-source libraries. The regulation requires the preparation of a Software Bill of Materials (SBOM) for each product, documenting all components and their known vulnerabilities.

For software companies, this means establishing processes to inventory dependencies, monitor vulnerabilities across the component landscape, and rapidly remediate issues in third-party code. Companies that rely heavily on open-source components — which includes virtually all modern software organisations — must develop the capability to track, assess, and respond to vulnerabilities disclosed in their dependency trees. The SBOM requirement alone represents a significant operational undertaking for organisations that have not previously maintained formal component inventories.

The open-source exemption deserves careful attention. The CRA exempts open-source software developed outside the course of a commercial activity. However, any organisation that integrates open-source components into a commercial product assumes responsibility for those components under the regulation. The exemption protects volunteer developers; it does not protect commercial vendors who build on open-source foundations. This distinction is critical for PE-backed software companies whose products may be substantially composed of open-source components.

CE Marking and Conformity Assessment

Products that meet CRA requirements will bear the CE marking, the familiar symbol of European conformity that currently applies to physical goods ranging from medical devices to machinery. Extending CE marking to software products is a conceptual and practical leap: software evolves continuously through updates, whereas traditional CE marking assesses a product at a point in time.

The CRA addresses this through ongoing conformity obligations. The manufacturer must ensure that the product continues to meet essential requirements throughout its expected lifetime, that security updates are available and actively pushed to users, and that the conformity documentation is maintained and updated to reflect changes. A CE-marked software product that subsequently develops unpatched vulnerabilities may lose its conformity status, potentially requiring withdrawal from the market.

For organisations accustomed to the pace of software development — where releases occur weekly or daily — aligning with a conformity framework designed for more static products requires careful process design. The conformity assessment must be integrated into the development lifecycle rather than treated as a gate at the end of the process. Companies that build compliance into their CI/CD pipelines will manage this efficiently; those that bolt it on retrospectively will face significant friction and delay.

Implications for PE-Backed Software Companies

For private equity investors with software portfolios, the CRA creates both risk and opportunity. The risk is straightforward: non-compliance carries penalties of up to €15 million or 2.5% of global turnover, product withdrawal orders from market surveillance authorities, and reputational damage that can impair customer relationships and exit valuations. Portfolio companies that sell into the EU market without CRA compliance will face increasing competitive disadvantage as compliant alternatives emerge.

The opportunity lies in the competitive differentiation that early compliance enables. Software companies that achieve CRA compliance ahead of the mandatory deadline demonstrate security maturity that resonates with enterprise buyers, regulatory bodies, and prospective acquirers. In exit scenarios, CRA compliance reduces a significant source of buyer due diligence risk, potentially supporting premium valuations.

PE firms should assess their software portfolios now for CRA readiness. Key questions include: Does the company maintain SBOMs for its products? Is there a formal vulnerability handling process? Can the company demonstrate secure development practices? What is the expected product classification under CRA, and is third-party conformity assessment required? For acquisition targets, CRA compliance readiness should be incorporated into technology due diligence — the cost of retrofitting compliance into a product not designed with these requirements in mind can be substantial.

Vulnerability Handling and Incident Reporting

The CRA's vulnerability handling obligations represent a paradigm shift for many software companies. Manufacturers must establish documented processes for receiving, assessing, and remediating vulnerability reports from any source — including security researchers, customers, and automated scanning tools. Each identified vulnerability must be addressed through a security update delivered without undue delay.

The 24-hour reporting obligation for actively exploited vulnerabilities is particularly demanding. When a manufacturer becomes aware that a vulnerability in its product is being actively exploited, it must notify ENISA within 24 hours, including an assessment of the severity and potential impact. A full vulnerability notification, including remediation measures, must follow within 72 hours. This timeline requires organisations to maintain the monitoring capability to detect exploitation, the analytical capability to assess impact rapidly, and the communication infrastructure to notify regulators within hours rather than days.

Companies that have historically treated vulnerability management as an informal process — patching when convenient, disclosing when pressured — must formalise their approach. This includes establishing coordinated vulnerability disclosure policies, maintaining relationships with the security research community, implementing systematic vulnerability tracking systems, and training development teams on secure coding practices that reduce the introduction of vulnerabilities in the first place.

Preparing for Compliance: A Phased Approach

The CRA includes a transition period, giving organisations time to achieve compliance. However, the scope of preparation required — particularly for organisations starting from a low maturity baseline — means that early action is essential. A phased approach is recommended.

Phase one (immediate): conduct a gap assessment against CRA essential requirements for each product in the portfolio. Identify product classifications and determine whether third-party conformity assessment will be required. Begin SBOM generation and component inventory. Phase two (three to six months): implement secure development lifecycle practices, establish vulnerability handling processes, and build the monitoring and reporting capabilities required for the 24-hour exploitation notification. Phase three (six to twelve months): conduct internal conformity assessments, engage notified bodies for products requiring third-party assessment, and prepare technical documentation for CE marking.

The CRA will reshape the European software market. Companies that prepare systematically will find compliance manageable and strategically advantageous. Those that delay will face compressed timelines, elevated costs, and the real risk of market access disruption. For PE-backed software companies, the message to portfolio leadership should be unambiguous: CRA preparation is a value-preservation imperative, not a discretionary compliance exercise.