NLnet Labs as an open-source software steward under the CRA
The Cyber Resilience Act is an EU law regulating the market for hardware and software. We have an excellent understanding of this law, helped to shape its treatment of open source software and are available to help companies that integrate our software in products to meet their CRA obligations.
by Maarten Aertsen
Just over a month ago the initial set of (reporting) obligations under the European Cyber Resilience Act kicked in for Manufacturers, commercial producers of hardware and software for the European Market. From December 12, 2027, all such products destined for the EU market will be subject to regulation. We have actively promoted the interests of open source developers since the CRA was proposed in 2022. Read on to learn what we achieved, or skip to the headings to learn what the law means in practice for contributors, integrators or operators of our software.
EU law is the result of negotiations between member states (Council) and the European Parliament, based on a proposal by the European Commission. We worked with all three sides to affect the outcome for developers of open source software. The negotiated text introduced an obligation for all Manufacturers that integrate software to upstream patches for security vulnerabilities to its (open source) maintainers, added nuance with respect to the scoping for developers of free and open source software and permits Manufacturers of open source software in the ‘important’ product class to self-assess instead of third party assess compliance.
Contributors: the CRA does not apply to you
In short, most open source software is out of scope for the CRA. Your contributions to our projects do not introduce CRA obligations for you, even if you contribute as part of your job.
If you really need to understand the nuanced treatment of open source under the CRA, we recommend the CRA guidance on open source software from the European Commission as your best starting point (before reading the law itself). I'm glad the tradition of flowcharts stuck and recommend to start with theirs, at the very end of Section 3 for an overview, and only then turn to the the fourteen pages that make up the section.
Integrators: support us and we'll simplify your due diligence obligations
Companies integrate our open source software as components in commercial products they sell on the EU market. The CRA puts a due diligence obligation on such Manufacturers. Due diligence is risk-based and more involved for load-bearing and security critical components. Our software is frequently employed in such a role, making due diligence more involved than automated checks.
We have an excellent understanding of the law and are ideally positioned as upstream maintainers to assist companies with their CRA due diligence obligations through the professional support services for our software. These relationships in turn allow us to recuperate our costs of long-term maintenance.
Our role as an open-source software steward
Not-for-profit organisations that develop and publish open source software, such as ourselves, are under a different CRA regime. NLnet Labs is a so-called Open-Source Software Steward under the CRA. We have published a new webpage detailing our compliance obligations, documenting the criteria we use to determine which projects are under our stewardship. It also spells out our CRA obligations with respect to these projects.
Not all of our open source work is stewarded: some projects were never intended for commercial activity in the first place (think: research projects), or have been declared end of life. As a result these do not or do no longer carry legal obligations for us under the CRA.
Operators: the CRA models how your supply chain obligations can work for open source
NIS2 introduced supply chain security obligations for DNS operators, TLD registries, Internet Exchanges and other organisations that use our open source software. The CRA is intended to simplify these obligations by making the 'CE-mark' a differentiator between products that do and products that do not meet EU requirements on product security.
Unfortunately, exceptions aside, most open source software you rely on will not be CE marked. This is a direct consequence of the fact that most open source software is maintained by individuals and the nuanced treatment of open source in the CRA that flows from that reality. Software by (communities of) individuals are out of scope and cannot be CE marked by their maintainers. Software that is backed by a non-profit (such as NLnet Labs) is in-scope, but cannot be CE marked by that entity (a steward) either. The only open source software that can be CE marked is FOSS sold by a Manufacturer, which is likely a fraction of all FOSS in your supply chain and not always its upstream maintainer.
The net result is that operators will need to find other productive ways to substantiate to regulators that they are taking care of their supply chain.
A poor outcome would be a move away from best in class software that happens to be open source, to alternatives that happen to be CE-marked.
As the regulatory approach with respect to NIS2 matures, we sincerely hope that the CRA notion of stewarded open source software can play a role. Pooling financial resources through steward organisations that support maintainers is more likely to lead to sustainable maintenance than every entity doing so on their own.
Open source software enables operators to build up the necessary expertise for troubleshooting their supply chain entirely in-house. But if you choose not to make that investment, you can contract with us for deep technical support. This keeps our work sustainable, and helps your interaction with regulators when they have questions about your supply chain or systems maintenance. On the NIS2 supply chain security requirements, ENISA guidance says: “Ensure that support contracts cover the system life cycle and obsolescence management requirements, including the date until which the system must be supported”. So it's not just us either.