I Read the EU's 75-Page CRA Draft Guidance. Here's What Open Source Stewards Should Worry About.

This week I sat down with the European Commission’s draft guidance for the Cyber Resilience Act - 75 pages of legal text explaining how the CRA applies to open source software. I reviewed it as a volunteer with the FreeBSD Foundation’s CRA readiness effort, coordinating through the ORC Working Group.

The CRA entered into force in December 2024. Full requirements kick in December 2027. Reporting obligations start September 2026, that is, six months from now. The draft guidance is the EC’s attempt to clarify the grey areas before the deadlines hit. The consultation is open until March 31, and I think every open source foundation should be paying attention to it.

I found 4 gaps that concern me. Not obscure edge cases - structural problems that affect how stewards operate.

The steward definition doesn’t match how foundations actually work

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.

This sounds like an internal detail, but it’s not. If the guidance makes “publishing” central to the steward definition, foundations that support without publishing could fall outside the definition entirely. That would be absurd: the FreeBSD Foundation, the Apache Software Foundation, the Python Software Foundation - they’re all structured this way. They steward the project without being the publisher.

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: if publishing becomes the test, the Foundation could end up OUTSIDE the steward classification. Which would mean no obligations, but also no recognized role in the CRA framework. Not great for anyone.

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 doesn’t manage it. The security team is part of the Project’s governance. I updated the comment. Small detail, but it matters when you’re trying to explain how a foundation works to regulators who may not know the difference.

Nobody knows when the clock starts for stewards

This is the finding that surprised me most, and from what I hear, it hasn’t been discussed much yet.

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: “becoming aware” with a “reasonable degree of certainty.” The problem is that every word of that explanation is framed around manufacturers and “its product.”

A steward doesn’t have “a product.” The FreeBSD Foundation supports software that runs in thousands of products made by other organizations. When a vulnerability is discovered in FreeBSD, which product triggers the clock? Who is “aware” - the volunteer security team, the Foundation staff member on that team, the Foundation as an organization?

The guidance simply doesn’t address this. 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 concern. But as of today, there’s no guidance at all for stewards on this point.

I think this is the gap most likely to cause real operational problems. A foundation that guesses wrong about when the clock starts could either over-report (flooding ENISA with premature notifications) or under-report (missing the 24-hour window). Neither is good.

The three-tier steward model is vague

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.

The problem: real foundations don’t fit neatly into one tier. The FreeBSD Foundation provides IT infrastructure AND employs developers AND coordinates engineering work. That’s at least two tiers, arguably all three. The guidance doesn’t say what happens when a single entity spans multiple tiers. Are the obligations cumulative? Does the most demanding tier apply?

At the ORC WG meeting on March 18, someone called the three-tier model “nebulous.” I think that’s accurate. The concept isn’t wrong - different foundations have different capabilities - but the boundaries need work.

Upstream reporting needs a deduplication step

This one is more practical. 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 - good. But there’s no guidance telling manufacturers to check if a vulnerability is already known upstream before filing a new report.

For a project like FreeBSD that gets embedded in a lot of products, this could mean dozens of manufacturers independently reporting the same vulnerability. The security team (volunteers, remember) would spend more time triaging duplicate reports than fixing the actual problem.

I left a comment suggesting the guidance add a step: verify with the upstream project whether the vulnerability is already known before filing a new report. Simple, but it needs to be written down.

What I’m doing about it

I’m not writing this as a policy expert. I’m a compliance practitioner with 16 years in IT governance (IBM, Kyndryl) who also happened to maintain an open source project for 9 years. I think that combination is useful here: I understand both the regulatory framework and what it’s like to be the person who gets the vulnerability report at 11 PM.

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

The guidance is a draft. It can change. But only if the people who understand how open source actually works tell the EC where the gaps are.

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