The countdown is on: what the EU Cyber Resilience Act requires

By Scott Register

Every connected product ships with a hidden liability: its software components. When the Log4Shell vulnerability surfaced in late 2021, that liability came due. Organizations spent days, sometimes weeks, determining whether a single open-source library was embedded in their products. answer should have been immediate. For most, it was anything but.

The EU’s response was to legislate. The Cyber Resilience Act (CRA), which entered into force in December 2024, imposes mandatory cyber security requirements on a broad range of products with digital elements made available on the EU market, from consumer IoT devices and industrial control systems to standalone software.

The first manufacturer reporting deadline is close: from 11 September 2026, manufacturers must submit an early warning within 24 hours of becoming aware of actively exploited vulnerabilities or severe incidents affecting product security. The notification must be made to the designated national CSIRT and ENISA.

From voluntary best practice to legal baseline

The Cyber Resilience Act represents a fundamental shift in how the EU treats software security. Rather than relying on voluntary frameworks, it positions cyber security as a product safety requirement, much like the standards that have governed hardware for decades.

The CRA provides for substantial penalties. Once Article 64 applies from 11 December 2027, non-compliance with the essential cyber security requirements or the manufacturer obligations under Articles 13 and 14 may attract fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. Authorities may also order product recalls or require non-compliant products to be withdrawn. On 27 July 2026, the European Commission published practical, non-binding guidance on the application of the Act.

Mapping the software you ship

A central Cyber Resilience Act requirement is that manufacturers must identify and document product components and vulnerabilities, including by drawing up a software bill of materials (SBOM). An SBOM is an inventory of the software components within a product, including operating system packages, third-party libraries, and dependencies. The regulation requires the SBOM to use a machine-readable format and to cover at least the product’s top-level dependencies.

Modern software products routinely consist of 75% or more external components, many of them open source. According to the 2025 Open Source Security and Risk Analysis Report, 97% of the audited commercial codebases contained open-source software, with many containing known vulnerabilities. Without a comprehensive SBOM, manufacturers cannot reliably identify whether their products contain a component affected by a newly disclosed vulnerability, let alone respond within the reporting windows that the CRA demands.

This reflects a broader global trend. Germany’s BSI TR-03183-2 guideline is becoming a de facto quality benchmark across the EU, and markets including South Korea and India are developing similar frameworks. For manufacturers selling into multiple jurisdictions, SBOM maturity is a global competitiveness issue, not just a European compliance exercise.

The false-positive problem

An SBOM details what is inside a product; however, it does not tell you whether a flagged vulnerability is exploitable. A library may contain a known flaw, but if the affected code is unreachable in the final build, that particular vulnerability may not be exploitable in that build. SBOM-based vulnerability scanners that rely on version matching can be poor at making this distinction. A 2026 study by researchers at King Abdullah University of Science and Technology found a 92.0% false-positive rate in its case study of SBOM-based vulnerability scanners.

The operational cost is material. Development teams lose hours each week chasing alerts that turn out to be noise, delaying releases, and eroding trust in security tools. Alert fatigue sets in, and genuine threats risk being overlooked. Under the CRA’s 24-hour early-warning obligation, the ability to separate potentially relevant vulnerabilities from false alarms becomes operationally important to meeting the regulatory requirement.

Building a supply chain security capability

Adhering to the Cyber Resilience Act requires more than a scanning tool and an SBOM. Organizations need end-to-end capabilities spanning vulnerability identification, triage, remediation, and communication, both upstream to component suppliers and downstream to customers.

Tooling decisions should reflect the development environment. Source code, build-time, and binary or firmware analysis each address different parts of the problem, and no single approach covers every scenario. Companies should evaluate solutions against their own codebases and look for detection accuracy and false-positive rates rather than feature lists.

Equally important is integration into existing workflows. Vulnerability data sitting in a standalone dashboard, disconnected from CI/CD pipelines, slows response and increases risk. A confirmed vulnerability should automatically generate a prioritised ticket, identify affected products, and trigger notifications up and down the supply chain.

The case for early action

The CRA’s main obligations apply from December 2027, but the September 2026 reporting obligations also apply to products within the CRA’s scope that were placed on the EU market before 11 December 2027. The time to act is now.

There is also a commercial dimension. Enterprise procurement teams are asking increasingly detailed questions about supply chain security posture before signing contracts. Companies that can demonstrate mature SBOM practices and rapid vulnerability response will stand apart in a market where trust is becoming a differentiator.

The CRA makes product cyber security a condition of market access and a factor in commercial relationships. With supply chain transparency contributing to assessments of trustworthiness, no business can afford to wait.