CRA Reporting Obligations for Open Source Software Stewards

Steward Reporting Starts on 11 December 2027

The application date is different from the earlier manufacturer reporting date. Article 14 reporting began applying to manufacturers on 11 September 2026. The CRA as a whole applies from 11 December 2027, and the European Commission's reporting guidance specifically confirms that open-source software stewards are subject to the Article 24(3) reporting obligations from 11 December 2027. Steward procedures should therefore use 11 December 2027 as their reporting application date rather than importing the manufacturer date.

• Manufacturer reporting started on 11 September 2026.
• Steward Article 24(3) reporting starts on 11 December 2027.
• The two dates should not be conflated.
• Stewards can prepare processes before the application date.

Article 24(3) Does Not Simply Copy the Entire Manufacturer Reporting Regime

Article 24(3) uses precise cross-references. It applies Article 14(1) to open-source software stewards within one stated condition and Article 14(3) and Article 14(8) within another stated condition. It does not say that every paragraph of Article 14 applies automatically to stewards. Compliance documentation should preserve that structure. Describing the steward regime simply as the same reporting regime as manufacturers risks obscuring both the narrower legal triggers and the separate role that open-source software stewards occupy under the CRA.

• Article 24(3) names specific Article 14 paragraphs.
• The steward regime is expressly limited.
• The manufacturer and steward roles remain different.
• Reporting procedures should follow the exact statutory cross-references.

Article 14(1) Applies Where the Steward Is Involved in Product Development

The first limb of Article 24(3) applies the obligation in Article 14(1) to open-source software stewards to the extent they are involved in development of the product with digital elements. Article 14(1) concerns actively exploited vulnerabilities contained in the product. The steward therefore needs a process for determining whether it is involved in development of the affected product and whether information reaching the organisation concerns an actively exploited vulnerability rather than an ordinary vulnerability with no known active exploitation.

• Development involvement is part of the steward trigger.
• The vulnerability must be actively exploited for Article 14(1).
• Ordinary vulnerability intake and mandatory CRA reporting are not identical.
• The steward should document its reportability assessment.

Actively Exploited Vulnerabilities Are Reported Through the CRA Platform

Article 14(1) requires notification to the CSIRT designated as coordinator and ENISA through the Single Reporting Platform established under Article 16. The Commission's current CRA reporting guidance confirms that manufacturers and open-source software stewards submit their notifications through that platform. A steward preparing for Article 24(3) should therefore identify who can access the reporting process, who has authority to submit on behalf of the organisation and how sensitive product and vulnerability information will be gathered before submission.

Do Not Automatically Copy Every Manufacturer Deadline Into the Steward Policy

Article 14 contains detailed manufacturer notification procedures, including the staged timelines found in paragraphs 2 and 4. Article 24(3), however, expressly cross-refers to Article 14(1), Article 14(3) and Article 14(8), not to every paragraph of Article 14. A steward policy should therefore avoid asserting, without a further legal basis or applicable official guidance, that every manufacturer procedural deadline automatically applies identically to stewards. The safest implementation is to track the exact Article 24(3) obligations, current Commission guidance and any later steward-specific reporting instructions issued for the Single Reporting Platform.

• Article 24(3) does not cite every Article 14 paragraph.
• Manufacturer deadline language should not be copied mechanically.
• Current official guidance should be monitored.
• Reporting processes should still support rapid escalation.

Severe-Incident Reporting Has a Different Steward Trigger

The second limb of Article 24(3) applies Article 14(3) and Article 14(8) only to the extent that severe incidents having an impact on the security of products with digital elements affect network and information systems provided by the steward for development of those products. This is materially narrower than saying every incident involving any downstream use of the open-source software must be reported by the steward. The steward needs to identify which development systems it actually provides and whether the severe incident affects those systems in the way required by Article 24(3).

• The event must be a severe incident affecting product security.
• The incident must affect relevant network and information systems.
• Those systems must be provided by the steward for product development.
• The trigger is narrower than general downstream incident awareness.

Identify Which Development Systems Are Provided by the Steward

A qualifying steward can provide collaboration platforms, code hosting, build services, release infrastructure, signing systems, issue trackers or other network and information systems supporting development. Article 24(3) makes the relationship between severe incidents and steward-provided development systems important. A steward should therefore maintain an inventory of the systems it provides for supported projects, including third-party services operated under the steward's responsibility where appropriate, so that incident responders can determine quickly whether the Article 24(3) condition is met.

• Inventory steward-provided development systems.
• Identify code and collaboration infrastructure.
• Identify build and release systems.
• Identify security-sensitive signing or publication infrastructure.
• Map systems to supported products.

Article 14(8) Brings User Communication Into the Steward Incident Context

Article 24(3) also cross-refers to Article 14(8) within the severe-incident condition stated for stewards. Article 14(8) concerns informing impacted users, and where appropriate all users, about relevant vulnerabilities or incidents and necessary risk-mitigation or corrective measures. For stewards, this duty should be read within the specific Article 24(3) condition concerning severe incidents affecting steward-provided development systems. Projects should therefore prepare communication channels capable of reaching affected users or communities where that legal trigger is met.

• Article 14(8) is expressly referenced by Article 24(3).
• User communication can become relevant.
• The steward-specific severe-incident condition still controls.
• Projects should prepare practical disclosure channels.

Voluntary Vulnerability Reporting Remains Separate

Article 24(1) requires the steward's cybersecurity policy to foster voluntary vulnerability reporting by developers under Article 15. This is separate from mandatory reporting under Article 24(3). A project can receive many vulnerability reports that never become Article 24(3) notifications because they are not known to be actively exploited or because the relevant severe-incident condition is not met. Steward processes should therefore maintain a broad vulnerability intake mechanism while adding a separate escalation decision for mandatory CRA reporting.

• Article 15 supports voluntary reporting.
• Article 24(3) creates defined mandatory triggers.
• Not every vulnerability report becomes a CRA mandatory notification.
• Escalation criteria should be documented.

Coordinate Project Security and Organisational Reporting Roles

Open-source projects often distribute security knowledge across maintainers, foundation staff, infrastructure operators and downstream companies. A steward should establish an organisational reporting owner who can collect technical facts without assuming that individual maintainers must interpret the CRA alone. Maintainers can identify exploitation, impact and remediation details, while the steward's legal or security function determines whether Article 24(3) applies and coordinates the Single Reporting Platform submission.

• Assign an organisational reporting owner.
• Keep maintainers involved in technical assessment.
• Do not place legal reporting decisions on one volunteer.
• Document escalation paths.

Preserve Evidence of Why an Event Was or Was Not Reportable

A steward should preserve a concise decision record for potentially reportable events. For an actively exploited vulnerability, record the affected product, evidence of exploitation, the steward's involvement in development and the reporting decision. For a severe incident, record the affected product, the relevant steward-provided development systems, security impact and any user-communication decision. This evidence supports consistent handling and helps the organisation explain its process if a market surveillance authority later reviews the steward's cybersecurity arrangements.

• Record the affected product.
• Record exploitation or incident evidence.
• Record development involvement.
• Record relevant steward-provided systems.
• Record the reporting conclusion.
• Record communication and remediation actions.

Build Reporting Into the Article 24 Cybersecurity Policy

The steward's Article 24 cybersecurity policy should connect vulnerability intake, incident response, development-system ownership and mandatory reporting escalation. It should identify who assesses actively exploited vulnerabilities, who determines whether a severe incident affects steward-provided development systems, who submits through the Single Reporting Platform and who communicates with affected users where Article 14(8) applies. Because the Commission and ENISA can issue further implementation guidance, the policy should include a review mechanism rather than hard-code assumptions beyond the current statutory cross-references.

• Connect reporting to vulnerability intake.
• Connect reporting to incident response.
• Assign Single Reporting Platform ownership.
• Define user-communication ownership.
• Review the process when official guidance changes.