Article 15

Stewards are legal persons that systematically support FOSS intended for commercial activities without placing it on the market (Art. 3(14), Art. 24). The guidance grades the reporting obligations by type of support: purely non-technical support, hosting the infrastructure, or active engineering contributions.

Key takeaways

• The role applies per FOSS project: the same organisation can be steward for product A and manufacturer for product B (e.g. community vs. paid edition).
• Non-technical support only (branding, governance, events, donations): no obligation to report actively exploited vulnerabilities — but share information with maintainers and consider voluntary reporting under Art. 15.
• Infrastructure steward (repos, version control, signing keys): notify ENISA/CSIRTs of severe incidents affecting product security (Art. 14(3)) and inform users where appropriate.
• Engineering steward (developers, releases, vulnerability handling): report actively exploited vulnerabilities (Art. 14(1)) and inform users (Art. 14(8)).
• Not-for-profit entities whose earnings serve not-for-profit objectives do not place their FOSS on the market even where it is monetised — steward obligations apply (Example 24: browser funded via search-engine partnerships).

The Article 14 reporting obligations apply from 11 September 2026 to all products within the CRA's scope — including products placed on the market before 11 December 2027 and products past their support period. 'Becoming aware' means reaching a reasonable degree of certainty after an immediate initial assessment — from that moment the deadlines run (24h early warning, 72h notification, 14 days / 1 month final report).

Key takeaways

• No retroactive reporting: active exploitation the manufacturer already knew about before 11 Sep 2026 is not reportable; where exploitation only becomes known afterwards, the obligation applies.
• Third-party components: only an actively exploited vulnerability that is exploitable/exploited in the manufacturer's own product is reportable — otherwise voluntary reporting (Art. 15) plus upstream reporting to the component maintainer (Art. 13(6)).
• 'Becoming aware' is deliberately aligned with the NIS 2 implementing regulation and the GDPR breach-notification guidelines.
• Informing users (Art. 14(8)) is risk-based: no indiscriminate disclosure — for sensitive environments, detailed information may be limited to affected users; broader disclosure once fixed, and mandatory disclosure of fixed vulnerabilities under Annex I Part II point (4).
• Unlike vulnerability handling, the reporting obligations continue to apply after the support period ends.

The guidance clarifies three obligations: reporting component vulnerabilities and sharing security fixes upstream (Art. 13(6)), the prohibition on placing products with known exploitable vulnerabilities on the market (Annex I Part I), and the 'effective and regular tests and reviews' (Annex I Part II point (3)) — which require input-driven review and adaptation rather than mechanical test repetition.

Key takeaways

• Upstream reporting only for the version actually integrated, following the maintainer's CVD processes; no obligation where the vulnerability is already known (avoid duplicates: check databases/advisories) or the project no longer has a maintainer.
• Only vulnerabilities in the component itself must be reported — not those arising from the manufacturer's own integration.
• Share security fixes in machine-readable, licence-compatible form; the maintainer need not accept the fix, nor must the manufacturer adopt the maintainer's fix.
• A vulnerability is 'known' when listed in relevant public databases (e.g. the European vulnerability database), disclosed via coordinated disclosure, found through the manufacturer's own testing (including AI-powered analysis), or prominently reported in reliable media — a short verification period is permissible.
• Vulnerabilities discovered shortly before release: risk-based decision on whether to postpone the release — weighed against the risks of delay (e.g. where the release also fixes other vulnerabilities).

Any person with knowledge of a vulnerability or incident — security researchers, bug bounty participants, importers, end customers. The report is made to the relevant CSIRT or directly to ENISA.

No, provided the report is made in good faith. Article 15 explicitly protects voluntary reporters from civil and criminal consequences, to the extent national law permits.

Article 15 creates the legal framework that secures bug bounty reports to authorities. Bug bounties paid by manufacturers remain unaffected; voluntary authority reporting is an additional channel.