CRA: are open-source software stewards required to report from 11 September 2026?

Berlin, 9 September 2026

Update of 9 September 2026, evening: ENISA revised its Single Reporting Platform FAQ today. Answers 27, 29 and 30 – two of them new – now state that the reporting obligations of open-source software stewards under Article 24(3) apply from 11 December 2027, and that the platform currently accepts mandatory notifications from manufacturers only; anyone else is directed to the competent national CSIRT and may see a submission marked as invalid. The agency that operates the reporting platform has thus adopted the reading of FAQ section 5.5, and the national market surveillance authorities are likely to follow. The two readings set out below stand as published; what has changed is the practical outlook – and the status question under heading 1 becomes more important rather than less.

Two days before the reporting obligations of the Cyber Resilience Act take effect, the position for open-source software stewards has become unsettled. On 4 September 2026 the European Commission updated its CRA implementation FAQ to version 1.4. The only change in that version is a new section 5.5, which states that the reporting obligations extended to stewards by Article 24(3) apply from 11 December 2027. ENISA's factsheet on the Single Reporting Platform, by contrast, names manufacturers and open-source software stewards together under 11 September 2026 and draws no distinction as to the deadlines – the agency's Single Reporting Platform FAQ, however, was aligned with the Commission's reading later the same day (see the update above).

Two separate questions follow for any organisation that supports open-source development. They are regularly merged, and only the second of them is genuinely open.

1. Are you an open-source software steward at all?

Article 3(14) CRA requires three conditions cumulatively: a legal person; not a manufacturer within the meaning of Article 3(13); and systematic and sustained support for the development of free and open-source software intended for commercial activities, including ensuring its viability. In the reviews we have run it is the second condition that fails, and it usually fails for reasons the organisation had not connected with the CRA at all.

  • Release model and supply channels. Who hands the compiled binary to the end user – the organisation itself, through its own website, package repositories or installers, or exclusively vendors and members? Hosting a repository is not placing a product on the market; shipping an installer under your own name may well be.
  • Licence terms. Article 3(48) requires the source code to be openly shared and licensed so that it may be freely accessed, used, modified and redistributed. A discretionary right of termination, an obligation to destroy copies, or “fair and reasonable terms” in place of a named open-source licence each defeat that qualification.
  • Membership-gated source access. Source code for members and binaries for everyone is the most frequent finding of all. It goes to the FOSS qualification, and therefore arises before any question of manufacturer status.
  • Own name or mark. A mark registered for software and carried on the component itself, together with a commercial activity, is what makes an organisation a manufacturer under Article 3(13). The two elements are cumulative – branding alone does not suffice, and trademark governance is expressly listed among the tasks typical of a steward.
  • Contributor and vendor IP arrangements. Whether the chain of rights is royalty-free and perpetual, or whether royalties or an election right for implementation-necessary patents remain in place.

Two points of method matter here. The status is to be established per project or repository and not once for the entity, as the Commission's guidance sets out; a register of projects with licence, publicity, commercial purpose and depth of support is the workable instrument, and it has to be kept current. And where steward status is not made out, the organisation is a manufacturer for that component: Article 14 then applies to it from 11 September 2026 directly, without any cross-reference and without any date question.

What this looks like in practice – six findings from our reviews

The examples are anonymised and drawn from different mandates. In each case the organisation had a settled view of its own status; in five of the six the review changed it.

  • Example 1 – supply under the organisation's own name. A consortium published its reference implementation on its own website as a signed installer carrying its registered word mark. Repository hosting alone would have been neutral; supply under its own name, alongside paid membership, made it the manufacturer for that component.
  • Example 2 – source for members only. A foundation licensed the source code to members only while the binaries were free to everyone. The analysis stopped at Article 3(48): without free access to the source there is no free and open-source software, and therefore no steward status to consider.
  • Example 3 – a royalty-bearing patent election. An IPR policy allowed contributors to elect royalty-bearing terms for implementation-necessary patents. The chain of rights was not royalty-free, so redistribution was not free in the sense required – a licensing problem that no cybersecurity measure can cure.
  • Example 4 – termination rights in the licence. A licence reserved a discretionary right of termination and obliged users to destroy their copies, while the project described itself as open source throughout – terms incompatible with the permanent, irrevocable grant that open-source licensing requires. In another case the public repository carried no licence file at all.
  • Example 5 – a conformance mark plus own supply. A conformance programme operated a private mark with a public register. The mark alone did not create manufacturer status – trade mark governance is expressly a steward task – but combined with the organisation's own supply of the test tool it did, for that tool.
  • Example 6 – status confirmed. Source public under a named open-source licence, distribution exclusively through vendors, no supply under the organisation's own name. Steward status was established, documented per project, and that organisation has nothing to file before December 2027.

The pattern is consistent: what decides the outcome is rarely the cybersecurity posture but the licensing and distribution arrangements – documents drafted years earlier for entirely different reasons. Where the status does hold, the extent of the duties still depends on the depth of involvement: non-technical support alone triggers none, providing the development infrastructure triggers reporting for that infrastructure, and own development resources trigger the full extension of Article 24(3).

2. If you are a steward, from when must you report?

This is the question the new FAQ entry has unsettled, and both readings are defensible.

On the reading in section 5.5, Article 24(3) is the operative source of the steward's duty. Article 71(2) advances only Chapter IV and Article 14, and Article 24 is not among them; Article 14(1) addresses “a manufacturer”, whereas Article 3(14) defines a steward as a legal person “other than a manufacturer”. The duty therefore cannot be located in Article 14 itself and follows the date of Article 24, namely 11 December 2027.

On the reading we had taken, Article 71(2) advances “Article 14” as a provision rather than a class of addressees. Article 24(3) creates no duty of its own: it extends the obligations “laid down in Article 14(1)”, which locates the obligation in Article 14 and leaves Article 24(3) as an extension of its personal scope, travelling with the provision that is advanced. Three points support this. Article 69(3) addresses the temporal reach of Article 14 separately and broadly. Articles 14 to 16 form a single reporting architecture that goes live as a unit on 11 September 2026, and the components most likely to surface an actively exploited vulnerability are precisely the open-source ones. And Article 64(10)(b) exempts stewards only from the fines of paragraphs 3 to 9, so that Article 64(2), which covers Article 14, remains applicable to them.

Three things are worth knowing about the status of the entry. It is new, published on 4 September 2026. It is expressly non-binding: the FAQ is prepared by the Commission services, does not represent the official position of the Commission, neither extends nor reduces rights and obligations, and cannot prejudge an interpretation by the Court of Justice. And enforcement is national: under the German CRA implementing act the market surveillance authority is the BSI, which refers questions of law and administrative practice to the Federal Ministry of the Interior – and the ministry, in reply to our enquiry, pointed us to precisely the ENISA material that drew no distinction as to timing – material that has since been changed, so that the national position is likely to move with it.

We have put the question to both the ministry and ENISA and will report the answers here.

What this means in practice

  • Settle the status question first. Whether the date is contested at all depends on it. Where steward status is not established for a project, the obligation applies through the manufacturer route from 11 September 2026 in any event.
  • Establish reporting readiness by 11 September 2026. A named security contact with a deputy, a working reporting address, a documented decision path within 24 hours, registration on the reporting platform. The cost of holding that in place is low; the exposure under Article 64(2) is up to EUR 15 million or 2.5 % of worldwide annual turnover.
  • Keep the FAQ version on file. Section 5.5 in version 1.4 of 4 September 2026 is material for the defence of an individual case – it is not a basis on which to move a compliance date.
  • Track the changes. The FAQ is a living document. ENISA aligned its Single Reporting Platform FAQ on 9 September 2026; whether the factsheet follows remains to be seen.

Provisions

  • Article 3(13), (14), (48) CRA – manufacturer, open-source software steward, free and open-source software
  • Article 14 CRA – reporting obligations, deadlines of 24 hours, 72 hours, 14 days and one month
  • Article 24 CRA – obligations of open-source software stewards, extension of the reporting duties in paragraph 3
  • Article 64 CRA – administrative fines, paragraph 2 and the limited exemption in paragraph 10(b)
  • Article 71(2) CRA – application from 11 December 2027, Article 14 from 11 September 2026, Chapter IV from 11 June 2026

More on the CRA

About SES Berlin

SES Berlin is a firm of lawyers and civil-law notaries based in Berlin. Our IT and technology practice advises manufacturers, importers, consortia, standards organisations and open-source bodies on the Cyber Resilience Act – from classification as manufacturer or steward, through licensing and contribution frameworks, to disclosure policy, reporting workflow and governance. Roman Ronneburger, Rechtsanwalt and specialist lawyer for copyright and media law, leads the firm's CRA work and advises international consortia on their European product-security obligations. We work project by project, document each classification so that it can be relied on, and deliver the instruments that follow from it.

We review steward status per project and put the reporting readiness in place – licensing, disclosure policy, reporting workflow and governance. Your contact: Roman Ronneburger, or through our contact page.

CRA: are open-source software stewards required to report from 11 September 2026?

Berlin, 9 September 2026

Update of 9 September 2026, evening: ENISA revised its Single Reporting Platform FAQ today. Answers 27, 29 and 30 – two of them new – now state that the reporting obligations of open-source software stewards under Article 24(3) apply from 11 December 2027, and that the platform currently accepts mandatory notifications from manufacturers only; anyone else is directed to the competent national CSIRT and may see a submission marked as invalid. The agency that operates the reporting platform has thus adopted the reading of FAQ section 5.5, and the national market surveillance authorities are likely to follow. The two readings set out below stand as published; what has changed is the practical outlook – and the status question under heading 1 becomes more important rather than less.

Two days before the reporting obligations of the Cyber Resilience Act take effect, the position for open-source software stewards has become unsettled. On 4 September 2026 the European Commission updated its CRA implementation FAQ to version 1.4. The only change in that version is a new section 5.5, which states that the reporting obligations extended to stewards by Article 24(3) apply from 11 December 2027. ENISA's factsheet on the Single Reporting Platform, by contrast, names manufacturers and open-source software stewards together under 11 September 2026 and draws no distinction as to the deadlines – the agency's Single Reporting Platform FAQ, however, was aligned with the Commission's reading later the same day (see the update above).

Two separate questions follow for any organisation that supports open-source development. They are regularly merged, and only the second of them is genuinely open.

1. Are you an open-source software steward at all?

Article 3(14) CRA requires three conditions cumulatively: a legal person; not a manufacturer within the meaning of Article 3(13); and systematic and sustained support for the development of free and open-source software intended for commercial activities, including ensuring its viability. In the reviews we have run it is the second condition that fails, and it usually fails for reasons the organisation had not connected with the CRA at all.

  • Release model and supply channels. Who hands the compiled binary to the end user – the organisation itself, through its own website, package repositories or installers, or exclusively vendors and members? Hosting a repository is not placing a product on the market; shipping an installer under your own name may well be.
  • Licence terms. Article 3(48) requires the source code to be openly shared and licensed so that it may be freely accessed, used, modified and redistributed. A discretionary right of termination, an obligation to destroy copies, or “fair and reasonable terms” in place of a named open-source licence each defeat that qualification.
  • Membership-gated source access. Source code for members and binaries for everyone is the most frequent finding of all. It goes to the FOSS qualification, and therefore arises before any question of manufacturer status.
  • Own name or mark. A mark registered for software and carried on the component itself, together with a commercial activity, is what makes an organisation a manufacturer under Article 3(13). The two elements are cumulative – branding alone does not suffice, and trademark governance is expressly listed among the tasks typical of a steward.
  • Contributor and vendor IP arrangements. Whether the chain of rights is royalty-free and perpetual, or whether royalties or an election right for implementation-necessary patents remain in place.

Two points of method matter here. The status is to be established per project or repository and not once for the entity, as the Commission's guidance sets out; a register of projects with licence, publicity, commercial purpose and depth of support is the workable instrument, and it has to be kept current. And where steward status is not made out, the organisation is a manufacturer for that component: Article 14 then applies to it from 11 September 2026 directly, without any cross-reference and without any date question.

What this looks like in practice – six findings from our reviews

The examples are anonymised and drawn from different mandates. In each case the organisation had a settled view of its own status; in five of the six the review changed it.

  • Example 1 – supply under the organisation's own name. A consortium published its reference implementation on its own website as a signed installer carrying its registered word mark. Repository hosting alone would have been neutral; supply under its own name, alongside paid membership, made it the manufacturer for that component.
  • Example 2 – source for members only. A foundation licensed the source code to members only while the binaries were free to everyone. The analysis stopped at Article 3(48): without free access to the source there is no free and open-source software, and therefore no steward status to consider.
  • Example 3 – a royalty-bearing patent election. An IPR policy allowed contributors to elect royalty-bearing terms for implementation-necessary patents. The chain of rights was not royalty-free, so redistribution was not free in the sense required – a licensing problem that no cybersecurity measure can cure.
  • Example 4 – termination rights in the licence. A licence reserved a discretionary right of termination and obliged users to destroy their copies, while the project described itself as open source throughout – terms incompatible with the permanent, irrevocable grant that open-source licensing requires. In another case the public repository carried no licence file at all.
  • Example 5 – a conformance mark plus own supply. A conformance programme operated a private mark with a public register. The mark alone did not create manufacturer status – trade mark governance is expressly a steward task – but combined with the organisation's own supply of the test tool it did, for that tool.
  • Example 6 – status confirmed. Source public under a named open-source licence, distribution exclusively through vendors, no supply under the organisation's own name. Steward status was established, documented per project, and that organisation has nothing to file before December 2027.

The pattern is consistent: what decides the outcome is rarely the cybersecurity posture but the licensing and distribution arrangements – documents drafted years earlier for entirely different reasons. Where the status does hold, the extent of the duties still depends on the depth of involvement: non-technical support alone triggers none, providing the development infrastructure triggers reporting for that infrastructure, and own development resources trigger the full extension of Article 24(3).

2. If you are a steward, from when must you report?

This is the question the new FAQ entry has unsettled, and both readings are defensible.

On the reading in section 5.5, Article 24(3) is the operative source of the steward's duty. Article 71(2) advances only Chapter IV and Article 14, and Article 24 is not among them; Article 14(1) addresses “a manufacturer”, whereas Article 3(14) defines a steward as a legal person “other than a manufacturer”. The duty therefore cannot be located in Article 14 itself and follows the date of Article 24, namely 11 December 2027.

On the reading we had taken, Article 71(2) advances “Article 14” as a provision rather than a class of addressees. Article 24(3) creates no duty of its own: it extends the obligations “laid down in Article 14(1)”, which locates the obligation in Article 14 and leaves Article 24(3) as an extension of its personal scope, travelling with the provision that is advanced. Three points support this. Article 69(3) addresses the temporal reach of Article 14 separately and broadly. Articles 14 to 16 form a single reporting architecture that goes live as a unit on 11 September 2026, and the components most likely to surface an actively exploited vulnerability are precisely the open-source ones. And Article 64(10)(b) exempts stewards only from the fines of paragraphs 3 to 9, so that Article 64(2), which covers Article 14, remains applicable to them.

Three things are worth knowing about the status of the entry. It is new, published on 4 September 2026. It is expressly non-binding: the FAQ is prepared by the Commission services, does not represent the official position of the Commission, neither extends nor reduces rights and obligations, and cannot prejudge an interpretation by the Court of Justice. And enforcement is national: under the German CRA implementing act the market surveillance authority is the BSI, which refers questions of law and administrative practice to the Federal Ministry of the Interior – and the ministry, in reply to our enquiry, pointed us to precisely the ENISA material that drew no distinction as to timing – material that has since been changed, so that the national position is likely to move with it.

We have put the question to both the ministry and ENISA and will report the answers here.

What this means in practice

  • Settle the status question first. Whether the date is contested at all depends on it. Where steward status is not established for a project, the obligation applies through the manufacturer route from 11 September 2026 in any event.
  • Establish reporting readiness by 11 September 2026. A named security contact with a deputy, a working reporting address, a documented decision path within 24 hours, registration on the reporting platform. The cost of holding that in place is low; the exposure under Article 64(2) is up to EUR 15 million or 2.5 % of worldwide annual turnover.
  • Keep the FAQ version on file. Section 5.5 in version 1.4 of 4 September 2026 is material for the defence of an individual case – it is not a basis on which to move a compliance date.
  • Track the changes. The FAQ is a living document. ENISA aligned its Single Reporting Platform FAQ on 9 September 2026; whether the factsheet follows remains to be seen.

Provisions

  • Article 3(13), (14), (48) CRA – manufacturer, open-source software steward, free and open-source software
  • Article 14 CRA – reporting obligations, deadlines of 24 hours, 72 hours, 14 days and one month
  • Article 24 CRA – obligations of open-source software stewards, extension of the reporting duties in paragraph 3
  • Article 64 CRA – administrative fines, paragraph 2 and the limited exemption in paragraph 10(b)
  • Article 71(2) CRA – application from 11 December 2027, Article 14 from 11 September 2026, Chapter IV from 11 June 2026

More on the CRA

About SES Berlin

SES Berlin is a firm of lawyers and civil-law notaries based in Berlin. Our IT and technology practice advises manufacturers, importers, consortia, standards organisations and open-source bodies on the Cyber Resilience Act – from classification as manufacturer or steward, through licensing and contribution frameworks, to disclosure policy, reporting workflow and governance. Roman Ronneburger, Rechtsanwalt and specialist lawyer for copyright and media law, leads the firm's CRA work and advises international consortia on their European product-security obligations. We work project by project, document each classification so that it can be relied on, and deliver the instruments that follow from it.

We review steward status per project and put the reporting readiness in place – licensing, disclosure policy, reporting workflow and governance. Your contact: Roman Ronneburger, or through our contact page.