CRA for open-source maintainers: who carries obligations

Do open-source maintainers and contributors carry Cyber Resilience Act obligations?

Obligations depend on who publishes the software and controls its releases and distribution, not on who wrote the code. Under the Commission's guidance on applying the regulation (Annex to C(2026) 5252, section 3), responsibility for free and open-source software sits with the maintainers who publish it and control releases and distribution. Contributors who submit pull requests or hold commit access without that control are not subject to the regulation. The definition behind this test is in Article 3(48), which describes free and open-source software as software whose source code is openly shared under a license granting the rights to freely access, use, modify and redistribute it. Code shared only with paying customers or a limited group does not qualify, according to the same guidance.

Being free of charge is not the whole test, and money changes the analysis in specific ways. Free and open-source software that is not monetized is not placed on the market. Donations made without intent to make a profit are unlikely to place software on the market, unless access to the software, its essential features or its updates is in practice conditioned on donating. Third-party funding, sponsorship and paid development work do not by themselves place free software on the market, and not-for-profit organizations that use all earnings after costs for not-for-profit objectives do not place their software on the market either. Maintainers and foundations should check whether any paid tier, gated download or update condition exists, because that is where the answer can change.

Foundations and companies that give sustained support to specific open-source software intended for commercial activities need a separate review. The guidance (section 3.3) treats them as stewards for those projects, and a legal person that publishes a free community version and a monetized version is a steward for the first and a manufacturer of the second. Stewards carry a lighter regime, including the Article 24 reporting duties that apply from 11 December 2027, and Article 64(10)(b) excludes administrative fines for infringements by open-source software stewards. The organization remains responsible for its own compliance decisions, and any conformity report or certificate must come from an independent assessor or certification body, not from a consultant or implementation partner. Confirm your status against the Commission guidance before publishing a commercial edition.

Who is responsible for a FOSS project under the CRA?

A maintainer who publishes a FOSS project and controls its releases and distribution is the party the Commission guidance (C(2026) 5252, section 3) places responsibility on for that software. Publishing openly without monetization generally means the software is not placed on the market, so the CRA's manufacturer duties do not attach by default. Whether that holds depends on the facts of each project, including whether access, essential features or updates are in practice conditioned on payment or donations.

Release control: The person or group that publishes builds and decides what ships is the party the guidance points to.
Donations: Donations without intent to make a profit are unlikely to place the software on the market, unless access, essential features or updates are in practice conditioned on donating.
Sponsorship: Third-party funding or paid development work does not by itself place the software on the market.
Commercial reuse: A maintainer who later sells the software or a supported version may move into a manufacturer role.
Stewardship: Systematic support for FOSS intended for commercial activities can make a legal person a steward, which is a different role from manufacturer.

Before relying on the open-source position, confirm with counsel how the guidance applies to your specific funding and distribution arrangements, and keep a written record of who controls releases.

Do donations, sponsorship and paid development make FOSS a regulated product?

Donations, sponsorship and paid development do not by themselves make free and open-source software a product placed on the market. The Commission's guidance (C(2026) 5252, section 3.2.4) says donations made without intent to make a profit are unlikely to place FOSS on the market. The exception is narrower than it sounds: it applies when access to the software, its essential features or its updates is in practice conditioned on donating. The guidance also says third-party funding, sponsorship and paid development work do not by themselves place FOSS on the market (sections 3.2.5 and 3.2.6), and that a not-for-profit organization using all earnings after costs for not-for-profit objectives does not place its FOSS on the market either. Those points are the starting position, not a safe harbor for every arrangement.

Consider two hypothetical projects, both described for illustration only. Project A accepts donations through a button on its website, publishes every release to everyone at no charge, and has no paid tier. Project B offers the same code freely, but security patches reach users only after a paid subscription starts. Project A's donations look like general support, and the guidance treats that as unlikely to place the software on the market. Project B has tied a safety-relevant update to payment, which is the kind of conditioning the exception describes. Whether that conditioning is in practice real depends on the facts: what the project publishes, to whom, and whether non-paying users can get the same fixes on the same terms.

The answer depends on facts about each project, so document your reasoning before a regulator or a downstream customer asks. Record who publishes releases, who controls distribution, how donations and sponsorship are received and spent, whether any feature, update or support route depends on payment, and how earnings are used if you are a not-for-profit. Confirm each point against the current guidance text, and revisit the record when funding or distribution changes. Where the answer is unclear, ask a qualified legal adviser to review the file rather than relying on a single reading of the guidance.

How not-for-profit organizations and foundations are treated

Foundations and not-for-profit bodies often host open-source projects, so their exposure depends on how the software is funded, who controls releases and whether they support projects for commercial use. The cards below separate the cases the Commission guidance addresses and mark the points that need confirmation with counsel.

Not-for-profit organizations that publish FOSS

Under the Commission guidance (section 3.2.6), a not-for-profit organization that uses all earnings after costs for its not-for-profit objectives does not place its FOSS on the market. This is the cleanest route for a project hosted by a charity or association. Check that the earnings rule is written into the organization's governing documents and that no part of the software is sold or gated behind payment. Ask counsel to confirm how the earnings test applies to mixed revenue, such as paid training or event income.

Foundations giving sustained support

The guidance (section 3.3) states that a foundation giving sustained support to specific FOSS intended for commercial activities is a steward for those projects. Stewardship is a status tied to the support pattern, not to the foundation's legal form. Record which projects receive sustained support, what that support includes (hosting, security processes, release engineering or funding) and whether it is intended to serve commercial use. These records show whether a foundation has crossed the line.

Free community version and paid version

A legal person that publishes a free community version and a monetized version is a steward for the first and the manufacturer of the second, according to section 3.3 of the guidance. The same organization can hold both roles at once. Map each release line, licence, distribution channel and paid feature set separately, because the obligations attach to the product actually placed on the market. Ask counsel where the boundary falls for features that are open in one edition and paywalled in another.

Systematic support under Article 3(14)

Article 3(14) describes legal persons that systematically support FOSS intended for commercial activities. Systematic support is what distinguishes a steward from a body that merely accepts occasional sponsorship. Document recurring commitments such as staffed maintenance, scheduled security work or dedicated budgets. One-off donations or grants for a fixed deliverable are a different question, and the guidance treats third-party funding and paid development work separately.

The link to Article 24 duties

A steward's obligations come from Article 24, which applies from 11 December 2027. Stewards must report actively exploited vulnerabilities to the extent they are involved in development, and severe incidents affecting the network and information systems they provide for development. The duties are lighter than a manufacturer's, and Article 64(10)(b) excludes administrative fines for open-source stewards. Confirm with counsel which systems a foundation provides for development, such as build servers or disclosure channels, since those define the reporting scope.

Whether commercial members change the role

A common question is whether a foundation's commercial members make it a steward or a manufacturer. The guidance addresses funding and sponsorship, and says third-party funding or paid development work does not by itself place FOSS on the market. Membership fees, seats on a board or sponsor logos do not settle the question on their own. Review who controls releases and distribution, and whether members receive software, features or updates in return for payment. Ask counsel to confirm the answer for your specific membership terms.

When steward reporting starts and what it covers

The sequence below shows which obligations apply on which dates, what a foundation or steward must report under Article 24(3), and what each phase produces so the organization can decide what to prepare and when.

Confirm the 11 September 2026 manufacturer reporting start
Manufacturers of in-scope products have had to report actively exploited vulnerabilities and severe incidents under Article 14 since 11 September 2026. Stewards are not yet bound by Article 24(3) at this point, but a foundation or company that also places products on the market as a manufacturer is already inside that duty. Whoever publishes a monetized product should confirm which of its roles carries Article 14 obligations today. The output is a written role map that names each legal entity and each product it publishes, with the reporting duty attached to each.
Map which steward activities create duties
Review whether the organization gives sustained support to specific FOSS intended for commercial activities. The Commission guidance treats such foundations and legal persons as stewards, while code shared without monetization is generally not placed on the market. Sponsorship, third-party funding and paid development work do not by themselves create this status, and not-for-profit organizations that use all earnings after costs for not-for-profit objectives are treated differently. The output is a documented determination for each project, reviewed by counsel, that records the facts relied on.
Identify the steward's development role
Article 24(3) limits steward reporting to the extent the steward is involved in development. Document which repositories, release processes, build systems and infrastructure the steward controls, and which are run by others. This boundary decides which vulnerabilities and incidents the steward must report. The output is a scope statement listing the systems and code under the steward's control, so the reporting duty can be applied to a defined set of assets.
Set up detection for actively exploited vulnerabilities
Steward reporting covers actively exploited vulnerabilities in the projects where the steward participates in development. The steward needs a way to learn of exploitation, such as advisory feeds, vulnerability disclosure intake and monitoring of issue trackers and security mailing lists. Confirm with counsel how the term actively exploited is read in the Commission guidance before writing procedures. The output is a documented intake and triage procedure with named owners.
Prepare severe incident detection for development systems
The second steward duty covers severe incidents affecting the network and information systems the steward provides for development, such as code hosting, build pipelines, package registries and signing infrastructure. Operators of these systems should review logging, access records and backup coverage so an incident can be identified and scoped. The output is a list of development systems with their monitoring sources and an escalation path to the person who would decide on a report.
Prepare reporting through the Single Reporting Platform
Stewards report through the same ENISA-run channel used by manufacturers, and notifications go to the CSIRT designated as coordinator. Before the steward duty applies from 11 December 2027, teams should confirm the reporting contacts, the designated CSIRT and the internal approval chain. The output is a tested reporting runbook that names who drafts, who approves and who submits a notification.
Check the Article 64(10)(b) fine exclusion
Article 64(10)(b) excludes administrative fines for any infringement of the regulation by open-source software stewards. This exclusion does not remove the reporting duty itself, and it does not apply to a steward that also acts as a manufacturer of a monetized product. Counsel should confirm how the exclusion interacts with each entity's role. The output is a short written analysis that separates steward duties from manufacturer duties for each entity.
Apply the steward duties from 11 December 2027
The Commission's reporting page states that Article 24(3) steward reporting applies from 11 December 2027, the date the regulation applies generally. By this point the intake procedure, development scope, incident monitoring and reporting runbook should be tested against a realistic exercise, and the results recorded. The output is a dated readiness record that shows what was in place when the duty began.

What contributors should check before submitting code

Whether the CRA reaches a contributor depends on who controls publication and release, who pays for the work and whether the software is monetized. The checks below help you answer those questions for your project using its governance documents, and they are a starting point for a conversation with the maintainers, not a legal opinion.

Commit access without release control

Holding commit access or submitting pull requests does not by itself make you a manufacturer. The guidance places responsibility with the maintainers who publish the software and control its releases and distribution. Check the project's governance file or contributing guide to see who approves merges, who cuts release tags and who signs and publishes packages. If you cannot approve a release, your exposure is likely limited, but confirm that with the maintainers.

Whether your employer funds the work

Third-party funding, sponsorship or paid development work does not by itself place free and open-source software on the market. Your employer's involvement matters in a different way: if the company builds its own commercial product on the code, that product may be its own in-scope product. Ask whether your contribution is made in a personal capacity or as part of paid work, and whether your employer distributes a commercial build that includes your changes.

Whether the project is monetized

Free and open-source software that is not monetized is not placed on the market. Monetization can come from paid editions, paid support, hosted services or conditioning access to updates or essential features on a donation. Review the project's website, pricing pages and license terms to see whether anything is sold or conditioned on payment. Commercial activity around the project is the point where a steward or manufacturer role may arise, so ask the maintainers who makes that determination.

Whether you distribute builds

Publishing binaries, container images, installers or packages to users is distinct from publishing source code. Check whether you would upload artifacts to a package registry, attach them to releases or push images to a public repository. Distribution of builds under your own account is the kind of activity that makes the publisher's role concrete, so confirm with the maintainers which pipeline publishes official artifacts and who holds the credentials for it.

Who handles vulnerability reports

Before you submit a fix for a security issue, ask who receives vulnerability reports and who coordinates disclosure. A published security policy, a designated security contact or a foundation's vulnerability process indicates an existing handling route. If none exists, raise that gap with the maintainers. Reporting duties for actively exploited vulnerabilities apply to stewards from 11 December 2027, so the project's process for triage and disclosure should be documented before that date.

What maintainers and foundations should document now

The first thing to document is the classification decision itself: who publishes the software, whether it is monetized, and which role that places the organization in under the regulation. For a free and open-source project, the guidance puts responsibility with the maintainers who publish it and control releases and distribution. A foundation or company that gives sustained support to specific projects intended for commercial activities may instead be a steward. Write down the facts behind the choice, including who publishes each artifact, who holds release authority, and whether any paid edition exists. Record the date of the decision and the person who approved it. The organization owns this conclusion. An outside advisor can help you structure the analysis, but the decision, and the duty to revisit it when the project changes, stays with your board or project leadership.

The second thing to document is governance and release control. Name the people or bodies that can approve a release, sign artifacts, accept vulnerability reports and speak for the project to users and authorities. Keep the release process in writing, including who holds signing keys and where build and distribution rights sit. This record matters most for contributors: a pull request or commit access without control over publication does not, on the guidance's reading, make a contributor subject to the regulation, and a written governance model is what shows where that line falls in your project. Also document the funding arrangements: donation terms, sponsorship agreements, paid development contracts and any not-for-profit status. Confirm with counsel whether any donation or contract ties access to updates or features to payment, since that condition can change the analysis.

This record is what you will show a regulator, a commercial adopter or an auditor when the question comes up. A dated classification memo, a governance chart, a release procedure and a funding summary let you answer quickly and consistently. Keep them in the project repository or a governance folder so they are versioned with the code. Review them when a company starts paying for support, when a foundation takes on a new project, or when the Commission or national authorities publish further guidance. Only an independent auditor or certification body issues assessment reports, and no outside party issues a CRA compliance certificate. Use outside help to prepare and test the documentation, and confirm the current guidance on the Commission's CRA page before you finalize the record.

Questions maintainers ask about CRA obligations

Does a hobby open-source project need to comply with the Cyber Resilience Act?

A free project that is not monetized is not placed on the market, so the regulation's product obligations generally do not reach it. The Commission's guidance (C(2026) 5252) confirms that free and open-source software is covered only when it is made available on the market, which requires a commercial purpose. Free software shared without monetization sits outside that scope. The position changes if the maintainer or a related legal person starts charging for the software, or for access to it, essential features or updates. Check the project's funding and distribution model against the guidance before assuming it is exempt, because the test looks at how the software is supplied, not at the author's intent alone.

Do contributors who submit pull requests carry CRA obligations?

Generally no. The guidance places responsibility for free and open-source software with the maintainers who publish it and control its releases and distribution. Contributors who submit pull requests, or who hold commit access without control over publication and distribution, are not subject to the regulation. Responsibility follows release authority. Projects should record who decides on releases, signs artifacts and publishes packages, since that is the person or entity the regulator would look to. Confirm your project's governance document reflects this before relying on it.

Do donations or sponsorship count as placing open-source software on the market?

Donations made without intent to make a profit are unlikely to place the software on the market, unless access to the software, its essential features or its updates is in practice conditioned on donating. Third-party funding, sponsorship or paid development work does not by itself place the software on the market. Not-for-profit organizations that use all earnings after costs for their not-for-profit objectives do not place their free software on the market either. The risk appears when a donation tier unlocks something the community cannot otherwise get, such as security updates or priority fixes. Review donation tiers, sponsor perks and paid support terms with counsel to confirm where the line falls for your project.

What is steward reporting under the CRA from December 2027?

From 11 December 2027, open-source software stewards must report actively exploited vulnerabilities and severe incidents under Article 24(3), to the extent they are involved in development. Stewards are legal persons that systematically support free software intended for commercial activities, such as foundations giving sustained support to specific projects. The Commission guidance says a legal person publishing a free community version and a monetized version is a steward for the first and a manufacturer of the second. Stewards have a lighter regime than manufacturers, and Article 64(10)(b) excludes administrative fines for infringements by open-source software stewards. Establish now who would receive and triage vulnerability reports, and confirm your reporting route with the regulator's published guidance.

Can a foundation avoid CRA fines by being a steward?

A foundation's status as a steward does not give it blanket immunity, but the regime is lighter. Article 64(10)(b) excludes administrative fines for any infringement of the regulation by open-source software stewards, and the steward obligations are limited to the Article 24 duties. A foundation that is not a steward, for example because it does not give sustained support to commercial projects, may fall outside the regime altogether. A foundation that publishes a monetized product of its own is treated as a manufacturer for that product, and manufacturer fines apply. Map each project the foundation supports to its role before assuming the exclusion covers it.

Do I need an outside consultant for CRA work, and what does it cost?

Whether you need outside help depends on whether your project is in scope and how much of your work is commercial. Several parts of the work are one-time (scope determination, a vulnerability disclosure process, a reporting route) and some recur (triage, dependency monitoring, supporting releases). No fee figures are supplied for this topic, so any number you hear should be checked against a written scope. Ask any provider for a fixed scope listing the systems, deliverables and timeline, the roles (who owns controls, who prepares evidence), and what is excluded. DeployOpen plans, implements and documents self-hosted open-source platforms and runs security testing, and it prepares evidence for assessments. It does not issue reports or certifications, and independent bodies do. Pricing follows from the written scope.

How to choose a legal or compliance adviser for a FOSS project

An adviser can help a FOSS project map its status under the Cyber Resilience Act, but the conclusion stays with the project and its legal counsel. The cards below set out what to check before you sign, from understanding the Commission's guidance to agreeing how evidence changes hands.

Confirm knowledge of the Commission guidance

Ask the adviser to explain how the Commission's guidance treats FOSS, including the difference between a maintainer who publishes and controls releases and a contributor who submits pull requests. Ask which sections they rely on for donations, sponsorship and not-for-profit funding, and how they would test whether your project is placed on the market. A vague answer on these points is a reason to keep looking.

Ask for a written scope

Require a written scope that names the project, the repositories, the releases and the funding arrangements in question, along with each deliverable and the date it is due. Fixed-scope work is easier to compare across bids and easier to hold to account. Ask which questions are excluded, such as steward status or a foundation's obligations, so you know what remains open.

Check open-source governance experience

Ask for examples, described without client names, of work on open-source governance, release control, contributor policies or foundation structures. Ask how they would document who controls releases and distribution, since that question often decides whether a person or organization carries obligations. Experience with the steward concept under Article 24 is worth asking about directly.

Confirm they do not issue the conclusion

Confirm in writing that the adviser will analyze and prepare material, but will not decide whether your project is in scope or issue a legal opinion on your behalf. Conformity and regulatory positions belong to the organization and its counsel, and assessment reports come only from independent assessors or certification bodies. Advisers who promise a definitive answer are overstating their role.

Agree how evidence is handed over

Ask in what format the adviser will deliver memos, decision records and supporting evidence, and who keeps the master copies. Agree on version control, on how privileged or sensitive material is stored, and on who receives the files at the end. Clear handover terms prevent a project from depending on a consultant to explain its own position later.

How DeployOpen helps open-source projects prepare evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For maintainers and foundations working through Cyber Resilience Act questions, we prepare the systems, records and evidence that show how a project is governed, maintained and patched, while your organization keeps ownership of its decisions.

How we scope

We agree a written scope that names the projects, repositories, release channels and distribution points in question before any work starts.
The scope states which governance, release and vulnerability handling records we will document, and which decisions remain with your maintainers or board.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing, and a quote follows directly from that agreed scope.

How we build

We set up the infrastructure, build pipelines and tooling that record releases, dependencies and vulnerability reports inside your own environment.
We document how responsibility for each release and distribution channel is assigned, so the record matches who actually controls publication.
We test the vulnerability intake and patch workflow end to end, then record the results so your team can repeat them.

How we hand over

You receive the documentation, configuration and evidence artifacts in a form your maintainers and auditors can review and reuse.
Handover includes a walkthrough of the processes, so the people who run the project can operate and update the records without us.
Only an independent auditor, assessor or certification body issues reports or certificates, and we confirm the evidence with your legal advisers before handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers once the initial scope is complete.
A retainer can cover updates to records when releases change, when contributors or sponsors change, or when the guidance is revised.
Ask us to confirm in writing which support, testing and review activities a retainer includes before you sign.