Time is running out to be in full compliance with the EU Cyber Resilience Act, and we’re helping developers and manufacturers understand how to do just that. Here’s what we’ve been up to since March in helping the wider community understand how to meet the CRA head-on.

The EU Cyber Resilience Act (CRA) is in effect, and testing and certification are on the way. And while the Act is slated for full enforcement in 2027, it’s entirely possible that certification will be in effect as early as next June 2026 – which is just a year away. This ticking clock is understandably anxiety-inducing for lots of organizations, who are rushing to figure out how to meet the wide-ranging requirements of the CRA, while addressing the complexity and difficulty of managing their open source infrastructure and ecosystem.

At Canonical, we’ve been hard at work helping businesses figure this out. In just the last month alone, I attended three events: a Press Event with Mediatek, a partner event with IEI, and a panel on the impact of the CRA on open source during a conference held in Brussels about CRA. At all of these events, two challenges stood out: first, how to understand the Cyber Resilience Act requirements, and second, how to design open source stacks that meet them head on. 

In this article, I’ll explore the key conversations taking place at these events, and examine the most pressing concerns I heard. I’ll also share how Ubuntu Pro is perhaps the most potent way to meet patching and long term support requirements needed to pass CRA requirements.

Learn more about the EU Cyber Resilience Act Requirements

Embedded World

In March, I was honored to join the Embedded World stage during the official launch of Mediatek’s latest releases, the Genio 720 and 520 series. Embedded World is the go-to conference for everything related to embedded technologies and IoT devices, and Ubuntu is an integral part of development on these devices. Ubuntu is widely considered the de facto standard for durable, secured, and sustainable deployment on Mediatek platforms.

I joined Henri Parmentier (Senior Manager EPM Modules at ADLink) and Sameer Sharma (Associate VP of IoT at Mediatek) in a vibrant and direct discussion about how developers could meet the various challenges and requirements that the CRA is bringing to the IoT and devices table.

My focus was on how to meet CRA compliance on Mediatek platforms. During my talk, I emphasized the complexity of the open source environment in the context of CRA with one of my favorite slides:

I love this slide: it really shines an inescapable spotlight on the complexity of open source supply chains and vulnerability management, and demonstrates the effort it takes to incorporate open source effectively and securely into your tech stack. 

Open source is everywhere (a recent IDC study we commissioned shows that more than 70% of organizations use it extensively) but that ubiquity means that your adopted open source will inherit dependencies and vulnerabilities. When you consider how long it takes to fix a vulnerability, and the deep webs of interlinked dependencies that can exist in open source, you begin to understand why meeting the strict SLAs and cybersecurity requirements of the CRA is a major concern for developers and organizations. 

In most cases, the CRA would mandate that you inform CSIRT of product vulnerabilities or security incidents within 24 hours of discovery. Details regarding the severity, impact, and suspected unlawful acts should be included, as well as information to users about the incident and possible mitigation measures they can take in response.

So, how do you manage this kind of issue?

I think the best way to do it is how we have been doing it: through partnerships. 

Canonical works with ODMs and OEMs worldwide, across industries of all kinds, to help navigate and stay afloat of the rising tide of cybersecurity regulations. Our work with Mediatek is just one example of our expansive efforts to create devices and systems that work, securely, and which are maintained well beyond the support and security life cycle minimums of the CRA. 

By working closely with Silicon vendors, manufacturers, and distributors, Canonical creates a continuum of security updates and support that enables secure open source across a rapidly expanding ecosystem on devices. What this means in real terms for developers who worry about the CRA is that many of the anxiety-inducing facts you saw in my above-mentioned Favourite Slide are much more streamlined: you get a trusted source to pull your open source with a set of commitments and depend on a partner to help you address those vulnerabilities and gain peace of mind. 

IEI partner event

Shortly after the Embedded World trade show, we found ourselves in the beautiful Grand Hotel in Nuremberg for the Next-Gen Edge Intelligence 2025 Seminar, organised by our long-time ODM partner, IEI Integration group. With my colleague Joe Dulin, Canonical’s VP of Devices Sales, we presented how Canonical can shorten the time taken to secure products and get them to market – in part, by being CRA compliant from the get-go.

During this seminar, we shared some detailed insights into how Canonical products help manufacturers and developers navigate the increasingly complex world of producing secure and CRA-compliant devices for the EU market. It was relatively normal stuff at an event like this – but what was really interesting were the conversations I heard at the event: manufacturers, developers, suppliers, and providers alike all expressed anxieties around how they could meet the CRA’s vulnerability monitoring, disclosure, and patching requirements. 

It’s easy to see why, given the extra pressure the CRA places on manufacturers to meet reporting obligations for vulnerabilities, even before being bound to its other numerous requirements. While manufacturers, importers, and distributors of hardware and software products have 36 months from the CRA’s official publication to adapt to the new requirements, there is only a 21-month grace period for manufacturers to adopt reporting obligations for incidents and vulnerabilities.

So, the pressure is on to build a robust framework for monitoring, disclosing, and reporting vulnerabilities and incidents. 

Luckily, you have options.

How do you solve patching and support to meet CRA compliance?

In general, manufacturers and developers have two choices: 

1. Meet all the compliance requirements of the CRA themselves, and manually manage the device patching and security updates for their entire fleet of devices made for the EU market, or,
   
2. Consume your software supply chain from a vendor who has taken on the manufacturer responsibility for CRA compliance – who can provide timely patches for you in an automated way.

Canonical has committed to make our OS – Ubuntu – a first-class CRA-compliant distro and to meet the manufacturer’s requirements for the software we produce and that is embedded into PDEs.

The heart of this commitment is Ubuntu itself. Its performant and security-centric design, open source nature, and consistent patching schedule make it the go-to OS for developers and IoT manufacturers. This is reinforced by Ubuntu Pro, which provides up to 12 years of support – far beyond the 5 year absolute minimum that the CRA requires.

Of course, managing vulnerabilities is one thing. Managing those vulnerabilities across thousands (or even millions!) of devices is an entirely different story – and Landscape is the hero of that tale. Landscape allows a secure and efficient fleet management, which is vital for managing security patching and package updates at scale across your entire fleet of devices that are in the EU market.

Of course, long term support is easier said than done. There’s a common misconception that it’s simply about fixing bugs in the latest versions of your devices and PDEs. 

If only it were that simple! In reality, LTS is much harder and more demanding, because it’s about backporting every single CVE to all the previous  versions of your software and devices for the entirety of their supported lifecycle. 

Think about how we manage security patching for our Ubuntu operating system: in this context, providing long term support across the entire lifecycle of our product is about keeping all the releases which are less than 10 years old (e.g. 14.04, 16.04, 18.04, 20.04 and 22.04) secure by ensuring that the fixes we apply to 24.04 are available to those versions too. 

It’s easier for us because we’ve been doing this for over 20 years, and have an incredibly talented security engineering team who created a process which allows us to backport a CVE fix created for Noble back to Trusty, aka Ubuntu 14.04! And not only are we doing this for the kernel, but for more than 36,000 libraries too. 

For entrants to the devices market, managing the long-term lifecycle of their products is a steep task, because they won’t have these specialized teams or decades of experience. That’s why the most practical step is to consume your security updates through your device operating system, via Ubuntu Pro. All of the security patching work we do is all available under a single Ubuntu Pro licence. The benefits for a manufacturer are obvious, as it means that they do not need to “upgrade” their application for this entire lifecycle, as long as they apply our security updates – freeing them from manually patching packages themselves and simplifying their path to CRA compliance.

EU Cyberact event in Brussels 

Finally, during March, I was invited to participate in a Panel during the International Conference on the EU Cybersecurity and Resilience Acts in Brussels, called “How to deal with open source software used in a product under CRA”. The panel discussed the impact of CRA on the open source ecosystem, and was was led by various experts and leading voices in meeting the CRA requirements, like  Arnaud Martin (Agoria), Mikael Barbero (Eclipse Foundation), Jordan Maris (Open Source Initiative (OSI)), Matteo Molé (European Cyber Security Organisation (ECSO))… and myself.

The short version of my talk is that CRA is raising the bar for the playing field: it will re-educate the market to be accountable for the software shipped along with a device.

My hot take on this very controversial topic is all about responsibility. Nobody would trust a car maker who tells you they don’t know where the brakes come from. Nobody would trust a cook who tells you they put mushrooms in your meal, but they’re not sure if they are safe to eat. Similarly, on the devices market in the EU, no one is going to trust some device manufacturer who doesn’t take their software supply chain security seriously. 

If you plan to include an open source component to your product, you should feel entitled to make sure that the component will not break your entire product. For people who have been manufacturing products forever, and are more than acquainted with BOM, the “SBOM level-up” should come as no surprise.

Personally, I found the panel discussion very enlightening, and the follow-up questions clearly pointed to two key concerns from the market: 

1. How are we going to certify? There’s still uncertainty around meeting which certification standards we will need to meet, which creates turmoil. While Common Criteria and 62443 have been used to benchmark products, we are all waiting on the Implementation Act to provide clarity.

2. What is the exact role and liability of a steward and how do I use it to waive my own liability? It’s interesting to see that the exact scope around the steward role is still subject to debate between people from different open source foundations and representatives of the EU! At Canonical, we will be taking the manufacturer role for our products, which means that people working with Ubuntu and other Canonical products will engage with us as a manufacturer.

In conclusion, March was an eye-opening month for understanding the depth and richness of conversation that’s happening now around the CRA requirements, even if that regulation is “still 2 years away” (spoilers, it’s much less than that). 

Manufacturers, developers, and IoT providers are all understandably concerned about this new legislation, and most are already taking steps to ensure they’re not left on the back foot, come June next year. Vulnerability monitoring and disclosure, basic cybersecurity design standards, long term patching and support, and clearly defined and secure software supply chains are all top of mind for manufacturers – and that’s proof that our work in meeting the CRA requirements and offering comprehensive long term support and security patches is vital for the future of secure devices and a safe EU device marketplace.

To learn more about how we can help you meet your CRA requirements for vulnerability management, automated patching, and long term support for all your open source packages, visit our Ubuntu Pro for Devices page.

Learn more about the EU Cyber Resilience Act and its numerous requirements on our dedicated CRA webpage.

References:

1. https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis.html
2. https://www.csoonline.com/article/574607/at-least-one-open-source-vulnerability-found-in-84-of-code-bases-report.html

Further reading

Cyber Resilience Act: Yocto or Ubuntu Core for embedded devices?

Understand IoT security and IoT compliance across global markets

What the CRA means for IoT manufacturers