CRA Draft Guidance and Open Source Stewards

I reviewed the European Commission’s draft guidance for the Cyber Resilience Act as part of the FreeBSD Foundation’s CRA readiness work, coordinating through the ORC Working Group. The document is meant to clarify how the CRA applies to open source software and open source stewards.

The CRA entered into force in December 2024. Full requirements apply in December 2027, and reporting obligations start in September 2026. The draft guidance is the Commission’s attempt to narrow some of the grey areas before those deadlines arrive. The consultation was originally open until March 31 and has since been extended to April 13.

Four points stood out because they affect how foundations describe their role and how they would operationalize the CRA.

Steward definition and publication

Paragraph 46 of the guidance frames steward responsibility around “publishing” open source software and “exercising primary control.” The FreeBSD Foundation meets every criterion in Article 19 of the CRA for being a steward: sustained support, funding infrastructure, employing developers, ensuring the project’s viability. But the Foundation does not publish FreeBSD. The Project publishes. Release engineering is handled by volunteers. The Foundation provides staff support and infrastructure, but governance and releases are separate.

If the guidance makes “publishing” central to the steward definition, foundations that support a project without publishing it could fall outside the definition entirely. The FreeBSD Foundation is not unusual in that respect, and the same general pattern exists in other project foundations where governance, release engineering, and institutional support are split across different bodies.

I wrote a comment on the ORC WG’s shared review document explaining the FreeBSD example. Alice Sowerby from the Foundation raised the complementary point that, if publishing becomes the test, the Foundation could end up outside the steward classification. That would leave a gap between the role foundations play in practice and the role recognized by the CRA framework.

One thing I got wrong initially: I stated that the Foundation “manages the security team.” Anne Dickison (Deputy Director) corrected me. The Foundation has a staff member on the security team but does not manage it; the security team is part of the Project’s governance. I updated the comment because that distinction matters when describing how a foundation and a project relate to each other.

When reporting obligations start for stewards

Article 14 of the CRA requires reporting actively exploited vulnerabilities within 24 hours and full notification within 72 hours. Paragraphs 193-196 of the guidance explain when the clock starts, using the language of “becoming aware” with a “reasonable degree of certainty.” That explanation is framed around manufacturers and “its product.”

A steward does not necessarily have a single product in that sense. The FreeBSD Foundation supports software that runs in many products made by other organizations. When a vulnerability is discovered in FreeBSD, it is not obvious which product starts the clock, or who counts as “aware”: the volunteer security team, the Foundation staff member on that team, or the Foundation as an organization.

The guidance does not address that situation directly. I left a comment on the Google Doc at paragraphs 193-195. Juan from the Eclipse Foundation created issue #261 in the ORC WG repo with proposed text that aligns closely with the same concern.

A foundation that gets this wrong could end up over-reporting to ENISA with premature notifications or under-reporting and missing the 24-hour window. Neither outcome is clearly addressed for stewards in the current draft.

Three-tier steward model

Paragraphs 76-79 introduce three tiers of stewards based on their capabilities: non-technical foundations, IT infrastructure providers, and organizations with engineering resources. Your tier determines your obligations, including whether Article 14’s 24-hour/72-hour reporting is mandatory.

Real foundations do not fit neatly into one tier. The FreeBSD Foundation provides IT infrastructure, employs developers, and coordinates engineering work. The guidance does not say what happens when one entity spans multiple tiers. It is not clear whether the obligations are cumulative or whether the highest tier governs the whole organization.

At the ORC WG meeting on March 18, someone called the three-tier model “nebulous.” Different foundations do have different capabilities, but the boundaries between the tiers are still hard to apply.

Upstream reporting and duplicate reports

Article 13(6) requires manufacturers to report vulnerabilities in integrated components upstream and share fixes. Paragraph 205 already says manufacturers should follow the maintainer’s guidelines. The guidance does not tell manufacturers to verify whether a vulnerability is already known upstream before filing a new report.

For a project like FreeBSD, which is embedded in many downstream products, that could mean multiple manufacturers independently reporting the same vulnerability. The security team would spend time triaging duplicate reports instead of working on the underlying issue.

I left a comment suggesting that the guidance add an explicit verification step: check with the upstream project whether the vulnerability is already known before filing a new report.

Current feedback process

All the feedback is going through the ORC WG’s formal channels - GitHub issues and the Cyber Resilience SIG meetings. The consultation deadline has been extended to April 13, 2026. If you work with or for an open source foundation, there’s still time to read the draft and comment. The ORC WG’s cra-hub repository has the full text and the process for submitting feedback.

Sources and references:

• CRA draft guidance (ORC WG cra-hub)
• ORC WG feedback issues (parent tracking issue)
• FreeBSD Foundation CRA readiness project
• EU Cyber Resilience Act - full text

Antenore Gatta

A proud and busy Hacker, Father and Kyndrol

Post comment