Your Guide to Understanding the EU Cyber Resilience Act

The EU Cyber Resilience Act will transform the IoT ecosystem. Now is the time for manufacturers to start preparing.

The regulatory landscape for connected devices is changing fast. IoT might have felt a little like the wild west for the last 10 years, but not anymore. Regulators are getting serious about the security of these devices, and manufacturers need to act now or fall behind.

The EU is currently in the final stages of agreement on a regulatory framework that requires full compliance in order to sell any connected devices in EU member states. The UK is slightly ahead, as it has already put regulations in place. Meanwhile, the US is following closely behind, although it is taking a slightly different approach based on certification rather than enforced compliance.

This article explains what you need to know about the EU Cyber Resilience Act and outlines the expected requirements to help you prepare for compliance.

Watch Now: How New IoT Security Regulations Will Shape the Industry’s Future

Contents

• What is the EU Cyber Resilience Act?
• Who does the EU Cyber Resilience Act apply to?
• What does the EU Cyber Resilience Act mean for IoT developers?
• When does the EU Cyber Resilience Act come into force?
• How to comply with the Cyber Resilience Act
• Solutions for complying with the Cyber Resilience Act
• How Memfault can help
• How to start planning for CRA compliance

 

What is the EU Cyber Resilience Act?

The Cyber Resilience Act (CRA) is an EU regulation that will require manufacturers of products and services with a digital element to comply with its standards in order to be able to offer those products in EU member states.

It will provide a framework for businesses to use to ensure their products are secure by design and remain secure throughout their lifecycle.

Who does the EU Cyber Resilience Act apply to?

This broad-ranging regulation primarily targets businesses that manufacture and supply connected devices, but it will impact companies and organizations across the entire connected device ecosystem.

The CRA names three organization types, each with different obligations.

1. Manufacturers need to ensure their products comply with the regulations.
2. Importers must only make available products that comply with cyber security requirements and bear the CE mark.
3. Distributors must verify that products bear the CE mark.

The CRA focuses on “products with digital elements,” which includes “any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately” and specifically “products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.”

In summary, it’s safe to assume that nearly every connected device maker will need to comply with these regulations.

Service providers that deliver hardware and software components should be ready to support manufacturers in their compliance efforts, either directly or indirectly. The regulation calls out operating systems, non-embedded software, and AI systems as falling under its remit.

Exactly how the CRA will be implemented is still somewhat uncertain, but the ecosystem at large should start taking steps to ensure they will be prepared.

There is some strife around the treatment of open source software, which the open source community is working to deal with. This centers around the definition of what makes a commercial entity in the context of open source software. We won’t get into the details here, but needless to say, things are going to change across the ecosystem.

Exemptions

It’s worth calling out that there are many exemptions listed. Some examples are for those devices that are already covered by existing vertical-specific regulations such as “medical devices, in-vitro diagnostic medical devices, civil aviation safety, on-type approval requirements for motor vehicles and their trailers and systems. Furthermore, components and products developed exclusively for national security or military purposes and products specifically designed to process classified information.”

 

What does the EU Cyber Resilience Act mean for IoT developers?

The Cyber Resilience Act will extend beyond just secure design principles. The regulation will also mandate that businesses are able to maintain the security of devices across their lifecycle. The regulation splits obligations into two categories: cybersecurity requirements and vulnerability handling.

In most (but not all) cases, businesses will be expected to self-certify their compliance by implementing the necessary tools and processes. In some cases, businesses will need to complete a third-party assessment, and the path to compliance will depend on the product’s classification, which we’ll discuss later in this guide.

Whether you self-certify or complete a third-party assessment, being in non-compliance poses a risk of significant fines if a breach of the requirements is found.

The existing UK PSTI Act carries a maximum penalty of £10MM (or 4% of annual revenue) plus £20k per day fine for continued non-compliance. The fines under the Cyber Resilience Act are yet to be finalized and will be determined at the discretion of member states. However, the regulation itself recommends fines of €15MM or 2.5% of annual revenue, whichever is greater.

When does the EU Cyber Resilience Act come into force?

The Cyber Resilience Act is already “approved.” It was published in December 2023 and received parliamentary approval in March 2024. The final stage is the approval by the European Council, which is expected to occur in late 2024. At that point, the regulation will enter into full force.

Transition Period

There will be an allowance for a transition period so that businesses may design (and/or re-design) products to comply with regulations.

The transition period is staggered based on requirements. Initially, the regulation stated that it would become applicable 24 months after its entry into force, with manufacturers expected to comply with the reporting requirement 12 months after its entry into force. However, a recent revision has extended the timeline to 3 years. This means that compliance will be expected in 2027, but vulnerability reporting requirements may be required by 2026 or earlier.

For makers of connected hardware, this is a relatively short window. Because development projects for connected hardware are typically measured in years, now is the time to start preparing.

How to comply with the Cyber Resilience Act

For specific guidance on compliance with the regulations, we recommend you read the regulation in full.

In the following section, we’ll provide a summary of the regulation and an opinion on the potential impact and solutions for businesses.

Conformity assessment process

The process for conformity varies depending on the grouping your product falls under. The regulation lays out two main groups of products and two further sub-classes, all of which have slightly different routes to compliance.

• Non-Critical Products require manufacturers of connected devices to self-certify that their products are in compliance by submitting a declaration of conformity, as laid out in Annex IV of the regulation.
• Critical Products are broken down into a lower risk group, Critical Class I, and a higher risk group, Critical Class II.
  • For Critical Class I products, manufacturers may perform a self-assessment adhering to an existing standard (such as ETSI EN 303 645) or they may perform a third-party assessment.
  • Critical Class II products will require a mandatory third-party assessment run by a “Conformity Assessment Body” (CAB).

Risk assessment

The regulation requires that businesses perform a risk assessment for all products on which the regulation applies. Although this is laid out in Article 10(2), the regulation doesn’t provide specific guidance on the structure of this risk assessment.

Secure design, maintenance, and support

Annex I(1) of the regulation lays out the requirements for ensuring products are secure by design and can be maintained appropriately throughout their lifecycle. The wording here suggests:

“Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks;”

Products must be delivered without any “known exploitable vulnerabilities” and should take an appropriate set of precautions based on the risk assessment mentioned above. For specific guidance, please review Annex I, which contains an extensive requirements list.

We have summarized the requirements below.

Secure design and configurations

• Designed to limit attack surfaces and reduce impact of an incident using mitigation mechanisms and techniques
• Delivered with a secure default configuration and the ability to reset to its original state
• Has protection from unauthorized access including authentication, identity, or access management systems

Data protection and security

• Complete data protection and security ensuring confidentiality of personal data, data encryption in transit and at rest, and only processing data necessary for the intended use of the product
• Ability to report on data corruption and security-related information through the use of recording/monitoring of access to or modifications of data, service, or functions

Resilience and risk mitigation

• Able to protect availability of essential functions and mitigate DDOS attacks and minimize negative impact of availability of related services or networks

Updates and vulnerability resolution

• Able to patch security vulnerabilities with automatic updates and to notify users when an update is available

Vulnerability handling

Annex 1(2) provides an overview of the requirements for Vulnerability Handling, which are summarized below.

Transparency and testing

• Vulnerabilities and components must be documented in a software BoM
• Apply regular and effective testing and review of security and resolve vulnerabilities without delay
• Enforce a policy for the disclosure of vulnerabilities

Proactive information sharing

• Publicly disclose details of security updates and fixed vulnerabilities in order to allow users to understand severity, impact, and information required to remediate
• Facilitate sharing of information on vulnerabilities in products and third-party components, including contact information for reporting of vulnerabilities

Timely vulnerability resolution

• Enable secure distribution of updates to ensure vulnerabilities are fixed or mitigated in a timely manner
• Share security updates in a timely manner and free of charge, accompanied by an advisory message to guide users on the action to be taken

Solutions for complying with the Cyber Resilience Act

Complying with the CRA is going to be no small feat. However, there are a number of great resources already available to help. In particular, we have found the resources made available by PSA Certified extremely helpful. They have been working for a number of years to improve and standardize security practices for IoT devices. It’s a great place to start!

Although Memfault cannot make comprehensive recommendations as to how businesses might comply with all parts of the regulation, we do have significant experience in a few of the key requirements. As such, we want to provide our view here, noting that the specific solution will be very dependent on your specific use case.

How Memfault can help

Memfault excels at supporting customers in their compliance requirements across a number of specific areas.

Timely vulnerability detection and reporting

It goes without saying that in order to resolve and report issues in a timely manner, you must first identify them. While some degree of vulnerability testing and detection is possible in-house, it’s impossible to account for all the potential variables that happen in the field. Memfault is acutely aware of this problem; in fact, it’s the primary reason why we exist.

Ultimately, there is no replacement for real-world data. Maintaining visibility into device performance in the field is not only critical to identifying quality or performance faults, but also for identifying unaccounted for vulnerabilities that may arise due to user behavior, environmental factors, or other variables.

Collecting robust usage, performance, and behavior data from devices in the field will become even more critical—if not from the entire fleet, then at least from a substantial sample.

This will help establish a realistic picture of “normal” behavior, accounting for the significant variability in the field and making detection of anomalous behavior easier and more accurate. Additionally, collecting data broadly from your fleet will help you more confidently assess how widespread an issue might be.

Data collection tools

Memfault has a robust set of tools to help you collect various types of data from your devices, including crash data, logs, and metrics. Collecting a range of data and being able to correlate a specific issue to a particular software version, hardware version, component, or other factors will be extremely beneficial in compliance with detection and reporting requirements.

This connects closely to the requirement to maintain an inventory of software and hardware components for your deployed devices. If you do identify a vulnerability via in-house testing or field data, it will be crucial to have a clear picture of your fleet’s exposure to the issue and determine it is correlated with a specific component. This is another place Memfault can help.

Memfault provides a complete device inventory that can hold information about the components of each individual device (we call these “attributes”), all of which can be customized and automatically populated. We are developing functionality that will let you store a Software Bill of Materials (SBOM) in Memfault for each individual software version, allowing you to quickly see the prevalence of each version and its components across your fleet at any time.

Updates and vulnerability resolution

Memfault provides a robust, reliable, and secure solution for the delivery of software updates to your deployed devices. Being able to patch security vulnerabilities will be a key requirement for compliance. Manufacturers must provide security updates for at least the duration of the device’s lifecycle. The exact method for doing this will vary depending on use case, but having an efficient way to roll out updates will be critical.

Memfault already provides an easy-to-implement and easy-to-use OTA update management and distribution solution. It comes with full observability capabilities that allow you to complete the full cycle—from identifying the issue to shipping the fix and monitoring the success of the rollout—all in one place.

We know that updates can be hugely stressful for those tasked with “pushing the button” and deploying an update to a production fleet. We have numerous tools to make this process more controlled and to increase confidence in the deployment.

The regulation may force device makers to update their devices on short notice and outside their usual update schedule. This means more updates, more regularly, which comes with additional risk. When shipping an update to patch a security vulnerability, there’s always a possibility that you could accidentally create another issue. Therefore, it will be important to have a controlled shipping process as well as ongoing, comprehensive observability and monitoring of devices receiving updates.

Data protection and security

As the requirements to monitor devices in the field for vulnerabilities and maintain connections for updates increase, the volume of data collected from devices will naturally rise. The CRA has a strong stance on ensuring this data is secure in transit and at rest.

It’s worth mentioning another impending regulatory change in this area: the EU Data Act. The EU Data Act is comparable to GDPR, but it focuses on data collected from connected devices. Additionally, it does not limit oversight to only PII data, but rather all data collected from an end user device. The Act stipulates that manufacturers must be able to provide all data collected from a device to its end user upon request. This has the potential to create significant management challenges.

Here again, Memfault can make the compliance process easier. We are already compliant with all major data security and privacy regulations with SOCII accreditation and built-in tools to ensure GDPR compliance. We are also working on solutions to ensure that Memfault will be able to facilitate full compliance with the EU Data Act when it comes into force in 2026.

The CRA will force businesses to collect data from devices; then, the Data Act will require them to comprehensively manage this data. Memfault has both of these requirements covered.

This allows you to maintain great visibility into device behavior and performance in the field without creating an additional compliance burden.

How to start planning for CRA compliance

The IoT market is about to undergo a seismic shift in its approach to the maintenance of devices deployed in the field. We are in full support of this shift and think it’s well overdue. However, we also acknowledge that it will place a significant additional burden on the manufacturers of connected devices, who already have an extremely complex job putting together these great pieces of technology to improve our everyday lives.

I recently joined my fellow co-founder, Chris Coleman, for an open discussion on the future of the IoT industry in light of new security regulations being introduced. We talked about the driving forces behind the CRA and other regulations, the potential impacts, and how to prepare.

Needless to say, we will be watching the progress of the CRA and other IoT security regulations closely. And we’ll continue to develop our product to support our customers as they build and deploy great connected devices around the world.

More IoT Security Resources for You

• IoT Device Security On-Demand Discussion: A panel of IoT and security experts discuss best practices for safeguarding your connected devices.
• Benchmarks on IoT Security and Other Pressing Challenges: This first-of-its-kind report reveals how hundreds of other IoT professionals are handling security and other development challenges.
• Opinion: Regulators are coming for IoT device security: Insights on what is striking about the new regulations and standards, and recommendations on what to do.