European Commission Guidance on CRA

In July 2026, the Commission provides guidance on critical interpretations of Regulation (EU) 2024/2847 (Cyber Resilience Act or CRA), specifically targeting areas where the iterative nature of software development requires clearer regulatory alignment.

The published guidance provides implementation information in 6 key areas. Below is a summary of the new guidance and how it aligns with the core CRA regulations:

1. Clarifying "Placing on the Market" for Software

While the CRA defines "placing on the market" as the first making available of a product, the new guidance clarifies how this applies to intangible standalone software.

• Alignment: A software product is considered placed on the market the moment it is first offered for distribution or use.

• Iterative Development: Subsequent versions are only considered "newly placed" if they constitute a substantial modification. This prevents every minor bug fix from resetting the regulatory clock.

• Web Distinction: Software merely accessed remotely (like most websites) is generally not a product with digital elements unless it supports a specific product function as a Remote Data Processing Solution (RDPS).

2. Free and Open-Source Software (FOSS) Ecosystem

The guidance provides a "stylized

flowchart" to help developers determine their status under Articles 13, 14, and 24.

• Responsibility: Only "maintainers" who exercise primary control over releases and governance are responsible under the CRA; individual "contributors" are exempt.

• Commercial Activity: The guidance clarifies that accepting donations is generally not a commercial activity unless they are a de facto requirement to access the software or security updates.

• Stewards: Open-source software stewards (Article 24) are legal persons providing sustained support for FOSS intended for commercial use. Their reporting obligations (Article 14) scale based on their role: those providing infrastructure must report severe incidents, while those providing engineering resources must also report exploited vulnerabilities.

3. Substantial Modifications and Spare Parts

Article 3(30) defines substantial modification as a change affecting compliance or intended purpose. The guidance offers practical boundaries:

• Security Updates: In line with Recital 39, security updates are generally not substantial modifications because their primary goal is risk reduction.

• Functionality Changes: A change is substantial if it introduces new threat vectors (e.g., new APIs) or attack scenarios not covered in the initial risk assessment.

• Spare Parts Exemption: Under Article 2(6), spare parts are exempt only if they are identical and supplied through service channels for repair. Non-identical parts (e.g., a newer chip with different encryption) are considered new products subject to the CRA.

4. Support Period and Support for Older Versions

The CRA mandates a minimum 5-year support period unless the product's lifetime is shorter.

• Article 13(10) Flexibility: For software, manufacturers may choose to provide security updates only for the latest version if users can upgrade free of charge and without "additional costs".

• Cost Definition: "Additional costs" refers to mandatory hardware upgrades or infrastructure replacement, not the routine time or testing required for a standard update.

5. Remote Data Processing Solutions (RDPS)

The guidance clarifies Article 3(2) by establishing a three-part test for RDPS:

1. Is the processing "at a distance" (e.g., cloud/edge)?

2. Is its absence a barrier to the product performing a function?

3. Was the software developed under the manufacturer's responsibility (in-house or tailor-made)?

4. Alignment: If a solution (like a third-party SaaS chat bot) is not developed under the manufacturer's responsibility, it is treated as a component rather than an RDPS. The manufacturer must still perform due diligence on it but does not "own" its compliance.

6. Reporting and Vulnerability Handling

• "Becoming Aware": Manufacturers are deemed "aware" (starting the 24-hour clock) once they have a reasonable degree of certainty that an exploitation or severe incident has occurred.

• Reporting Upstream: Under Article 13(6), if a manufacturer finds a flaw in an integrated third-party component, they must report it to the maintainer. The guidance clarifies this is only required if the maintainer is known and the flaw exists within the component itself, not just as a result of poor integration.

7. Interplay with Other Legislation

The guidance clarifies how the CRA interacts with existing sector-specific laws.

• Transition: Valid certificates issued under the Radio Equipment Directive or Machinery Regulation regarding cybersecurity remain valid for those specific risks until June 11, 2028

CRA Sources:

1.      Cyber Resilience Act | Shaping Europe’s digital future 

2.      Commission publishes new guidance to support timely Cyber Resilience Act implementation | Shaping Europe’s digital future 

Looking for a solution tailored to your unique challenges? Gira Group provides expert consultation and specialized training designed to drive results. Let’s work together - reach out to our team or learn more about our services at www.gira.group.