IoT and new EU cyber security obligations and liabilities

As smart home technology expands, so does the range of connected devices, better known as the Internet of Things (IoT). From smart locks and facial recognition doors to intelligent thermostats and even Internet of Bodies (IoB) devices such as smart pacemakers: the variety and number of IoT devices rises, while the level of cyber security of these IoT devices lags behind.

This article provides a high-level overview of incoming cyber security obligations and liabilities for IoT devices under the EU's Cyber Resilience Act (CRA), the revised Product Liability Directive (PLD) and the AI Act, excluding related obligations under (proposed) legislation such as NIS2, DORA, the Data Act, and the General Product Safety Regulation.

New security obligations for IoT devices under the Cyber Resilience Act

In March 2024, the European Parliament approved the CRA – leaving only the Council’s approval before the CRA becomes law. The CRA will apply to "products with digital elements" (PDEs) which is defined broadly as all software and hardware products and their remote data processing solutions made available on the market, where the intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network – in short, all hardware and software products that can have a data or network connection when in use. The CRA excludes medical devices, aviation, and cars, which are already covered by existing rules.

PDEs may only be placed on the market if they meet the rather generic “essential requirements” listed in Annex I of the CRA. The concrete formulation of the requirements is to take place in so-called “harmonised standards” which are currently still being developed. The “essential requirements” include:

• Cyber security by design - ensuring that PDEs are designed, developed and produced in such a way that they ensure an appropriate level of cyber security based on the risks
• Cyber security by default - ensuring that PDEs are being made available on the market with a secure by default configuration (with room for different contractual arrangements for tailor-made products) including the ability to reset the product to its original state
• Updating to address vulnerabilities which can be addressed through security updates, including through automated security updates. Such updates must be provided for the duration of the support period (see below) and must remain available for ten years after the PDE has been placed on the market or for the remainder of the support period, whichever is longer
• Unauthorised access prevention by appropriate control mechanisms, such as authentication, identity or access management systems
• Protecting the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state-of-the-art mechanisms
• Protecting the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against any manipulation or modification
• Data minimisation by processing only data, personal or other, that is adequate, relevant and limited to what is necessary in relation to the intended purpose of a PDE
• Protection of the availability of essential and basic functions, in particular after an incident, through resilience and mitigation measures of denial-of-service attacks, and
• Data portability allowing users to permanently remove all data and settings securely and easily and, where such data can be transferred to other products or systems, in a secure manner.

Although the CRA applies broadly to PDEs, it focuses particularly on “important” or “critical” PDEs. Important and critical products are divided into different lists based on their criticality and the level of cyber security risk they pose. Important and critical products with digital elements are subject to additional requirements, especially with regards to the relevant conformity assessment as mentioned above. PDEs are considered to be “important” when they have the core functionality of a product category set out in Annex III, such as smart door locks, baby monitoring systems and alarm systems, connected toys, operating systems and personal wearable health technology (Class I) and firewalls or intrusion detection or prevention systems (Class II).

Manufacturers, importers and distributors of PDEs are subject to specific obligations.

Obligations on manufacturers of PDEs

These include:

• Risk assessments - manufacturers must ensure that a PDE has been designed, developed, and produced in accordance with the “essential requirements”. As such, the manufacturer must assess the risks associated with a PDE and take the outcomes of such assessment into account during all phases of the PDEs’ lifecycle. The risk assessment must be documented and updated during the support period and must include an explanation of how the manufacturer complies with the vulnerability handling requirements.
• Documentation and reporting - manufacturers must document relevant cyber security aspects concerning the PDEs, including vulnerabilities of which they become aware. Any actively exploited vulnerabilities and incidents must be reported to the competent national authorities via the incident reporting platform supervised by the EU agency for cyber security (ENISA) not later than 24 hours of becoming aware of the vulnerability or incident (for preliminary notification) and 72 hours (for full notification).
• Monitoring and software updates - the manufacturers must determine the relevant support period, taking into account the economic lifecycle of the product and users’ reasonable expectations. The support period must be at least 5 years, except for products which are expected to be in use for less than that and manufacturers must monitor their products during such period and document relevant cyber security aspects
• Conformity assessment and CE marking - the manufacturer must perform the applicable conformity assessments as specified in the CRA. For non-important and non-critical PDEs, an internal conformity assessment will be sufficient. “Important” and “critical” PDEs are subject to stricter conformity assessment procedures. The CE marking is the visible consequence of the conformity assessment in a broad sense and should be affixed to the PDE in accordance with the CRA
• Transparency - the manufacturer must maintain technical documentation and produce user instructions in a clear and intelligible form. Such instructions must be provided in a language which can be easily understood by users and market surveillance authorities. 

Obligations on importers of PDEs

Before placing PDEs on the market, importers must ensure that:

• appropriate conformity assessment procedures have been carried out by the manufacturer
• the manufacturer has drawn up the technical documentation
• the product bears the CE marking
• the product is accompanied by clear, understandable, intelligible and legible information and instructions which ensure secure installation, operation and use.

Importers must not place a PDE on the market where they consider that it is not compliant with the “essential requirements”.

Obligations on distributors of PDEs

Before placing PDEs on the market, distributors need to verify that:

• the PDE bears the CE marking
• the manufacturer has accompanied the information and instructions and the EU declaration of conformity
• the importer has indicated their name, registered trade name or registered trade mark and a contact address on the product or on its packaging.

Open Source Software

Following heavy criticism of the early drafts - the latest version of the CRA includes specific exclusions for certain Open Source Software (OSS), the provision of which does not involve “economic activity”. It introduces the concept of the “open source steward”: a legal person who provides support for the development of OSS which is intended for commercial activities, and who plays a main role in ensuring the viability of those products. The main job of the open source steward is to support and maintain the OSS, ensuring it stays secure and functional for commercial use with fines associated with non-compliance. The recitals to the CRA state that the open source steward is therefore subject to a “light-touch and tailor-made regulatory regime” but the CRA still leaves a lot of unanswered questions as to who will do what and how the regulatory work load can be efficiently allocated in complex open source projects.

Enforcement

Member States will appoint market surveillance authorities responsible for enforcement of the CRA. They will have the power to require non-compliance to be brought to an end, to prohibit or restrict the making available of a non-compliant product, or order its withdrawal or recall. 

Market surveillance authorities will be able to issue fines with the most severe range of penalties set at up to a maximum of EUR15m or up to 2.5% of annual global turnover, whichever is higher. Member States will set out their own rules on fines which must be effective proportionate and dissuasive.

Next steps

The CRA now needs to be formally adopted by the Council before it becomes law, which will likely be in April 2024. The majority of the provisions will apply in full three years after the CRA comes into force, but vulnerability reporting obligations will apply within 21 months.

Expanded liabilities for cyber security of (B2C) IoT devices under the new Product Liability Directive

The CRA does not contain any specific rules on liability for (the lack of sufficient) cyber security of IoT devices. Instead, the CRA refers to the Product Liability Directive (PLD) as being complementary to the CRA. As the PLD is now 40 years old, it is in need of updating and in December 2023, an agreement was reached by the European Parliament and the Council to amend it. The key changes are as follows:

• Extended scope - “product” will now include software and digital production files. This means that operating systems, firmware, computer programmes and AI systems, whether marketed as a stand-alone product or integrated as a component in other material products, fall within the scope of the Directive and that claimants can be compensated for material and non-material damage as well as the destruction or corruption of data that is not used for professional purposes.
• More potential defendants - in addition to the (quasi-) manufacturer and the EEA importer of a product, the revised PLD imposes strict 'no-fault' liability on the manufacturer’s EU authorised representatives, fulfilment service providers (i.e. storage, packaging and shipping service providers) and, in certain cases, even retailers and online marketplace operators. Companies that "substantially modify" a product outside the control of the manufacturer will be considered effectively to be the manufacturer of the modified product.
• Burden of proof - the revised PLD aims to simplify the burden of proof for claimants who would normally have to prove that the product was defective and that this caused the damage suffered. In addition to several other presumptions, the draft provides that both the defectiveness and the causal link between the product defect and the damage can be presumed if the claimant faces excessive difficulties in particular due to technical or scientific complexity.

This means that all parties involved throughout the supply chain may be liable for damage resulting from non-compliance with certain obligations under the CRA. However, the revised PLD will have limited effect with regard to liability for non-compliance with cyber security obligations in B2B situations, as it only applies to B2C products.

Cyber security of Artificial Intelligence of Things (AIoT) and the relationship to the AI Act

The combination of AI and IoT is also known as Artificial Intelligence of Things (AIoT). AI adds value to IoT through machine learning and decision-making, while IoT devices add value to AI through data exchange, signalling, and connectivity. AIoT may be subject to both the CRA and the AI Act. The AI Act affects a wide range of stakeholders involved in the development, deployment, and use of AI systems in the EU and takes a risk-based approach, meaning that the Regulation distinguishes between different types of AI system, depending on the level of risk they pose. High-risk AI systems, such as autonomous vehicles, biometric identification systems or credit scoring systems, are subject to stricter requirements and controls than lower-risk AI systems, such as chatbots.

With regard to high-risk AI systems, the AI Act contains obligations specifically related to cyber security. In short, the cyber security obligations entail that high-risk AI systems must be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cyber security, and perform consistently throughout their lifecycle. The CRA contains a specific arrangement for situations where a PDE also qualifies as a high-risk AI system under the AI Act: if an AI system and the processes put in place by the manufacturer fulfil the “essential requirements” and the required level of cyber security protection is demonstrated in the applicable declaration of conformity, under certain circumstances the AI system may be considered to comply with the cyber security obligations under the AI Act.

The AI Act was approved by the European Parliament in March 2024, and needs to be formally endorsed by the Council. It will enter into force twenty days after its publication in the Official Journal, and be (mostly) applicable 24 months after its entry into force. Obligations for high-risk systems will be applicable 36 months after its entry into force.

What next?

Now that the legislative initiatives discussed above are in the final stages of the legislative process, providers of PDEs can prepare themselves by starting to assess whether their products and services fall within the scope of the incoming legislation and, if so, which category they fall into. Next they will need to assess which specific obligations they need to comply with and in what manner. In practice, this will not be an easy task, as several definitions are not sufficiently specific and the essential standards and frameworks are not yet in place, especially with regard to the internal conformity assessment.