The European Union's (EU) Cyber Resilience Act (CRA) is a significant development in product security regulation. As a law that will apply to software and connected device manufacturers located both within and outside EU borders, the CRA will have a long-term global impact. Though the CRA will not fully enter into force for several months, companies are advised to begin preparing now for the complex technical, administrative, and legal processes required.

This post focuses on key CRA requirements related to security vulnerability management. For a broader overview of the CRA, please check out this summary by myself, Alex Botting, and Tanvi Chopra. In this post, we cover:

• Vulnerability reporting requirements
• Product security requirements related to vulnerability management
• Software Bill of Materials (SBOM) and vulnerability documentation
• Coordinated vulnerability disclosure
• Security research protection and bug bounties

The Center for Cybersecurity Policy and Law, through the Cybersecurity Coalition, the Hacking Policy Council, and other initiatives, has tracked the CRA closely and urged improvements to avoid undermining security and innovation. These efforts helped produce progress in the text, notably in the area of vulnerability reporting. However, there are still important improvements that should be considered during implementation.

Applicability and timeline

The CRA applies to “products with digital elements” (PDEs) made commercially available in the EU market, with limited exceptions. This includes software as well as products with both software and hardware with a connection to a device or network – such as Internet of Things devices or operational technology – regardless of where these items are manufactured. To sell a PDE on the EU market, product manufacturers must demonstrate compliance with the CRA’s security requirements through technical documentation and a conformity assessment.

The EU is expected to pass the CRA into law in coming weeks. Much of the CRA will be enforceable three years after enactment, while the vulnerability and cyber incident reporting requirements will apply 21 months after enactment.

Rapid reporting of exploited vulnerabilities

The CRA will require software and connected device manufacturers to promptly report any exploited vulnerabilities in their products. This vulnerability reporting requirement is separate from, and in addition to, the CRA’s obligation that manufacturers report any severe cyber incidents – meaning that exploited vulnerabilities must be reported even if there is no related cyber incident.

This reporting must occur within 24 hours to their designated EU Member State Computer Security Incident Response Team (CSIRT), followed by a more detailed vulnerability notification within 72 hours, and a detailed vulnerability description and mitigation report within 14 days of making the mitigation available. Except in exceptional circumstances, these vulnerability reports are forwarded to other CSIRTs and market surveillance authorities in Member States in which the product is on the market. [See Articles 11.1-11.4; Recitals 34-35c.]

The Center raised serious concerns with the CRA’s requirements to report potentially unmitigated vulnerabilities to dozens of government agencies. These efforts helped result in the final CRA text excluding vulnerabilities identified by good faith security researchers from the reporting requirements [Recital 35a], reducing the level of detail required in the initial 24-hour report [Art. 11.2(a)], and additional flexibility for CSIRTs to delay sharing vulnerability information with other agencies [Recital 35c].

However, concerns regarding government use of reported vulnerabilities for offensive purposes remain, and the Center looks forward to working with EU Member States on CRA implementation to ensure reported vulnerabilities are used only for defense.

Proactive vulnerability management and support

The CRA will require manufacturers to ensure their PDEs are free from “known exploitable vulnerabilities” before market release. Vulnerabilities must be addressed and remediated “without delay” through security updates, and disclosed publicly once an update is available. [Art. 10.6; Annex I Part I (3)(a), Part II (2)-(4).]

Once released, each security update must be available to users for a minimum of 10 years, or for the duration of the product's support period, whichever is longer. [Art. 10.6a.] The CRA specifies that the support period for PDEs should match the expected usage time, with a minimum duration of five years [Art. 10.6].

Businesses can prepare by implementing robust vulnerability detection and patch management systems. This should include efficient documentation processes to track and record vulnerabilities systematically, and use this information in subsequent risk assessments. Businesses should also plan their product life cycles to ensure continued security support throughout the compliance period.

Software Bill of Materials and vulnerability documentation

As manufacturers become aware of product vulnerabilities, including those disclosed by third parties, the CRA requires manufacturers to document them. [Art. 10.5.] One way the CRA requires manufacturers to document product vulnerabilities is by creating an SBOM that encompasses at least the product’s primary components. [Annex I, Part II(1).] Market surveillance authorities may request the SBOM, but manufacturers are not obliged to make their SBOM publicly available. [Recitals 16, 37].

SBOM mandates are appearing with greater frequency in security best practices and procurement specifications. Businesses may wish to initiate processes for producing and maintaining an SBOM, leveraging available resources and guidance to ensure the documentation can be created by the CRA compliance deadline.

Coordinated vulnerability disclosure

Manufacturers must establish a policy for coordinated vulnerability disclosure. This includes providing a clear channel for third parties to report product vulnerabilities to the manufacturer, as well as taking measures to share vulnerability information with other relevant organizations. [Art. 10.6, 10.9c; Recitals 22b, 36; Annex I, Part II (5)-(6).]

Manufacturers must provide users with a single point of contact for reporting security vulnerabilities to the manufacturer. When a product manufacturer learns of a potential vulnerability in a product component, including third party and open source components, the manufacturer must report the vulnerability to the entity maintaining the component. [Art. 10.4a; Annex I, Part II(5)-(6).] Importers and distributors must also inform manufacturers of any vulnerabilities identified in their products. [Arts. 13.5, 14.4.]

Businesses can prepare by creating transparent and responsive communication channels for vulnerability reporting based on widely accepted international standards, such as ISO/IEC 29147 and ISO/IEC 30111. Creation of coordinated disclosure programs should go hand-in-hand with development of vulnerability management processes to ensure disclosed vulnerabilities are assessed and mitigated efficiently.

Security researcher protection and bug bounties

The CRA includes a strong endorsement of the value of good faith security research. The CRA encourages its EU Member States to reduce the potential exposure of security researchers to criminal and civil liability. The regulation urges Member States to adopt guidelines for non-prosecution of security researchers and exempt them from civil liability, similar to action taken in the U.S. by the Department of Justice. [Recital 35i.]

While the CRA does not mandate bug bounty programs, the CRA explicitly encourages manufacturers to consider them. The CRA states manufacturers should ensure coordinated disclosure programs incentivize reporting of vulnerabilities by ensuring that individuals “receive recognition and compensation for their efforts (so-called ‘bug bounty programmes’).” [Recital 36.]

Such initiatives align closely with the CRA's overarching objectives of proactively identifying and mitigating vulnerabilities in PDEs, requirements to adopt coordinated disclosure policies, and the CRA’s stated goal of avoiding sale of exploitable vulnerabilities on the global black market. [Recital 36.] However, businesses must ensure that such programs are well-structured, transparent, and comply with the legal and ethical standards set out in the CRA and elsewhere, thereby fostering a constructive and responsible vulnerability reporting culture.

Establishing robust risk management programs

To effectively prepare for the CRA, companies that provide software and connected devices to the EU market will need to establish robust risk management programs. While prescriptive product security requirements are a sizable component of the CRA, it also obligates manufacturers to establish organization-wide practices, such as coordinated disclosure and vulnerability management processes.

These activities operate best through proactive training and collaboration by cross-functional teams that include legal, technical, and communications experts. Businesses should also establish clear lines of communication with relevant EU Member State CSIRTs and other regulatory authorities to streamline vulnerability reporting processes.

For businesses looking to augment in-house expertise, partnering with cybersecurity consultants or legal experts can provide guidance for navigating the CRA's complexities. Third-party services for conducting regular cybersecurity risk assessments, penetration testing, or bug bounties can help organizations eliminate vulnerabilities before the CRA compliance dates. By embracing a combination of technology and expert advice, businesses can not only help ensure compliance with upcoming CRA obligations, but also fortify their overall cybersecurity defenses.

***

The CRA will set a new standard for product cybersecurity in the EU and beyond. The CRA may well have a GDPR-like ripple effect on product security practices outside of EU borders by applying security requirements to software and connected devices regardless of where they are manufactured. It remains to be seen whether other jurisdictions, including U.S. states, take a page from the CRA and adopt prescriptive product security requirements of their own – as occurred after GDPR.

With an estimated 17 elements still to be prescribed through secondary legislation – implementing acts or delegated acts – and around 30 product-specific standards still to be developed, the Center for Cybersecurity Policy and Law will continue to engage EU policy making bodies and Member States on CRA. It is imperative that implementation and enforcement of CRA avoid undermining security or creating barriers to competition by overburdening product manufacturers. At the same time, the CRA has many positive themes that, if executed well, will contribute to a more secure digital environment.

‍