EU Cyber Resilience Act: Key Considerations for Manufacturers, Vendors, and Distributors
By Matthew Brady, Senior Security Engineering Manager, Black Duck
As of September 11, 2026, the European Union’s Cyber Resilience Act (CRA) has officially come into effect, marking a pivotal moment for organizations involved in manufacturing, importing, or distributing products containing digital elements within the EU market. This regulation introduces critical responsibilities for these entities, imposing a requirement to notify ENISA (European Union Agency for Cybersecurity) or their respective national CSIRT (Computer Security Incident Response Team) within 24 hours upon discovering that a vulnerability is being actively exploited. Furthermore, they must submit a mitigation report within 72 hours and a comprehensive analysis within two weeks. This implementation represents not only the first significant milestone of the CRA but also sets the stage for broader secure development obligations that are expected to be enacted by December 2027.
Understanding the Scope of the CRA
The Cyber Resilience Act is applicable to a range of products featuring digital components capable of connecting to other devices or networks. This includes, but is not limited to, operating systems, Internet of Things (IoT) devices, web browsers, and routers. The CRA categorizes these products into four distinct tiers based on their criticality. At the most basic level, known as the “default” category, manufacturers can self-certify their products. However, those classified under the important and critical tiers will require external, third-party assessments. The latter tier emphasizes the necessity for stringent compliance and thorough verification, thus placing greater responsibilities on manufacturers to maintain documentation demonstrating their products’ compliance.
Certain categories do fall outside the CRA’s purview entirely. For example, purely open-source software and hosted services are not included unless they connect with products containing digital elements, such as companion applications. Moreover, while products governed by different regulatory frameworks—like automotive and medical devices—are generally excluded, there are exceptions. For instance, infotainment systems in vehicles are still subject to the CRA, even if the core driving systems remain outside its scope.
Clarifications on Reporting Vulnerabilities
A crucial aspect of the CRA pertains to the specification of what constitutes an "actively exploited" vulnerability. Initial guidelines indicated that all vulnerabilities within the broader supply chain would necessitate reporting, a scenario that could overwhelm regulators with the staggering number of vulnerabilities detected daily. However, ENISA has clarified that the reporting obligation solely pertains to vulnerabilities that are being actively exploited within the manufacturer’s own products. This adjustment not only alleviates some reporting burdens but also necessitates heightened diligence from manufacturers, compelling them to maintain an ongoing awareness of their supply chains, continuously monitor for vulnerabilities, and assess incoming data in relation to their product offerings.
Moreover, the decision not to report a known exploited vulnerability must still be well-documented. If a vulnerability that has been identified in the supply chain is later found to exploit a specific product, this lapse in reporting could be seen as a failure to comply with the CRA’s stringent vulnerability management and secure design mandates. Organizations may face severe penalties if they cannot demonstrate compliance, with fines potentially reaching up to 2.5 percent of global turnover or 15 million euros, whichever is greater.
Navigating the Landscape of Public Data
Organizations attempting to build a reporting process grounded solely in public vulnerability data will find themselves navigating a complex and ever-evolving landscape. The frequency of monthly disclosures has surged significantly, yet databases like the National Institute of Standards and Technology’s (NIST) National Vulnerability Database have ceased scoring a majority of new CVEs (Common Vulnerabilities and Exposures). Consequently, the European Union’s own Vulnerability Database often reflects similar inconsistencies. Thus, businesses must employ scoring methodologies that extend beyond single data feeds, ideally leveraging the evolving CVSS version 4, which addresses exploit maturity and captures whether exploitation has been documented in real-world scenarios.
Relying on manual, periodic scans will prove insufficient in meeting the 24-hour reporting requirement. Research conducted by Black Duck has indicated that organizations utilizing continuous, automated monitoring are able to rectify critical vulnerabilities in under a day, significantly faster than their less automated counterparts. As regulatory pressures—including the CRA—continue to mount, such automation has become vital, driving investment in automated testing frameworks. Concepts like SLSA (Supply Chain Levels for Software Artifacts) and NIST’s Secure Software Development Framework facilitate the visibility of dependencies and the validation of Software Bill of Materials (SBOM), thus expediting the remediation process.
Collaborative Responsibilities
The primary duty of reporting vulnerabilities rests predominantly with the manufacturer, vendor, or distributor who introduces a product to the EU market. These entities are also responsible for maintaining an aggregated Software Bill of Materials (SBOM) that encompasses their entire supply chain. Additionally, suppliers of paid components may also fit the definition of manufacturers, with obligations often being transferred downstream through contractual agreements. It is important to note that while open-source components are generally exempt, they must be integrated into the composite SBOM by the vendor assembling the final product. Many organizations find themselves in a dual role, acting both as suppliers and customers, necessitating robust practices for validating incoming SBOMs against the actual delivered products.
Forward Outlook: Broader Requirements Ahead
Looking ahead, the expansive secure development lifecycle requirements set to take effect in December 2027 will encompass various aspects including secure-by-default configurations, structured vulnerability management, and coordinated disclosure protocols. Understanding the relationship between the CRA and the revised EU Product Liability Directive is equally important. This directive, which takes effect in December 2026, reclassifies software as a product for liability purposes and introduces no-fault liability with a reduced burden of proof for claimants. Therefore, while the CRA delineates the responsibilities of a reasonable manufacturer, the directive determines the repercussions for those who fail to uphold specified standards. Documentation produced for CRA compliance may later serve as critical evidence in liability claims.
The role of AI in this context is twofold. It not only broadens the attack surface and increases the volume of vulnerabilities that organizations must manage but also plays a key part in vulnerability assessment. While compliance with the CRA necessitates documented, repeatable, and deterministic processes, AI can support efforts in vulnerability management. However, the reliance on AI must not veer into a lack of accountability; the evidence trail mandated by regulation remains paramount.
Conclusion: A Collective Approach to Compliance
Achieving compliance with the CRA is not a challenge that can be addressed by a single department; it necessitates a collaborative effort across various functions. Effective security relies heavily on the visibility provided by engineering teams, while engineering must integrate risk context that security teams are best placed to offer. Governance, Risk, and Compliance (GRC) functions require insights from both engineering and security to effectively manage compliance. Embedding security testing and compliance processes into existing development workflows can yield better outcomes while minimizing friction, as compliance becomes an inherent output of the software development lifecycle.
The recent reporting requirements established under the CRA may seem burdensome, yet they present a valuable opportunity for organizations to cultivate the supply chain visibility, automated monitoring, and cross-disciplinary collaboration required for the forthcoming December 2027 deadlines. Furthermore, establishing a proactive approach to compliance is essential not only for meeting regulatory demands but also for ensuring long-term liability management and competitive differentiation in an increasingly security-focused digital marketplace.