The EU rolls out new security rules for product developers and manufacturers - the Cyber Resilience Act (CRA). At emteria, we’re at the center of this change, working with a wide range of product developers and manufacturers from OEMs to startups. All of them are united in their focus on developing products based on the Android platform.
So we took a step back and looked at the EU cybersecurity framework and the impact the enforcement of the Cyber Resilience Act will have on product builders.
That said, manufacturers and product developers should start prepping for the new EU-wide cybersecurity framework changes.
Please note, we do not provide legal counsel. We are Android experts trying to grasp the extend of the EU cybersecurity framework to the best of our ability. The goal of this article is to give you a comprehensive and understandable overview on the Cyber Resilience Act.
Before we dive into the EU Cyber Resilience Act, let's start by sorting out the difference between some relevant directives:
Getting a grasp of the groundwork set by those directives will give us a well-rounded view of the cybersecurity environment in the EU.
RCE Directive (2022) replaces ECI Directive (2008) and NIS (2016) is updated to NIS 2 Directive (2022). Leaves us with two out of four. Both directives regulate European operators of critical infrastructure. RCE deals with the definition and resilience of critical infrastructure whereas NIS 2 regulates their cybersecurity measures.
Here is an overview:
Source: Own illustration / Canva
The Cyber Resilience Act (tba, 2024) - which we will look at shortly - does not address cybersecurity for operators of critical infrastructures, but for product manufacturers in general. This is a huge novelty!
As NIS 2 Directive and CRA are often mentioned in the same sentence and are at first difficult to distinguish, here is a bit more background on NIS 2:
What is the NIS 2 Directive?
The EU directive serves as a framework to regulate network and information security within companies that are defined as critical infrastructure. The primary goal of the NIS 2 Directive is to enhance and standardize cybersecurity measures across the critical infrastructure in the EU.
In simpler terms, the NIS 2 Directive is the EU's ultimate cybersecurity rulebook for critical infrastructure companies, setting consistent security rules and standards across all EU member states.
The NIS rulebook enforces that companies should ensure certain security measures are accounted for in their cybersecurity strategy. Those measures include:
In particular, healthcare or cloud providers and public administration are instructed to take appropriate and proportionate technical, operational and organizational cybersecurity measures.
Originally introduced in 2016, the NIS Directive underwent a significant update in December 2020, resulting in the NIS 2 Directive (2022).
This updated version brought some notable changes:
When does the NIS 2 Directive comes into force?
NIS 2 Directive is already in effect, replacing the original NIS Directive. EU member states have until October 2024 to integrate it into their national legislation.
The Cyber Resilience Act (CRA) is a vital extension to current regulations like the NIS 2 Directive, working hand in hand to strengthen the overall EU cybersecurity framework. Rather than competing, CRA complements by targeting product manufacturers of a particular product group.
What is the EU Cyber Resilience Act?
The Cyber Resilience Act (CRA) is an EU regulation that ensures essential security measures are enforced for products with digital elements, including software, hardware, and components, throughout their entire lifecycle.
Whereas NIS2 serves as a broader security framework to establish uniform security rules and standards for critical infrastructure operators, CRA focuses on protecting customers buying digital products from manufacturers.
But why did the EU think an addition to existing legislation was necessary to specifically regulate product manufacturers and products with digital elements?
First introduced in September 2022, the EU CRA was an answer to the increase of security exploits, in particular supply chain attacks. These attacks spread through the software supply chain and affected many products. Those products used the same software components all weakened with major vulnerabilities. The damage was done to companies that relied on these components and to the end users of the devices, not the original manufacturers.
The motivation for enacting the CRA by the EU can be summarized in three major points:
Especially "the fact that many manufacturers do not provide updates to address vulnerabilities" is highly concerning! Source
The main reason for this — at least from the POV of the EU — is that exploited security risks mainly impact the manufacturers' good name, whereas users have to pay for costs caused on their end. This makes it unattractive for manufacturers to invest in a robust update infrastructure, as they do not benefit from it straight away.
This might be true to a certain degree but in our experience even if product builders and manufacturers are encouraged to update their devices regularly it is not as easy as it might seem. We are spoiled by our smartphone updates that simply appear on our phones and can be carried out quickly and easily. Devices come in various form factors, hardware architectures, and software stacks, making it challenging to create a one-size-fits-all Over-the-Air update solution.
We'll dive into this a little further later on.
When does the Cyber Resilience Act come into force?
The date is dependent on the final publication of the Cyber Resilience Act which is expected to be in October 2024. If this happens, member states have 36 months to prepare before CRA will come into full force in 2027.
The Cyber Resilience Act impacts manufacturers of hardware products like mobile devices and network devices. Also, it extends to software manufacturers and importers of products with digital elements (white-label goods). All of them need to understand and fulfill their responsibilities within the supply chain.
Here are some examples:
Special regulations apply to manufacturers of so-called “critical” or "highly critical" products, which must undergo a conformity procedure.
There are two categories:
Some products that contain digital elements are excluded because other regulations cover them:
Software that is part of a service (SaaS) or developed in-house is excluded from the CRA requirements. In this case, solely the NIS2 Directive takes over.
What are the implications for manufacturers? Short answer: They need to comply with CRA during the whole product lifecycle.
This includes:
Monitoring in this context means vulnerability scanning. If vulnerabilities are detected or publicly announced by other parties companies need to provide free security patches. Besides providing those updates, end users must be informed on how long their purchases will be supported. This period should meet the expected time of use - 5 years.
This EU-defined time of use mostly fits consumer products. A lot of industrial and professional devices are used way longer. We are talking about up to 10 years and counting. This is why long-term support (LTS) is a critical topic for many product builders!
Manufacturers need to pass a verification process to make sure they meet legal obligations. This is mandatory! This is a big change in responsibility since before CRA this was only known for economic operators.
What exactly does that mean? Security is officially becoming a product characteristic, as part of the CE marking (CE stands for Conformité Européenne).
How does the CE marking work?
If a manufacturer wants to sell in the EU, he cannot simply do that. He needs to get his products certified to make sure they fulfill EU requirements. The CE marking states that he did that and that his products are safe in terms of EU standards.
Source: Own illustration / Canva
The Cyber Resilience Act uses the existing legal framework for CE marking. This legal framework will be extended to include security measures for products with digital elements.
The process of getting a CE marking is called the "process of conformity assessment." Audits can be carried out internally for uncritical products and critical products (Class I) - with a stricter verification procedure - or externally for highly critical (Class II) products. CE marking also has a legal framework, which is regulated in the New Legislative Framework for Product Legislation (NFL).
What is the New Legislative Framework?
The EU's New Legislative Framework (NLF) is a package of measures designed to improve market oversight and increase the quality of conformity assessments. It also clarifies the use of the CE marking and creates a toolbox of rules and measures for product legislation.
Now it's getting even more confusing. Let's summarize: CRA stipulates that products with digital elements now also need a CE marking. How conformity assessment is carried out is standardized in individual industry-specific regulations that are based on the New Legislative Framework (NLF).
Lots of frameworks and rules... Hopefully, we have not lost you yet since we are now jumping into the most interesting part.
Before we do that let's make a quick summary of CRA:
Cyber Resilience Act at a glance
- Manufacturers are required to meet the cybersecurity requirements of the CRA during all phases of product development and marketing.
- They must monitor their products throughout their entire lifecycle (defined as 5 years in the CRA) and provide free updates for security vulnerabilities.
- Incidents affecting the security of a digital product must be reported to the EU cybersecurity agency ENISA within 24 hours.
- The CRA establishes specific regulations for manufacturers of critical products, requiring a separate conformity procedure in line with CE marking.
- Companies must ensure full security updates and inform consumers completely and transparently.
- Providers and manufacturers of products with digital elements should implement Security by Design from the outset and ensure secure use through security updates.
Congratulations on getting through the theoretical aspects. Now, let's jump into an example to bring this complex framework to life.
A company wants to build a POS system to be delivered to its customers - a large supermarket chain.
To get started, the company purchases a custom hardware board to be operated with Android. The board manufacturer supplies an Android BSP (Board Support Package). The company must rely on the BSP being securely designed and receiving updates for a certain period to ensure security throughout the supply chain.
However, this is not the current reality! Based on our experience, it is often difficult to obtain an Android BSP that meets minimum quality guidelines. Additionally, security and version updates are typically not provided.
When CRA comes into force, this should change. The board manufacturer will be obliged to comply with CRA and provide security updates. Otherwise, he will not get a CE marking and can not deliver to the EU. Good news right?
Yes! But... As you might have guessed this is not where the challenges for product builders end. Assuming the board manufacturer supplies updates: How are these used in customized Android OSes that where developed based on the BSP? How do these updates reach the end customer - the many stores of a supermarket chain? Manually? Hopefull not!
The company needs a sufficient Over-the-Air software update infrastructure not "just" for Android OS updates but for applications to run on the device as well.
In this scenario, the company must still:
The company must implement all these requirements for its part of the supply chain and ensure that all necessary security updates and information obligations are met.
It is crucial not to underestimate the level of effort needed by companies to meet the new CRA regulations. Proactive measures must be implemented early on to ensure that their upcoming product lines align with CRA compliance standards.
Besides the bureaucratic and implementation effort needed to meet CRA standards, there are concerns regarding Open Source software. The CRA is focused on commercial products but as we all know Open Source components are part of many commercial products. Where are the boundaries?
The EU stated that they have no interest in regulating the Open Source or research community. Nevertheless, the initial draft caused a great deal of uncertainty. However, the community's subsequent efforts proved successful: CRA comes now in an adapted form, with extensive exceptions for the Open Source community.
Assuming you do not qualify as Open Source exception: Do not panic!
Whenever new regulations are rolled out, there is a lot of uncertainty. If your company is affected by one of the newly implemented cybersecurity regulations, you should:
Do you have questions about updates and are looking for a solution to keep your Android devices secure and up-to-date? Don't hesitate to contact us.
We are Android experts, no legal advisors! From our POV the new EU regulations and directives make a lot of sense. We have preached for years how important security updates are and help our customers to:
If you are looking for a partner to help you with the practical implementation of the CRA update requirements, you have come to the right place.
Sources: