The Cyber Resilience Act distinguishes between manufacturers who place products on the market in a commercial activity and open-source software stewards who support development without being manufacturers themselves. Art. 3(14) defines an open-source software steward as a legal person, other than a manufacturer, that systematically supports the development of specific products qualifying as free and open-source software intended for commercial activities and ensures their viability. Recital 19 clarifies the scope: foundations, entities that develop and publish FOSS in a business context, and not-for-profit entities steering development of commercially intended software. The regime under Art. 24 is intentionally light: a documented cybersecurity policy (Art. 24(1)), cooperation with market surveillance authorities (Art. 24(2)), and partial Art. 14 reporting obligations (Art. 24(3)). Critically, Art. 64(10)(b) exempts open-source software stewards from administrative fines for any CRA infringement. CRACheck generates documentation structured under Art. 31 and Annex VII for manufacturers integrating your components. €149 per product. 15-25 minutes.
€149 one-time · 8-document ZIP · 15–25 minutes · Browser-side
The CRA exempts individual contributors (Recital 18) and non-commercial FOSS. But Art. 3(14) creates the steward category specifically for legal persons that support commercially intended FOSS. If your foundation stewards a project that manufacturers routinely integrate into commercial products, Art. 24 applies to you — even though fines do not.
If your organisation develops the product and markets it under its own name — even free of charge — Recital 18 of Regulation (EU) 2024/2847 may classify you as manufacturer under Art. 3(13) if the activity is commercial. Monetisation through enterprise licensing, paid support, or SaaS deployment of the same codebase can trigger manufacturer status with full Art. 13 obligations.
Art. 24(3) applies Art. 14(1) — vulnerability notification to ENISA — to stewards involved in the development. If you maintain the repository, merge security patches, and manage releases, you are involved. The 24h early warning and subsequent notifications apply from 11 September 2026.
8 PDF documents generated from your data. Each cites the specific article of Regulation (EU) 2024/2847 it complies with.
Identifies the CRA category for the product your FOSS component is integrated into. Stewards do not classify their own components, but downstream manufacturers need this to determine their conformity assessment route.
Art. 31 and Annex VII documentation for the end product. Stewards do not produce this, but CRACheck helps the manufacturers who integrate your component to document how that component fits into their overall product documentation.
Cybersecurity risk assessment per Art. 13(2)-(3). Downstream manufacturers must include FOSS components in their risk assessment. CRACheck structures that inclusion.
Annex II user information. The manufacturer of the end product provides this — not the steward.
EU Declaration per Art. 28 and Annex V. Only manufacturers issue this. Stewards cannot affix CE marking (Recital 19).
Coordinated vulnerability disclosure policy. Stewards need their own cybersecurity policy under Art. 24(1). CRACheck structures the CVD component that downstream manufacturers reference.
ENISA notification template per Art. 14. Relevant to stewards under Art. 24(3) for actively exploited vulnerabilities in the component they steward.
Key dates: Art. 14 partial reporting from September 2026, full CRA enforcement December 2027, Art. 25 voluntary security attestation programmes.
See before you buy — Download sample dossier (PDF, fictional company) — Real structure, real articles, real format. Fictional data.
Generated from your data, in your browser. No data leaves your device.