Barry O'Donovan

The Cyber Resilience Act and Open Source: What Maintainers Need to Know

Last month I spoke at the RIPE 93 Open Source Working Group in Sofia on Beyond NIS2: Software Supply Chains and the Cyber Resilience Act. It was an updated version of a talk I’d given to the Euro-IX community, refocused on the people the CRA worries most: open-source developers, and the foundations and organisations that maintain the software the rest of us depend on.

Given how much confusion (and some outright panic) there is about the CRA in open-source circles, I thought it worth writing up properly. You can download the slides and there’s a video of the session.

I come at this from a few directions. Primarily, I’m the lead of IXP Manager, an open-source platform used by around 300 internet exchanges; and I’m part of the operations team at INEX, which is itself a regulated operator under NIS2 and runs plenty of open source in production.

One caveat before we start: I’m not a lawyer. This is my reading of the regulation and the Commission’s guidance, and where it matters to your organisation you should take proper advice.

A Regulatory Tsunami

It’s worth a moment on context, because the CRA doesn’t exist in isolation. Over the last decade the EU has produced a steady stream of cyber legislation:

  • 2016: the NIS1 Directive.
  • 2019: the Cybersecurity Act (ENISA’s mandate and certification schemes).
  • 2023: NIS2, the Critical Entities Resilience (CER) Directive and DORA for the financial sector.
  • 2024: the AI Act and the Cyber Resilience Act.
  • 2025: the Cyber Solidarity Act.

There has been a backlash. Mario Draghi’s 2024 report on EU competitiveness was scathing about the digital regulatory regime, counting around 100 tech-related laws which have created over 270 new regulatory bodies. President Macron has openly called for a regulatory pause so Europe can digest what it already has. And here in Ireland, the government has had to publicly scold its own civil servants over delays in transposing EU directives; NIS2 still isn’t Irish law, although many Irish operators are sensibly behaving as if it were.

None of that changes what’s on the statute book, though, and for the CRA the clock is already running.

NIS2 Runs Your Network; the CRA Governs What You Run It With

If you operate an ISP or an IXP, NIS2 very likely applies to you now. It creates a legal obligation to manage your operational cyber risk, including the risk in your supply chain.

That raises an obvious question: what about the software vendors and open-source projects supplying us? That’s where the CRA comes in. It imposes direct cybersecurity and vulnerability-reporting obligations on software (and hardware) made available on the EU market.

NIS2 governs how we run our networks. The CRA governs the software we run them with.

And of course, as xkcd famously put it, all modern digital infrastructure is balanced on many pieces of open source software maintained by a handful of people. I used Ondřej Surý as the example in the talk: the PHP packages so many of us install on Debian and Ubuntu come from his repository, maintained largely as a volunteer.

The week before RIPE 93 made the point better than any slide could. PHP2Shell, a pair of critical remote code execution flaws affecting PHP versions back to 5.4, was disclosed on 20 October and was already being exploited in the wild. Official binaries were only released for supported versions; for older versions there was just a source patch. Ondřej built installable packages for those older versions too, so operators could patch automatically rather than compile PHP by hand at short notice. That is critical infrastructure, and it was one volunteer. If the CRA had landed badly on people like Ondřej, it would have landed badly on all of us.

Are You in Scope?

Here’s the good news first: if you’re an individual developer publishing open source, the CRA almost certainly doesn’t apply to you.

Software is only regulated if it’s supplied in the course of a commercial activity. The regulation is explicit that simply hosting code on an open repository or collaboration platform (GitHub, GitLab) or distributing it through a package registry (PyPI, npm, Packagist) is not making it available on the market.

None of the following automatically push a project into scope:

  1. Accepting voluntary donations or tips, provided they offset hosting or development costs rather than generate a profit.
  2. Maintaining the project, including tagging regular releases.
  3. Accepting bug fixes and pull requests from engineers employed by commercial companies.
  4. Receiving non-commercial public research grants or academic funding.

Two clarifications that come up every time:

  • Not-for-profit doesn’t mean non-commercial. Just because your organisation doesn’t make a profit doesn’t mean the software isn’t used in a commercial activity. INEX is a not-for-profit association, but it charges its members for ports, and IXP Manager runs that service.
  • Status is decided per product, not per organisation. NLnet Labs, for example, treats Routinator as a steward product while some of its other software is out of scope. One project can even be both: a steward for the free version and a manufacturer for a paid edition.

Three Questions

Recital 19 is the key to the rest. It talks about free and open-source software that is “ultimately intended for commercial activities”, meaning integrated into commercial services or monetised products, and that word ultimately means indirect use counts. That gives three questions, in order:

  1. Do you make money from the software itself? If yes, then you’re a manufacturer, with the full set of CRA obligations.
  2. If not, are you an organisation that keeps the software going for businesses to build products or services on? Then you’re an open-source software steward.
  3. Neither? You’re out of scope.

And it only works in that order: if you tick the boxes for being a manufacturer, you can’t sidestep your way into being a steward.

The Commission’s guidance includes worked examples that line up with this:

  • [Example 33] A not-for-profit, membership-funded organisation whose members contribute code: steward.
  • [Example 28] A foundation maintaining a component that others build into commercial products: steward.
  • [Examples 25, 29] A company publishing a library it uses itself, without monetising it: steward, not manufacturer.
  • [Examples 27, 34] An individual developer, even if companies donate to them: no obligations.

Stewards Versus Manufacturers

So there’s a gap between individual open source developers and manufactures and that’s where the EU created an entirely new type of entity called open-source software stewards:

‘open-source software steward’ means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products

It’s a recognition that non-profit foundations are different from commercial vendors. It is important to note that in EU-legalese, ‘a legal person’ means any legal entity, including foundations, associations, and companies, but not individuals. I.e., an individual cannot be a software steward.

The question then arises as to when an entity’s open-source project is a dealt with as a software steward or as a manufacturer. Typical indicators are:

Open-source software steward Open-source manufacturer
Who Any legal person (foundation, association or company) that doesn’t monetise the software Anyone who monetises it, individual or company
Money Code distributed freely: no licence fees, no paywalled enterprise tier Open core (free basic, paid enterprise), support contracts tied to the product, or paid dual licensing
Examples from our world INEX for IXP Manager; NLnet Labs for Routinator Enterprise Linux vendors; appliance vendors packaging FRR or Linux into proprietary network boxes

When Does This Happen?

The CRA is Regulation (EU) 2024/2847, adopted in October 2024. It’s a regulation, not a directive, so, like GDPR, it applies directly across the EU without waiting for each member state to transpose it into national law. This is a point of difference with NIS2.

It applies in stages:

  • 11 September 2026: mandatory vulnerability and incident reporting for manufacturers. This is already live.
  • 11 December 2027: full application, including the (limited) reporting obligations for open-source software stewards.

For manufacturers, fines run up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

What Stewards Actually Have to Do

If you’re a steward, the obligations are deliberately light. There are three.

1. A Cybersecurity Policy

This is the bread and butter. You must have a cybersecurity policy that fosters the development of a secure product and the effective handling of vulnerabilities, encourages voluntary reporting of vulnerabilities, and promotes sharing information about discovered vulnerabilities within the open-source community. In practice that means covering secure development practices, how you take in vulnerability reports, your patching workflow and how you remediate. It can be tailored to how your organisation actually works; nobody expects a volunteer-heavy foundation to look like a multinational.

2. Cooperation With Market Surveillance Authorities

At their request, you must cooperate with the authorities to mitigate cybersecurity risks, including providing your cybersecurity policy. They can issue corrective orders (in practice, “go and write the policy”).

3. Reporting

From December 2027, stewards report:

  • Actively exploited vulnerabilities, to the extent you’re involved in the development (that is, you provide engineering resources), informing users where appropriate and directly where you have a relationship with them.
  • Severe incidents affecting the security of the product, where you provide the underlying IT infrastructure, with a general announcement to users where appropriate. Think of a compromised GitHub or GitLab account, build system or download server.

One very important thing to note: reporting obligations continue after a version stops being supported.

The clock (Article 14) is tight. It starts when you become aware, which may first mean confirming a report from a third party. Reports go through ENISA’s Single Reporting Platform: you choose your national CSIRT when you register, and a single report then reaches both ENISA and the CSIRT.

  1. Within 24 hours: an early warning.
  2. Within 72 hours: a detailed notification with an initial assessment.
  3. Final report: within 14 days of a fix or mitigation being available for a vulnerability, or within a month of the 72-hour notification for a severe incident.

So Where’s the Stick?

This is the part that surprised a few people in Sofia. Stewards can’t be fined. The CRA is explicit that no administrative fines or other pecuniary penalties apply to them for any infringement.

So it’s persuasion rather than punishment, and the persuasion is real:

  • Your users’ NIS2 obligations. Your users are now required to assess the security of their supply chain, and that includes you.
  • Manufacturers’ due diligence. Companies building your software into products must do due diligence on their components, and they’ll be asking you questions.
  • Your reputation. It takes years to build a reputation and seconds to lose it. A project with no security policy and no way to report a vulnerability is going to look increasingly out of place.
  • The CSIRT can go over your head. If you don’t communicate an actively exploited vulnerability, the authorities can go to your users directly. This will not reflect well on you.

And the one stick that does exist: monetise it, then you’re a manufacturer, with the full obligations and the full fines.

The Other Side: Consuming Open Source Under NIS2

Most of the people in that room weren’t only maintainers; they were also operators running open source in production. Article 21 of NIS2 is the counterpart to everything above:

“It’s free software” is no longer an excuse for unmanaged supply chain risk.

NIS2 requires essential and important entities to assess the security of third-party software, and that explicitly includes the open-source routing daemons, automation scripts and management platforms that run our networks. In practice, operators need:

  1. A software asset inventory: a clear map of the open-source packages in the production path.
  2. Vulnerability tracking: a structured process for taking in advisories and assessing whether a vulnerability is actually reachable and exploitable in your environment.
  3. Timely patch management: defined change procedures to deploy security fixes without undue delay.

This is where the two regulations meet. Every operator doing this properly will start looking for projects with a clear security policy, machine-readable advisories and a predictable support lifecycle. The good stewards will make that easy.

A Case Study: IXP Manager as a Steward

We treat INEX as the open-source software steward for IXP Manager. INEX funds the project’s GitHub, some of its developers, project management, releases and security audits, and IXP Manager is used to run exchanges that provide commercial services to their members, so it fits the definition squarely. Here’s what we’ve put in place:

  • A secure application development policy, published in the documentation. We actually wrote this before the CRA, because other exchanges, working through their own NIS2 supply-chain obligations, started asking us for one. That’s the persuasion I described above, working exactly as intended.
  • A formal coordinated vulnerability disclosure policy in our SECURITY.md: intake by PGP, Signal or GitHub Security Advisories, a 48-hour response target, and explicit support lifecycle tables so users know which versions get fixes.
  • GitHub Security Advisories, which generate standard CVEs and machine-readable OSV data that operators can feed straight into their own vulnerability scanning.
  • Proactive hardening. We use third-party penetration tests and responsible disclosures as a prompt for wider internal code audits. The last half-dozen releases have been largely security-focused, driven by a wave of AI-assisted vulnerability reports, with a developer we hired earlier this year handling much of the intake.
  • A CRA escalation playbook, still to be written, documenting how we’d notify the Single Reporting Platform within the 24 and 72-hour windows if active exploitation is confirmed. Steward reporting doesn’t apply until December 2027, so the policies came first.

None of this is exotic, and most of it is simply good practice that we’d want anyway. The CRA makes us all write it down.

What Should You Do?

If you publish software, work out which of three scenarios you’re in:

  1. Scripts and code you share without monetising it (an automation script, a BGP filter generator): out of scope. Carry on, and a SECURITY.md is still a kindness to your users.
  2. Sustained tooling your industry relies on, in a commercial context, without monetising it: steward. Publish a cybersecurity policy and a vulnerability disclosure process, use your forge’s security advisories, publish a support lifecycle, and have a plan for the 24 and 72-hour reporting windows before December 2027.
  3. Software you sell, or package into an appliance or a paid service: manufacturer. You’re looking at the full regime: CE marking, conformity assessment, SBOMs and, since September, mandatory reporting. If that’s news to you, it’s time to take advice.

If you consume open source in a NIS2-regulated organisation, start with the inventory. You can’t manage the risk of software you don’t know you’re running.

From the Q&A

The questions afterwards were as useful as the talk.

  • Will the line between steward and manufacturer be settled in court? One remote participant worried that it would, and inconsistently. My answer: some cases are clear-cut, but there’s a big grey area that only case law will settle. Another participant suggested that being recognised as a steward could become a badge of honour; with no fines attached, reputation is the real lever.
  • Is AI outpacing the regulation? Another participant made the point that AI-driven vulnerability discovery is moving faster than any regulatory timetable, that manufacturers are way behind, and that any slippage in dates is no reason for complacency. I agree; our own release history this year bears it out, and so does PHP2Shell.
  • Do reports go to the national CSIRT or to ENISA? A manufacturer in the room had understood it was only the CSIRT. It’s both, through the single platform, as above.

Resources

I work with boards and engineering teams on exactly these questions, from NIS2, DORA and CER readiness to the CRA, through Open Solutions. If your organisation is trying to work out where it stands, get in touch.