Open-source steward readiness before the CRA reporting date

Method note. Ansvar produced this article with AI assistance under human direction and editorial review. We removed the assessed project's name, sector, organisation type, release identifiers, governance roles, technical architecture, and assessment counts. This article explains a compliance review method. It is not legal advice or a vulnerability assessment.

The Cyber Resilience Act's Article 14 reporting rules apply from 11 September 2026. For some open-source projects, Article 24 carries parts of that reporting regime to a legal person acting as an open-source software steward.

Open-source organisations now have an immediate governance task. A project needs to identify the legal person, understand the support it provides, and assign the people who will make and document a reporting decision. A security policy alone cannot answer those questions.

We tested a public-source review method against a mature open-source project supported by a legal entity. We use the de-identified case study to explain the review method without turning the project into an unwilling public example.

Start with the legal role#

Article 3(14) of the CRA defines an open-source software steward as a legal person, other than a manufacturer, that supports the development of specific free and open-source software on a sustained basis, where the software is intended for commercial activities, and ensures its viability.

That definition requires project facts. A repository owner or funding page does not settle the role on its own. Reviewers need to establish:

• which legal person supports the project;
• whether the support concerns this project or a wider community;
• whether the support includes governance, infrastructure, release work, or engineering; and
• how use intended for commercial activities fits the project's circumstances.

The Commission's open-source CRA overview describes the steward regime as tailored to legal persons that support open-source products intended for commercial activities and play a main role in keeping them viable. The Commission provided practical examples in its July 2026 guidance, but the guidance remains non-binding. A project still needs its own factual and legal analysis.

Our review recorded a plausible role hypothesis. It did not declare that the legal person was a steward.

Freeze the evidence before assessing it#

We chose one tagged release and pinned it to an exact commit. The evidence set contained the release tree, the current security policy, public governance documents, current role records, and official EU legal texts.

Freezing the target kept us from making a common error. A project can improve its policy on its main branch while users of the stable source archive still receive an older copy. Comparing an old release against today's repository without naming both states would blur that difference.

Our team confirmed such a mismatch. The stable source archive carried outdated support information, while the current branch described a newer policy and reporting process. We treated this as a release-documentation issue. We did not present it as evidence of poor vulnerability handling.

Maintainers can address this class of problem by pointing each release page to one maintained policy and stating which copy governs.

Separate evidence gaps from missing processes#

Public repositories may omit the full operating procedure for a legal or regulatory response. A reviewer who finds no public Article 14 runbook cannot conclude that the project has no internal runbook.

We used three evidence states:

Reviewers who use these terms avoid overstating the case. Maintainers can close an open fact with evidence. Counsel can disagree with the role analysis without first correcting an accusation that the project never made.

Map Article 24 before building a reporting process#

Article 24 gives qualifying open-source software stewards a tailored set of duties. It requires a cybersecurity policy and documentation that a reviewer can verify, along with cooperation with market-surveillance authorities. Paragraph 3 connects stewards to parts of Article 14 under two conditions:

1. The actively exploited vulnerability reporting duty applies to the extent that the steward participates in development.
2. The severe-incident and user-notice duties apply to the extent that the incident affects network and information systems the steward provides for development.

Those conditions make the support model part of the compliance record. A legal person that supplies administrative support may face a different Article 24(3) analysis from one that manages release engineering or project development systems.

The CRA applies Article 14 from 11 September 2026. Its main obligations apply from 11 December 2027. The Commission confirmed those dates in its July 2026 implementation guidance notice.

Build the decision path before an incident#

A project can prepare without publishing sensitive incident procedures. The minimum internal record should answer these questions:

1. Who decides whether the legal person qualifies as the steward for this project?
2. Who determines whether the steward's support triggers an Article 24(3) reporting branch?
3. Who records awareness, starts the applicable clock, and submits through the required reporting route?
4. Which development systems does the steward provide, and who classifies a severe incident affecting them?
5. Who can assemble the cybersecurity-policy evidence requested by a market-surveillance authority?

The answers can stay private. The organisation should record them in a form it can test, approve, and retrieve under time pressure.

Make the assessment refuse unsupported conclusions#

We used an AI agent to collect evidence, map clauses, and construct a technical threat model. Human reviewers approved the scope and challenged the output against the frozen evidence.

The reviewers enforced four boundaries:

• no project identity or legal status inferred from a repository label;
• no vulnerability claim without technical validation;
• no CVE attached without evidence that it affected the frozen target; and
• no claim that an internal process was absent because it was not public.

The independent reviewer found public evidence that narrowed two open questions and a scoring rule applied in some rows but not others. We corrected the evidence map and the affected distribution. The correction record matters more than a polished first draft because it identifies the errors and their effects.

The useful output is an evidence packet#

The final internal packet joined the legal role analysis to operational evidence. It contained a clause map, an evidence manifest, an Article 14 tabletop, and a record of project facts that required confirmation.

That packet gives a supporting organisation a manageable review task. Counsel can decide the legal role. Maintainers can correct project facts. Security staff can test the reporting path. Each person reviews the part that requires their judgment.

Ansvar supports this kind of work by retrieving the current legal provisions, preserving their citations, and keeping unsupported conclusions out of the report. Your own agent remains the working interface.

Try this prompt with an agent connected to Ansvar:

Using Ansvar, assess whether our organisation could qualify as an open-source software steward under CRA Article 3(14). Cite the primary legal sources, separate confirmed facts from missing facts, and map the conditional duties in Article 24.

Start with the Ansvar quickstart, or read the official Cyber Resilience Act before you build the review.