Skip to content
folhas.io
secure by design for connected products· open source

Heard us on FOSS Weekly? Start here.

The CRA and open source: which role your project is in

Folhas Etéreas is a Portuguese product-security consultancy, with roots in pentesting and red teaming, that prepares manufacturers for the Cyber Resilience Act and runs offensive assessments from the firmware to the premises. This page exists because the CRA concerns a lot of people who build open source, and most do not yet know in which role.

The CRA and open source, in four facts

  1. Free and open-source software supplied outside a commercial activity is out of scope. A project maintained without consideration, published for anyone who wants to use it, is not "made available on the market" within the meaning of the regulation, because there is no commercial activity (Article 2(1) and Article 3(22)), so manufacturer obligations do not apply to it.
  2. "Free" does not mean "non-commercial". Selling support above actual cost, an enterprise edition or monetising the software's data is a commercial activity, and from there the project becomes a product with a responsible manufacturer. Article 07 draws the boundary with examples.
  3. Legal persons that systematically support, on a sustained basis, free and open-source software intended for commercial activities, such as certain foundations, have a lighter regime of their own. The regulation calls them "open-source software stewards" (Article 24): a cybersecurity policy and cooperation with market surveillance authorities. Reporting of actively exploited vulnerabilities applies to them only to the extent they are involved in development, and reporting of severe incidents only where these affect the network and information systems they provide for that development (Article 24(3)). There is no CE marking and no conformity assessment. These obligations only apply from 11 December 2027 (Article 71(2)); manufacturers' reporting has applied since 11 September 2026.
  4. Whoever integrates open source into a product answers for it. The manufacturer that puts a library into firmware has to inventory it in the SBOM, track its vulnerabilities and fix them in the product. Manufacturer obligations do not travel up to a maintainer working outside a commercial activity; they stay with whoever sells the library inside a product. The manufacturer still owes something to whoever maintains the component: on finding a vulnerability in it, it has to report it to that person or entity and, if it develops a fix, share the code or documentation with them (Article 13(6), applicable from 11 December 2027). If the library is itself a commercial product, its manufacturer has obligations of its own, which do not relieve the integrator of theirs. Article 09applies this to a concrete case: the flaws in PHP and Node.js, two open-source projects, fixed on 21 October 2026.

How this site practises what it says

This site's source code is public. We publish a security.txt with a PGP key for vulnerability reports, set up as we describe in Article 08. The content security policy locks the site to its own domain, and there are no analytics and no cookies. Our product, Aeromate, has an open Community edition, and its preparation for the CRA is documented in public in the logbook, failures included.

What we do, in three lines

Product security and CRA preparation, from prototype to sellable product. Offensive assessments: whitebox pentesting of firmware and systems, threat modelling and physical intrusion of premises, always with a written scope and authorisation. And Aeromate, which goes through the same sieve we advise. The detail is under services.

A first read for projects, at no cost

Describe the project or product to us by email, what it is, how it is distributed, whether money is involved and how, and within five working days we send back a written note, two pages long, with three things: whether the CRA reaches you and in which role (manufacturer, open-source steward or out of scope), the dates that apply, and the three most urgent decisions. No call, no meeting and no commercial follow-up unless you ask for it.

To be clear from the start. The read is based solely on the information you send us. It is not an audit, not legal advice and not a conformity assessment. Do not send code, credentials or confidential documentation; a functional description and the distribution model are plenty.

To request one: oi@folhas.io with the subject "First read (open source)".

We do not measure visits. If you came from the podcast, say so in the email: it is the only way we will know.