On July 27, 2026, the European Commission published the final version of its Cyber Resilience Act (CRA) Implementation Guidance, providing covered entities with clearer direction on how to apply the EU’s landmark product security regulation. 

The Cybersecurity Coalition welcomes the final guidance and appreciates the Commission addressing several key concerns we raised during its public consultation in April. The revisions clarify the regulation’s scope, reduce the risk that routine security fixes trigger disproportionate compliance burdens, and offer manufacturers greater flexibility in managing product support and vulnerabilities.

What is the main goal of the CRA?

The CRA requires covered entities to ensure that hardware and software products are developed using secure-by-design principles before they are placed on the market and that vulnerabilities are identified, managed, and remediated throughout the product lifecycle.

Why is the guidance significant? 

The guidance is intended to help manufacturers and other covered entities understand how the CRA’s requirements apply to their specific products. It recognizes that securing a router requires different considerations than securing a smart speaker or operational technology used to control critical infrastructure. 

Although the guidance itself is not legally binding, it reflects the Commission’s understanding of the CRA, which will likely influence enforcement by national authorities. It also arrives ahead of key deadlines: vulnerability and incident-reporting requirements take effect September 11, 2026, while the rest of the CRA applies beginning December 11, 2027.

Coalition Recommendations Reflected in the Final Guidance

• Broader Definition of Free and Open Source Software – The Coalition was concerned that the CRA and the guidance defined Free and Open Source Software (FOSS) too narrowly, creating uncertainty about whether established software development practices would qualify for the open source exemptions under the CRA. The Commission clarified that common upstream and downstream code-sharing practices can fall within the definition.
• Spare-Part Treatment for Full-Product Replacements – The Coalition was concerned that functionally identical replacements for an entire product might not qualify as spare parts, making repairs to complex or older systems more burdensome. The Commission clarified that certain full-product replacements may qualify for the spare-part exemption under Article 2(6).
• Security Updates to Existing Products – The Coalition was concerned that a security update to a product placed on the market before the CRA applies could trigger compliance obligations for the entire product. The Commission clarified that only the substantially modified part must be brought into compliance, rather than the entire product.
• Minor Updates and Support Periods – The CRA generally requires manufacturers to provide security support for products for at least five years. The Coalition was concerned that every minor update or bug fix could restart that period, but the Commission clarified that these updates do not automatically create a new five-year support obligation. 
• Flexible Vulnerability Reporting – The Coalition was concerned that the CRA could require security fixes to be shared with original software developers in a specific format or through a prescribed process, even when that approach does not fit standard industry practices or existing vulnerability-reporting channels. The Commission revised the Guidance to allow more flexible methods, including established coordinated vulnerability disclosure processes.

Coalition Concerns That Remain Unresolved

• Overlapping CRA and NIS2 Requirements for RDPS – The guidance fails to resolve potential regulatory overlap for remote data processing solutions (RDPS), leaving cloud services vulnerable to duplicative obligations under both the NIS2 Directive and the CRA.
• Open-Source Steward Status – The Commission did not clarify that entities providing only incidental support to open-source software should be exempt from being designated as software stewards.
• Product-Family Documentation Reuse – The guidance lacks clarity on when — and under what conditions — manufacturers can reuse risk assessments and conformity documentation across families of products.

That said, these revisions make the final guidance significantly more practical, aligning it more closely with real-world software development while removing unintended barriers to cybersecurity improvements. As implementation proceeds, the Coalition will continue advocating for a practical, risk-based approach to product security that enables manufacturers to respond effectively to evolving threats.