I’ve written about the EU Cyber Resilience Act (CRA) on our Canonical blog a few times now, and I think now’s the perfect time to talk about the implications of this new regulation and what it means for IoT and device manufacturers on the practical level of how they design and build Products with Digital Elements (PDEs).

In this blog, I’ll give you a thorough overview of common IoT manufacturer and PDE developer practices that need immediate attention, and how to change or improve these practices so that your work and PDEs can keep their place on the EU market with full CRA compliance.

What you can’t do under the CRA (and what to do instead)

In general, the things you can and cannot do under that CRA depend on how you and your PDEs are classified or categorized under this new piece of legislation. If you’re not familiar with the CRA’s wording, classifications, and requirements, you can catch up on the specifics by reading the previous articles I wrote here:

• A CISO’s comprehensive breakdown of the CRA: Catch up on what the EU Cyber Resilience Act is, what the CRA requirements are, and how it will broadly affect cybersecurity design, documentation, and long-term support and vulnerability management for devices. 
• What the CRA means for IoT manufacturers: Explore how the CRA will affect all IoT manufacturers looking to market their devices and products in the EU.
• How the CRA will affect open source software: Get an overarching insight into how the CRA came about, the community reaction to this regulation, and what it means for open source going forward.

However, outside of the category- and classification-specific requirements of the CRA, this regulation introduces an extremely broad set of changes to IoT and PDE cybersecurity and vulnerability management that will affect everyone, regardless of where they fall under the CRA’s specific wording. 

Let’s take a closer look:

No more passing the buck

No more passing security responsibility to your downstream users or expecting that your upstream providers will take care of vulnerabilities. In fact, building and shipping things often means you will be categorized as a manufacturer, which means that you will be burdened with an increased level of compliance assessment and higher demands for PDE compliance. 

If you don’t want to bear the brunt of Manufacturer compliance, you should find a supplier willing to assume that responsibility. 

You can no longer hide behind documentation – or treat it as optional

You can no longer hide behind documentation. If there are vulnerabilities, limitations, or flaws in the PDE, or specific outlines for its use, you cannot simply expect users to have fully read your documentation and follow these hard-to-find instructions to use your product safely. 

On a practical level, this means that instead of simply documenting vulnerabilities and communication – for example, telling users not to use the device on unsecured networks, to change the password before use, or to manually disable certain ports or features before use. It’s no longer enough to document vulnerabilities and then warn users about them: you need to patch them yourself. 

And when it comes to documentation, the CRA outlines stricter requirements for how to approach your docs and make them accessible. In general, the CRA means you will have new documentation requirements, with more communication around where this documentation can be accessed, and you’ll need to produce a software supply chain and formal software bill of materials (SBOM) that is accessible and machine readable. 

As a minimum, you need to have the following documented and available for the public and EU authorities:

• A description of the design, development, and vulnerability handling process
• An assessment of cybersecurity risks
• A list of harmonised EU cybersecurity standards the product meets
• A signed EU Declaration of Conformity that the above essential requirements have been met
• A Software Bill of Materials (SBOM) documenting vulnerabilities and components in the product

You can no longer hide behind intention

It’s not just documentation that you can’t use as a crutch or shield – intention is out too.

This means that you can’t defend flaws, design issues, or vulnerabilities as intentional design choices. For example, if your device has ports, features, or functionality that could reasonably be used to access the device or connect to networks, you need to take steps to mitigate the risks and attack vectors that these elements pose. 

In the next section, we’ll go through some of the practical steps you can take to address device cybersecurity.

The security basics are no longer optional

Many of the requirements of the CRA simply formalize cybersecurity practices and security features that should be considered as minimum standards. By this I’m referring to things like shipping with known vulnerabilities, expecting users and consumers to secure your devices after purchase, ignoring cybersecurity fundamentals like no default admin-password credentials, or hiding behind obscure or inadequate documentation. 

Some of these cybersecurity essentials include: 

• Ensuring that whatever you’re building is as secure as it can be. It must have minimal attack surfaces. 
• Hardening your device or product. Its data must be encrypted or protected and it must prevent unauthorized access.
• Preventing downtime. Your device must keep working, even under DDoS attack, and it mustn’t interrupt other devices, even when attacked with exploits.
• Keeping track of activity. Your device needs to be able to provide security data by monitoring or logging changes in the device. 
• Proactive patching. Your product needs to be able to receive security updates or rollbacks. This includes direct or remote updates, user notifications about updates, and the ability to roll back updates or reset the product to a factory/default state.

Even without the CRA compelling you to meet higher cybersecurity standards, you should be meeting these basic standards in PDE security design. Here are some steps you could take to ensure your PDEs are as robust and secure as possible before they reach the market:

• Implement a Zero Trust Architecture wherever possible
• Ensure that your authentication, authorization, and access control are fully secure (and that you have control over your credentials)
• Use Secure by Default configurations
• Minimize your attack surface – if your device, system, or organization isn’t actively using something (whether it’s a port, component, or package), then disable it by default until it’s needed
• Ensure proper use of cryptography to ensure data is protected at rest and in transfer, that traffic is encrypted, and that you avoid plaintext or cleartext data
• Validate all input and handle all exceptions
• Secure all individual components and their dependencies, not just the stack
• Minimize the access permissions of apps and systems, and design your baseline to stop server-side request forgery from Day Zero
• Use automated security patching software to ensure that validated and authenticated security updates, CVE fixes, and other patches are downloaded timeously and automatically 

In short, the goldrush of taking unsafe IoT devices to market is over: consumers have higher expectations for the security and privacy of the devices they use, and if your products don’t meet them, it will lead only to disaster down the line. We understand the serious impacts that CVEs have on users and businesses alike, which is why we take such a strong commitment to patching critical CVEs within 24 hours through Ubuntu Pro.

Ubuntu Pro gives organizations a hands-free, automated way of receiving vital software packages and security updates for up to 12 years, ensuring that they’re covered no matter what new vulnerabilities or regulatory compliance comes up. 

You can no longer ignore products after launch

Another priority you should focus on is patching and vulnerability management for your devices and software. One of the CRA’s primary requirements is to ensure that your devices can be securely updated against new vulnerabilities. Your updates must be free and sent out as soon as vulnerabilities are discovered, along with information to users about what actions they should take.

When this happens, you need to provide:

• A description of the vulnerabilities and their severity
• Information allowing users to identify the product with digital elements affected
• The impacts of the vulnerabilities
• Information helping users to remediate the vulnerabilities

What’s more, these patching and security update efforts must be long term, and cover the PDE’s entire lifecycle. You must regularly test the product, and fix vulnerabilities immediately – and once a fix has been applied, you need to publicly disclose what the fixed vulnerability was (in line with the new coordinated public disclosure policy you need to have, under the CRA). 

And for a period of a maximum of 5 years (or the product lifespan, whichever is shorter) you’ll be required to recall or withdraw products that don’t meet conformity standards of the CRA.

No more hidden or gray dependencies

Whether you’re classified as a manufacturer or not, you still need to think about your software supply chain like a manufacturer does. This is because the CRA introduces new requirements for documentation, transparent software supply chains, and a software bill of materials to show your software is securely sourced. As a minimum, you should be consuming trusted open source only, or only sourcing packages from trusted suppliers. 

If you’re unsure about your software supply chain and its ability to meet the CRA’s regulatory standards, documentation requirements, vulnerability disclosure demands and transparency expectations, you should evaluate your service and software providers to choose those who make it effortless to meet your CRA obligations. 

Generally, this means picking a vendor who meets one of the following criteria:

• Has a CE marking
• Can provide supply chain certification
• Has decided to take on the category of ‘Manufacturer’

Our recommendation is to consume packages or software updates from large and trusted suppliers who have taken on responsibility for CRA compliance. This means that you should be sourcing versions of your open source software, (or security patches for that software) directly from a vendor who has decided to take on the category of ‘Manufacturer’ in the software supply chain.

At Canonical we understand how important this is, which is why we’ve committed to meeting the manufacturer responsibilities for many of our products. The many, many tools and products we develop and maintain at Canonical – Ubuntu; our distributions of Kubernetes, MicroCloud, and OpenStack; and more – are designed with security in mind, supported through security maintenance and vulnerability patching, and aligned with the regulatory oversight in the CRA. On top of this, services like Ubuntu Pro for Devices ensure your devices will receive security maintenance for up to 12 years. 

No more “market-first” approach

The days of “move fast and break things” are over. Under the CRA, you cannot hyperfocus on market timing or a launch date and ship an MVP that skimps on security design and long-term support. Instead, you need to build on a strong foundation for security and support for your packages and software that extends for many years past your launch date.

You should be reassessing your choices – of OS, development environment, and software vendors – to meet this new change. And the systems you do choose should give both the robust baseline of security and the long-term security support the CRA requires – as well as the minimized attack surface that reduces the number of attack vectors and vulnerabilities as much as possible. 

Luckily, this has benefits that go beyond security: a minimized attack surface, device-optimized OS, or containerized build keeps everything to the smallest footprint possible – which means faster performance, lower device specification requirements, and cheaper manufacturing costs. In fact, Ubuntu Core (the embedded Linux OS for devices) takes these requirements and benefits to heart: it acts as a pared-down, strictly confined flavor of Ubuntu for embedded devices. Ubuntu Core has an optimized profile that’s perfect for devices that have limited specifications or hardware but which still demand robust security, long-term maintenance, and high levels of on-device performance. 

Summary of what you need to change to meet CRA compliance

In conclusion, the CRA means that a lot of things have changed. Gone are the days of hiding behind obscure documentation, passing the buck to manufacturers or users, or launching market-first, “fire-and-forget” devices with unknown dependencies and no support. However, by intensifying the security of your PDEs with cybersecurity basic practices, consuming trusted packages and security updates from a manufacturer-category supplier with a long-term support program, and building a clear list of your software supply chain and dependencies, you can easily meet these new requirements head-on, and access the EU market for years to come. 

To sum everything up, if you want to meet the new challenges and requirements of the CRA head-on, you need to follow these simple 6 steps: 

• Adopt best practices for PDE hardening and device security
• Implement cybersecurity hardening to the greatest extent possible
• Conduct your compliance assessment and testing as soon as you can
• Document everything and make it publicly available, along with SBOMs that show your software composition and dependencies 
• Take a customer-first approach, and beware of rushing an MVP to market
• Pick vendors who take on manufacturer responsibility for packages/software

To find out more about how Canonical can help you to meet the EU Cyber Resilience Act requirements for your devices, visit or comprehensive CRA webpage at https://canonical.com/solutions/open-source-security/cyber-resilience-act or fill out this form to contact our team of compliance experts.

Learn more

Find out how you can design and support CRA-ready PDEs by bringing up to 12 years of automated security patching to your device by visiting www.ubuntu.com/pro

Learn how Ubuntu Core is ideal for your PDEs, IoT devices, and all embedded systems by visiting www.ubuntu.com/core 

More reading

• Understand IoT security and IoT compliance across global markets [Free white paper]
• Read our CISO’s full breakdown of the CRA
• Explore the impacts of the CRA on open source
• Cyber Resilience Act: Yocto or Ubuntu Core for embedded devices?
• What is SBOM? Software bill of materials explained
• What the CRA means for IoT manufacturers