The CRA’s Global Impact: Why Manufacturers Hold the Key

The idea of regulating open source software is likely to spark anxiety, especially when it touches on security. But in this case, much of that worry is misplaced. The Cyber Resilience Act (CRA) was carefully drafted so that the weight of compliance falls primarily on manufacturers – those of us monetising products built on open source – not on the open source community itself. Its intent is clear: to make products more secure, protecting everyday consumers like you and me. While there may have been some initial apprehension, the CRA in its current, revised version ultimately represents an opportunity, not a threat.

The Cyber Resilience Act (CRA), even though it is a European Regulation, has a truly global impact. For an organisation such as Huawei, which is headquartered outside of Europe but sell products with digital elements (PDEs) in Europe, the CRA applies to us.. As anyone who works in international markets knows, you must follow the laws of the land. For Huawei, when we sell to the European market, we work closely with our product delivery teams to ensure our products comply with the local requirements. While local regulations are nothing new, the CRA’s impact is truly global, not only for multinational manufacturers, but also because it extends to open source, which is inherently global.

As someone who has worked with open source software for the majority of my career, I quickly saw the implications of the CRA on OSS. For example, if a European company consumes an open source project hosted outside of Europe into a product, that connection brings the project under the CRA’s scope. Whether the project is under a foundation acting as an open source software steward or maintained by individuals, what matters isn’t where the project is based, but where the product is used. That’s why the CRA’s impact is global. Early on, I noticed a wave of fear, with some open source community members even taking down their projects. Confronted with headlines about hefty fines – up to €15 million or 2.5% of revenue – they wondered whether they themselves could be held liable.

The good news is that the open source community engaged early and helped shape the CRA so that, in its current form, it should not be seen as a threat. On the contrary, it has the potential to strengthen consumer trust in open source.

Let me explain.

When the early conversations around Open Regulatory Compliance working group began, I was already deeply involved in the Eclipse Foundation through the Oniro Working Group, which I had joined from its inception. From the outset, I was aware of the effort, but my interest grew as it became clear what this work aimed to achieve: building consensus. After all, we were all reading the Cyber Resilience Act, but not everyone is a lawyer, a standards specialist, or a policy expert

The Eclipse Open Regulatory Compliance Working Group provided a space where we could collectively interpret the text, ask the right questions, and align our understanding. A good example is the FAQ we developed. I led the manufacturer section in one of the first meetups, gathering perspectives from different manufacturers on issues like what “open source due diligence” really means in practice. That kind of input has shaped key deliverables, from a planned white paper on security attestations to ongoing work on manufacturer responsibilities. Not every question has a final answer yet – some are marked as open in the FAQ as they depend on forthcoming standards and guidelines – but the process itself has been invaluable.

In the end, we are all trying to solve the same problem

What matters is that this is a community effort. Instead of each of us trying to navigate the CRA in isolation, we’re working together to share interpretations, resolve uncertainties, and ultimately ensure a stronger, shared understanding.
One of the key points for manufacturers is that many of us rely on the same open source components. We’re all building products on top of a shared code base, which means we’re facing the same challenges. Instead of each of us trying to solve them alone, it makes sense to build consensus – especially when it comes to understanding how to meet the obligations of the Cyber Resilience Act while incorporating those open source components into our products. In the end, we’re all trying to solve the same problem. So it’s better to join forces rather than each of us repeating the same work.

Ultimately, it is this joint effort – by manufacturers, open source stewards, and other stakeholders with real skin in the game – that will help build consumer trust in open source.

Knowledge is power

So how do we share the good news and put CRA fears to rest? The answer lies in education.

At recent conferences, I was surprised to meet people in large global organisations who had never even heard of it. It was a clear reminder that awareness cannot be taken for granted.

Here is what I recommend:

• Internal communication plans and training programs are essential, tailored to the needs of each department since the CRA touches everyone.
• Securing buy-in from senior leadership is especially important, because once executives understand the real obligations and potential financial penalties, they will prioritise giving teams the time and space to engage. At Huawei, we’ve been fortunate to have strong support from senior leadership right from the start. Their buy-in has been crucial in ensuring that all internal organisations are aligned and engaged. That’s something I would recommend to any manufacturer, regardless of size, even if you’re a company of just 50 people.
• Securing buy-in across departments is also relevant, because requirements under the CRA extend to areas that might not expect it, such as technical documentation. Technical writers, for example, will face new standards that affect how documentation must be produced. Without leadership support, it’s difficult to bring everyone on board. Clear communication across the organisation is therefore vital to ensure that every team understands and meets its obligations.
• Targeted education is key: creating multiple training formats at different levels – from quick, high-level briefings to detailed, department-specific materials – so that every team, whether it’s engineering, compliance, or technical documentation, understands what’s required of them. This is also where community resources and knowledge sharing are invaluable, providing shared assets that organisations can adapt to educate their own people.

In short, internal training programs, securing buy-in, and tailoring training are the pillars of ensuring organisations are truly prepared for the CRA.

Everyone wants secure open source and strong best practices

To sum up, I believe the CRA will ultimately be a positive force for open source. For the first time, the relationship between manufacturers and open source is explicitly recognised in regulation, clarifying roles and responsibilities that were previously undefined. At the end of the day, everyone wants secure open source and strong best practices; there’s no debate about that. My hope is that the CRA will encourage more manufacturers, especially those that have traditionally only consumed open source, to begin contributing back. At Huawei, we’ve long been active in contributing to projects and working with open source stewards, but I see this as an opportunity for many others to get more involved upstream. That could mean new contributors bringing code, documentation, or security expertise into these communities. If that happens, open source won’t just grow in participation – it will grow in quality and security. Regulation, in this sense, may actually strengthen open source by drawing in new voices and building even greater trust in the software we all rely on.

The same will hold true for other legislation that’s on the horizon. For example, the AI Act introduces specific obligations for open source, particularly for general-purpose AI models, raising new questions about what “open source AI” actually means. Looking ahead, I see the ORC Working Group expanding its focus to these emerging regulations as well, helping the open source community navigate their long-term impact. After all, it’s called the “Open Regulatory Compliance” Working Group for a reason.

Adrian O’Sullivan is the Director of the European Open Source Program Office at Huawei. He has a passion for creating technology that can help solve the issues that challenge the world we live in. He loves to work with diverse teams and collaborate globally. Therefore, Adrian was attracted to the global collaboration for shared success that he witnessed open source communities generate. Adrian feels lucky to be in a position to help direct how Huawei’s Consumer, Carrier, Cloud & AI Businesses make use of and participate in open source projects to build the products to meet Huawei customer’s needs.

In Europe, Adrian directs investment and resources into a large array of open source communities, from the Eclipse Foundation to the Linux Foundation Europe and more. Personally, he also loves to contribute time back into these communities, in a wide range of roles, such as being an Advisory Board member of the Linux Foundation Europe, a Project Technical Lead in the Linux Foundation ONAP project to the Steering Committee representative of both the Eclipse Foundation Oniro and Open Regulatory Compliance Working Groups. Adrian works on helping Huawei navigate the implications of new European regulations such as the Cyber Resilience and AI Acts, establishing best practices on how to safely consume open source into the products Huawei brings to the market, by working with both the Eclipse Open Regulatory Compliance and Linux Foundation Global Cyber Policy Working Groups. Adrian has also driven activities to bring open source and standard communities closer together, such as being the leader of the CEN-CENELEC Open Source Solutions business model team representing NSAI-National Standards Authority of Ireland. In Ireland. Adrian also represents Huawei Business interests as the lead Huawei representative within IBEC - Irish Business and Employers’ Confederation.