What The Cyber Resilience Act Means For IoT Manufacturers

Stephanie Domas is the CISO of Canonical, the makers of the open-source Linux operating system Ubuntu.

With the EU Cyber Resilience Act (CRA) entering into enforcement, I thought it would be valuable to share some insights into designing compliant, secure IOT devices. In this article, I’ll walk through the CRA’s cybersecurity requirements and share a blueprint for how the operating system can play a huge role in making market-ready and CRA-ready products.

How Device Manufacturers Can Prepare For The Cyber Resilience Act

Broadly speaking, the CRA concerns itself with several key areas you must address. These are:

1. Robust organizational security processes.

2. Good cybersecurity principles at the design level of the device.

3. Robust device security, such as better identity management and default access.

4. Clear processes for monitoring and patching vulnerabilities.

5. A clear roadmap for ongoing support and security updates for devices.

6. Standardized reporting channels and processes for vulnerability discoveries.

7. Public information and awareness of all vulnerabilities.

8. A clear device software supply chain.

9. Clear policies for the legal collection, storage and processing of private user data.

Of course, a concept like “improve device security” can seem overwhelming. Where would you even begin? Well, let’s start with the operating system (OS) blueprint that we use for device security.

The Operating System Blueprint For Creating Resilient, CRA-Compliant Devices

Start at the OS level.

You should always assume that your devices are going to be deployed in an insecure environment. From this standpoint, the OS is the most critical security factor you need to consider, as it is the basis of all other security measures.

The OS should be simple, functional and have a minimal attack surface.

IoT devices often have very few resources available in terms of CPU cycles, memory and storage. As a result, the OS used needs to be streamlined and take up as little space as possible.

However, reducing data usage and increasing simplicity is much more than getting an OS to run on a device; it also helps to make an OS more secure. The less complexity, the fewer points of vulnerability.

Your IoT OS needs to include security updates.

New vulnerabilities are discovered every single day, and the CRA requires you to discover, patch and report them ASAP. Your device and the OS it uses need to have a strong support foundation with easy methods for regular security updates.

The OS must have a centralized update mechanism.

The ability to update software reliably and automatically is non-negotiable for any IoT OS that has to meet CRA readiness. This is especially important for IoT deployments that:

• Feature large numbers of devices.

• Lack a regular update plan.

• Lack a clear UI for end-user updates.

• Are in remote locations that are difficult to access.

Authenticating your updates is equally important. Authenticated updates provide a mechanism to shield users from the negative consequences of human error or vendor failures. When your devices receive updates, it’s vital to be certain that these updates are verified.

The OS should feature automatic, inbuilt rollbacks.

Sometimes, things just go wrong; the incorrect patch is pushed, or an update introduces new vulnerabilities. Accordingly, your on-device OS must be able to automatically roll back to the last known working configuration to help keep them working and secure.

Secure system and critical files.

Preventing unauthorized tampering with trusted files is vital. As a baseline, your essential device and application files should be authenticated and protected against unwanted changes through read-only protection. These files should also require universal digital authentication to be replaced. This allows a far greater opportunity to examine the integrity of each snap before installation and guarantee this integrity over time.

Applications should be self-contained and sandboxed.

Apps or devices sometimes need to share data. However, these situations should be treated as specific cases with specifically designed processes because a free flow of data between applications provides malicious actors with an attack vector. Therefore, your applications should be segregated into their own restrictive sandboxes, minimizing the damage that can be done by compromised applications.

The OS should feature familiar architectures and known coding methods.

Simpler is always better. It can be tempting to use niche frameworks, architecture or languages to build your device or applications, but it’s almost always better to operate within a known framework and ecosystem. In general, using more conventional stacks and on-device OSes brings more support, faster fixes and better vulnerability discovery, which helps respond to the security and disclosure requirements of the CRA.

Ongoing long-term support must be a day-one consideration.

The CRA requires manufacturers to provide a schedule of updates to their devices across their entire life cycle. Consequently, your market approach must consider support strategies that make it cost-effective and simple to ensure your products remain viable and functional, even years past their intended life cycle.

Documentation and software supply chains should be clear and comprehensive.

A well-documented device and system is easier to manage, improve and secure. Good documentation also gives the end user peace of mind. What’s more, the CRA will require you to document and disclose quite a large amount of information about your products or services. Document everything you can, as clearly as you can.

Considering CRA-Ready Providers

Meeting CRA compliance on your own is a challenge. 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, consider reevaluating your providers and choose those that make it easier to meet CRA obligations.

The CRA will have considerable effects on your IoT devices, from documentation requirements and update schedules to long-term device life cycle management. There are many factors of your IoT device design and security that you need to be thinking about consistently, but getting the OS right can go a long way for products ready to hit the market.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?