2,475
Views
0
CrossRef citations to date
0
Altmetric
BILETA Special Edition

Connected and vulnerable: cybersecurity in vehicles

ABSTRACT

Back in 2015, two hackers hacked a Jeep Cherokee, wirelessly gaining access to the controls of the vehicle through the vehicle’s entertainment system. The hackers slowed the vehicle down on a highway. Remarkably, this did not result in accidents. This did, however, illustrate the already existing cybersecurity risks of vehicles and their threat to road safety, thereby making legislators aware of these dangers. Recently, several legislative steps were made to improve the cybersecurity in vehicles. As cybersecurity enters the realm of road safety, it is necessary to identify the key principles for cybersecurity in vehicles. The current legal framework is discussed in light of these principles, identifying gaps in the current legal framework for cybersecurity in vehicles. As this contribution argues, the focus of the current legislative measures focuses predominantly on the ‘first line of defence’. These measures aim to prevent unauthorised access to the vehicle’s systems, but fail to identify the steps necessary to limit the damage that can be done if this first line of defence is breached and unauthorised access is gained. Moreover, other identified cybersecurity principles are not adequately ensured. In addition, the fragmentation of the current legal framework in itself gives rise to concerns.

1. Introduction

As vehicles become increasingly more automated and connected, cybersecurity risks also increase. When a hacker exploits a cybersecurity vulnerability of a vehicle, the consequences can range from annoying but harmless, to life threatening for those inside and outside the vehicle. It might be annoying when the hacker decides to let the entertainment system of the vehicle of a Bach-enthusiast play heavy metal, but when the hacker gains access to safety-critical controls the situation can become very dangerous very quickly. The hacker could be able to let the vehicle accelerate or decelerate in a traffic situation that calls for the opposite action. If he also gains control of the steering wheel, the danger increases even more. The hacker can turn the car into a weapon and use it in, for instance, a terrorist attack.

Cybersecurity risks of vehicles hereby pose a great threat to road safety, especially as vehicles become ever more automated (ENISA and JRC Citation2021, 31). Recently, several legislative steps were undertaken to improve the cybersecurity in both conventional and automated vehicles. A great number of legislators and organisations, from the United Nations to the European Union to standards organisations, is committed to improving the cybersecurity in vehicles. Nevertheless, the current legal framework on cybersecurity in vehicles contains lacunas, as this contribution will argue. In order to identify these lacunas, this contribution maps out the current state of cybersecurity regulation within the European Union (EU). This contribution adds to the current discussion by going beyond the traditional vehicle regulation to address cybersecurity as it shows how consumer protection regulation adds to the vehicle cybersecurity ecosystem. It is argued that the current legal framework is focused on the ‘first line of defence’, not limiting damage that can be done once a hacker has made his way into the vehicle’s system. Moreover, new steps towards more ‘cybersecure’ vehicles are proposed.

2. Cybersecurity and core principles

In order to do identify lacunas in the legal framework on vehicle cybersecurity, it is important to first come to grips with the definition of ‘cybersecurity’ in the automotive context and establish what principles should be adhered to in order to reach a state of cybersecurity in vehicles. As one can imagine, it is not straight-forward to define cybersecurity (Craigen, Diakun-Thibault, and Purse Citation2014; Fuster and Jasmontaite Citation2020). It is therefore not the purpose of this contribution to offer a watertight definition. The aim is solely to establish in broad terms what it is that needs regulating/is regulated in relation to automated vehicles within the European Union legal framework.

The UNECE World Forum for Harmonization of Vehicle Regulations (hereinafter: WP.29), the United Nations’ body responsible for keeping technical vehicle requirements up-to-date, has formulated a definition on cybersecurity specifically for vehicles:

“Cyber security” means the condition in which road vehicles and their functions are protected from cyber threats to electrical or electronic components. (UN Regulation No. 155)

Of course, there are many more definitions of cybersecurity, but it goes beyond the scope and purpose of this contribution to discuss all available definitions. Some of those definitions are more focussed on cybersecurity as an activity, not a condition (i.e. Auto-Isac 2021; art. 2 of the EU Cybersecurity Act (Regulation (EU) 2019/881)). Oxford English Dictionary (Citationonline), however, sees security as a condition:

Security: (…) The state or condition of being protected from or not exposed to danger; safety. (…).

It is clear from this definition of security that security is a state or condition, not so much an activity. Here, the element of protection is paramount. The definition given by WP.29 will therefore be adhered to in this contribution: cybersecurity is seen as a condition that can be reached through certain activities and processes, protecting the vehicle’s system from threats.

The cybersecurity of vehicles is increasingly more threatened as vehicles become more connected. Phones can be connected to the vehicle’s entertainment system, the entertainment system itself could be connected to the Internet to download the latest hits or new updates, the vehicle’s navigation requires GPS input, and so on. New technologies, enabling vehicles to take over the driving task partially or entirely (e.g. automated vehicles), require the vehicle to communicate with the infrastructure around it (V2I communication), with vehicles around it (V2V communication) and/or with other elements outside the vehicle (V2X communication) (Möller and Haas Citation2019, para 6.1.8). All these lines of communication can potentially be intercepted and exploited for malicious purposes. Input can be altered, leading the vehicle astray, and communication can get cut-off (Taeihagh and Si Min Lim Citation2019, 115–117). In addition, it will become more common for vehicles to receive software updates over the air, providing an opening to install malware too. These scenarios and threats are complex. There is no ‘quick fix’ to secure the system of a vehicle.

As the Jeep Cherokee hack of 2015 has shown, a hacker could have seemingly endless possibilities to influence the vehicle’s driving behaviour once he has gained access (Möller and Haas Citation2019, 367–368). If the hacker has the ability to control the vehicle’s steering and speed, not only road safety is at risk. The vehicle could be used as a murder weapon or in a terrorist attack. Multiple hacked vehicles can be used to disrupt society by blocking important roads leading into a city, for example. This could not only lead to traffic coming to a halt, but it could disrupt supply chains too, leaving supermarkets deprived from new stock and hospitals from medication. It goes without saying that this can have very grave consequences. Therefore, it is of the upmost importance to limit the cybersecurity risks as much as possible.

How can that be done? Apart from the technological security measures, law can play an imported role in ensuring a vehicle is ‘cybersecure’ by regulating activities and processes necessary to reach this state. To get the most out of cybersecurity regulation, the most important cybersecurity conditions, principles if you will, need to be identified. This contribution aims to ignite the discussion on these principles, from a legal perspective. The list of principles might change over time, as the discussion develops further. This contribution thus marks a start, not an ending. Six principles can be identified:

  1. Unauthorised access to the vehicle’s systems should be prevented.

  2. In case of unauthorised access, damage should be limited as much as possible.

  3. In case of unauthorised access, the state of cybersecurity should be restored.

  4. Injured parties should be indemnified.

  5. Those exploiting a cybersecurity vulnerability should be held responsible for their actions under criminal law and administrative law.

  6. The state of cybersecurity should be preserved throughout a vehicle’s lifetime.

Principle 1 forms the base of cybersecurity regulation, whereas principle 2 adds an important next step for if principle 1 cannot be upheld: it prevents the hacker from hacking its way into the vehicle’s controls via the entertainment system. How a hacker gains access (for instance via malware) is not relevant. Principle 2 highlights the necessity of regulatory tools and measures to limit any damage the hacker can do and to help restore the state of cybersecurity. In order to ensure this sort of damage control, technical regulations should require specific security measures on the isolation of the non-safety-critical systems and safety-critical controls of the vehicle. This way, layers of barriers, safeguards and redundancies are created, a type of cybersecurity ‘onion’ (Mills Citation2021; Reichenbach Citation2015) or so-called Protection in Depth (Coole, Corkill, and Woodward Citation2012, 30). In addition, the introduction of a failsafe, making the vehicle return to a minimal risk condition as soon as it has been compromised by the actions of hackers, can contribute to limiting the damage from the exploitation of a vulnerability. Moreover, the sooner the cybersecure state is recovered (principle 3), the less harm can be done. This could require actions from the manufacturer: he might need to recall not only the hacked vehicle, but also other vehicles using the same software. Moreover, a software programmer might have to develop a software update to patch the cybersecurity vulnerability in its software. This requires rules on the monitoring of the cybersecurity state of the vehicle, recalls and obligations concerning software patches.

If all these steps do not have the desired effect and damage is caused, principle 4 identifies the need for the compensation of those injured by a hacked vehicle. To obtain compensation, it might be necessary for the injured party to establish the identity of the hacker. This can be very challenging and possibly even unfeasible. That, nevertheless, does not have to pose an impossible obstacle; other parties might also be liable for the damage caused. In addition, a compensation fund could be in place, compensating the damage of those who cannot trace their tortfeasor. Moreover, this can also provide for an incentive: the prospect of having to pay damages might hold back some hackers from hacking a vehicle (Förster Citation2021, Rn. 9).

Not just liability and tort law can serve as a tool providing certain incentives that make people refrain from certain behaviour. Criminal liability can also provide such an incentive, which underscores the importance of the fifth principle.

Administrative law can also play a part in providing an incentive to those who through their own behaviour have enabled hackers to exploit a vulnerability; a permit to bring vehicles onto the market could be withdrawn. Good enforcement is paramount to this. After all, if a hacker cannot be traced, he cannot be punished or be obliged to compensate the injured parties.

The field of cybersecurity is continuously evolving; hidden vulnerabilities can turn into great threats overnight. They can have a snowballing effect, where not just one system is affected by a hack, but entire fleets of vehicles can be brought to a halt (Malik and Sun Citation2020, 66). To keep on top of these developments, it is crucial to be monitoring vehicles throughout their lifetime and to update software to stay one step ahead of hackers, as described in the sixth principle. This requires a continuous process of monitoring and updating software. Different parties from the automotive sector can be involved in this process of monitoring and updating: vehicle approval authorities, producers, but also owners and users of vehicles.

The six principles for cybersecurity in vehicles identified here can be given a legal basis by the legislature, providing opportunities to enforce these principles. This does not necessarily require new legislative initiatives; some of the current laws already provide for certain elements of the principles. Furthermore, legislation not specifically aimed at the automotive field is relevant as well. The legislation currently in place in the automotive field and beyond and their compatibility with the six cybersecurity principles is addressed below, so as to identify any legislative gaps.

3. Legal developments

Gradually, legislators are becoming more and more aware of the risks cybersecurity vulnerabilities pose to road traffic safety. Testimony to this is the legislative steps of the recent years, ranging from new vehicle standards to the development of cybersecurity certification frameworks. As this contribution argues, existing legislation such as the EU Product Liability Directive also contributes to fulfilling the principles as listed above. By studying the EU legal framework in light of the principles, shortcomings in this legal framework are identified. For the sake of clarity, a distinction is made between the legal instruments that specifically focus on vehicles’ security and safety, and legal instruments that have a broader scope (i.e. consumer protection). provides an overview.

Table 1. Overview of relevant instruments.

4. Legal developments – vehicle safety regulations

The legal framework for vehicles is, in general, a well-developed field that is regularly updated. New technological developments, such as automated driving, urge legislators to draft new technical requirements for vehicles, identifying how safe is safe enough. The rise of cybersecurity risks in vehicles has also led to new legal developments, starting with new technical requirements for new vehicles.

4.1. UN Regulations No. 155 and 156

From mid-2022 onwards, two recent UN Regulations will be applicable to all new vehicles within the EU: UN Regulation No. 155 on Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system and UN Regulation No. 156 concerning Uniform provisions concerning the approval of vehicles with regards to software update and software update management. They set minimum requirements that need to be met in order to have a vehicle approved for use on public roads. Both of these new Regulations are of importance to the cybersecurity of new vehicles.

UN Regulation No. 155 requires a Certificate of Compliance for Cyber Security Management System from a vehicle manufacturer in order to have its vehicle approved for use on public roads (art. 7.2.1). This Cyber Security Management System or CSMS is defined by UN Reg. No. 155 as ‘a systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them from cyberattacks’ (art. 2.3). These organisational processes include processes used for the identification of risks to vehicle types (7.2.2.2.(b)) and processes used for testing the cyber security of a vehicle type (7.2.2.2.(e)). Such processes should contribute to ensuring the cybersecurity of the vehicle. This is also reflected in Annex 5, which sets out mitigation methods of different cybersecurity risks (including ‘Measures to prevent and detect unauthorized access shall be employed’ (9.1)). Thereby, UN Regulation No. 155 seeks to ensure no one can gain unauthorised access to the vehicle’s system and thus contributes to the first principle formulated on cybersecurity in vehicles.

In addition, UN Regulation No. 156 sets requirements on how to update the software of the vehicle. The vehicle manufacturer will have to have a Certificate of compliance for Software Update Management System. The Software Update Management System or SUMS is defined as a systematic approach defining organisational processes and procedures to comply with the requirements for delivery of software updates according to this Regulation (art. 2.5). Similar to the certificate for the CSMS, the vehicle manufacturer has to have a number of organisational processes in place to obtain a Certificate of compliance for the SUMS. These are processes such as the process whereby any interdependencies of the updated system with other systems can be identified (7.1.1.5) and a process to establish the compatibility of the update with the target vehicle configuration (7.1.1.7). That way, the installation of malware should be avoided. This UN Regulation thus also tries ‘to keep the bad guys out’.

By requiring a Cyber Security Management System and a Software Update Management System, the goal of reaching a state of cybersecurity is becoming engrained in the organisation of the manufacturer. As a result, both UN Regulation No. 155 as well as UN Regulation No. 156 contribute to the first principle discussed here, by aiming to prevent anyone from getting unauthorised access to a vehicle’s system.

It is on the second and third principle – once unauthorised access is gained, damage should be limited as much as possible (second principle) and the state of cybersecurity should be restored – where the UN regulations seem to fall short. UN Regulation No. 155 and UN Regulation No. 156 provide the option of withdrawal of the approval or certificate if requirements from these regulations are no longer met. Thereby, the damage occurred by the exploitation of a cybersecurity vulnerability can be limited. However, there are no requirements on the limitation of damage that can be done once a vehicle’s system is hacked. UN Regulation No. 155 states that a vehicle should be able to detect and respond to possible cybersecurity attacks (art. 5.1.1.(d)), but fails to identify what this response should be. Moreover, measures to safeguard the safety-critical controls of the vehicle are lacking. The UN regulation does not, for instance, require the isolation of safety-critical controls from the entertainment system of the vehicle. So, although UN Regulations No. 155 and No. 156 provide a ‘first line of defence’ by trying to make gaining unauthorised access very challenging, a ‘second line of defence’, focussed on damage control, is missing. In addition, other than the requirement to respond to a cybersecurity attack and the mitigating action of recovering from a denial of service attack (Annex 5), the third principle (restoration of cybersecurity) listed above does not get the attention it needs. UN Regulation No. 156, for instance, does not set out when a software update should be provided. One could argue, though, that both UN Regulations do contribute to the sixth principle of maintaining the cybersecurity of vehicles throughout their lifetime as there is a possibility to withdraw any approval of a vehicle (see below on the EU type-approval) if the vehicle is no longer in conformity with the UN Regulations No. 155 and No. 156. Overall, however, the legislative steps taken on a UN level seem to be focussed mainly on avoiding the unauthorised access to the vehicle’s system.

4.2. EU General Safety Regulation

The EU General Safety Regulation (Regulation 2019/2144, hereinafter: GSR) is the link between the UN Regulations No. 155 and No. 156 and the EU type-approval process for vehicles. From 6 July 2022, all new types of vehicles will therefore need to fulfil the requirements of these two UN regulations (art. 19, Annex II (D4) GSR). The EU has clearly seen the risks of cybersecurity vulnerabilities in vehicles, as the GSR states:

The connectivity and automation of vehicles increase the possibility for unauthorised remote access to in-vehicle data and the illegal modification of software over the air. In order to take into account such risks, UN Regulations or other regulatory acts on cyber security should be applied on a mandatory basis as soon as possible after their entry into force. (Recital 26)

The risks of software modifications leading to a change in vehicle functionalities are also acknowledged in Recital 27. Hence, the adoption of both UN regulations.

Another requirement introduced by the GSR is the use of the event data recorder or EDR (art. 6(1)(g) GSR). This EDR records and stores ‘critical crash-related parameters and information’ (art. 3(13) GSR). This includes the vehicle’s speed, braking, position and tilt of the vehicle on the road, and more (art. 6(4)(a) GSR). Those involved in an accident might want to alter the information stored on the EDR so as to avoid an obligation to pay compensation or to avoid prosecution. The EDR could, for that reason, become a potential target for hackers, in addition to the vehicle’s system and safety-critical controls. This, again, illustrates the importance of cybersecurity measures for vehicles, such as the UN Regulations No. 155 and No. 156.

The EDR and the conformity with UN Regulations No. 155 and No. 156 will become obligatory requirements for the EU type-approval of vehicles, which should lead to more ‘cybersecure’ vehicles on the public roads of the European Union. That way, the GSR contributes to the realisation of the first principle identified: the prevention of gaining unauthorised access. The GSR, however, only has this effect through its link with the EU Regulation on the type-approval for vehicles (Regulation (EU) 2018/858).

4.3. Regulation (EU) 2018/858 on the type-approval of vehicles

It was briefly mentioned above: via the GSR, UN Regulation No. 155 and UN Regulation No. 156 make their way into the EU vehicle type-approval of Regulation 2018/858. A EU type-approval certificate (art. 28 Regulation 2018/858) can be granted by a type-approval authority to a specific type of vehicles that meet all relevant technical requirements. All cars of this specific approved vehicle type are allowed to drive on public roads in the EU.

From mid-2022 onwards, conformity with UN Regulation No. 155 and UN Regulation No. 156 is required for the EU type-approval, whereby cybersecurity enters the realm of the previously very technical, not so much digital, type-approval. At the moment, however, it is already possible for approval authorities to take cybersecurity into account as they have the option to refuse the type-approval of a type of vehicle when they deem the type is unsafe despite meeting all requirements:

the approval authority shall refuse to grant an EU type-approval where it finds that a type of vehicle, system, component or separate technical unit that complies with the applicable requirements nonetheless presents a serious risk to safety or may seriously harm the environment or public health (…). (art. 26 (5) Regulation 2018/858)

This way, approval authorities can already get a head start on ensuring the cybersecurity of vehicles.

During the lifetime of an approved (type of) vehicle, there is still work to be done by the approval authority. The approval authority has to respond if a vehicle becomes unsafe during its lifetime by withdrawing the approval granted before the vehicle was put into circulation. Article 7(4) of Regulation 2018/858 reads:

Where an approval authority has been informed […] that a vehicle, system, […] is suspected of presenting a serious risk or of being in non-compliance, it shall take all necessary measures to review the type-approval granted and, where appropriate, correct or withdraw the type-approval depending on the reasons and the seriousness of the deviations demonstrated.

The Regulation does not provide a definition or description of ‘serious risk’, but Annex VI of the Regulation does provide a list of equipment whose malfunctioning could pose a serious risk to the correct functioning of a vehicle’s system. The European Commission can amend this list through delegated acts (art. 55(4) Regulations 2018/858), thereby keeping it up-to-date. That way, cybersecurity threats can move within the scope of ‘serious risk’.

Because of its power to withdraw approval, the approval authority performs an integral part of both principle 2 (limitation of damage) and principle 5 (maintain a state of cybersecurity throughout a vehicle’s lifetime): this mechanism provides a continuous incentive to make sure that a cybersecurity vulnerability will not pose a serious threat, and by withdrawing a type-approval, the damage that can result from a hack is being limited.

4.4. Standards

There are many technical standards in the automotive field. These standards are issued by organisations such as ISO (International Organization for Standardization), IEEE (Institute of Electrical and Electronics Engineers), the ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute) and the SAE (Society of Automotive Engineers). At the moment of writing, an important standard on cybersecurity in vehicles, ISO/SAE standard 21434, is close to being published (SAE Citation2021) and more efforts are being undertaken (Schmittner and Macher Citation2019). Although standards issued by these organisations can have a global impact, the standards are often not legally binding. Nevertheless, not adhering to a widely used standard can lead to negligence (and subsequent liability) depending on national law. This provides an incentive to adhere to such a standard, contributing to the fulfilment of the cybersecurity principles identified above. Standards, depending on their exact content, have thus the ability to contribute to each of the principles apart from principle 5 (legal consequences for the hackers under criminal and administrative law). They thereby form a cornerstone in advancing vehicle security.

4.5. EU Motor Insurance Directive

Under the Motor Insurance Directive (Directive 2009/103/EC), every EU Member State has to ‘take all appropriate measures to ensure that civil liability in respect of the use of vehicles normally based in its territory is covered by insurance’ (art. 3). Consequently, victims of motor vehicle accidents across the EU have an insurer to turn to and claim damages form. This holds true even if the identity of the vehicle that caused the damage cannot be established (e.g. hit-and-run) or if the vehicle was uninsured (e.g. in case of a car theft), as the Motor Insurance Directive requires Member States to set up a compensation fund to cover the damage caused by an unidentified or uninsured vehicle. Article 10 of the Motor Insurance Directive states:

Each Member State shall set up or authorise a body with the task of providing compensation, at least up to the limits of the insurance obligation for damage to property or personal injuries caused by an unidentified vehicle or a vehicle for which the insurance obligation provided for in Article 3 has not been satisfied.

Although this provides an extensive ‘safety net’ for those seeking compensation for damage suffered, the exact terms of the vehicle insurance can differ from one Member States to another. Take for instance the Netherlands: if the damage has been caused by a defect for which the manufacturer of the vehicle is liable, the vehicle insurance is not necessarily obliged to compensate that damage (art. 3 Wet Aansprakelijkheidsverzekering Motorrijtuigen).

Nevertheless, a mandatory motor vehicle insurance in combination with the compensation fund for damage caused by unidentified or uninsured vehicles is essential in ensuring parties suffering damage from a road accident, including an accident caused by a hacked vehicle, receive compensation. Thereby the Motor Insurance Directive contributes to principle 4 on compensation for those suffering damage caused by a hacked vehicle.

5. Legal developments – beyond vehicle regulations

5.1. Vehicle cybersecurity outside of vehicle regulations

Although vehicle requirements are the ‘place to be’ when it comes to technical demands for vehicles, cybersecurity can also be encouraged through other legal instruments. In this section, such instruments and their effect on the development of cybersecurity vehicles are discussed. This will illustrate that the (domestic) legislator does not have to wait for any technical vehicle regulations, such as the UN Regulations No. 155 and No. 156, to come into effect. The legislator has other means to his disposal to encourage the uptake of cybersecurity measures in vehicles, for instance through consumer protection regulation.

5.2. EU Cybersecurity Act

A different certification framework than the EU vehicle type-approval is the EU Cybersecurity Act (Regulation 2019/881), which might also contribute to fulfilling the first principle on cybersecurity in the vehicle. With its Cybersecurity Act, the European Union tries to safeguard the cybersecurity of ICT products, ICT services and ICT processes through the development of a voluntary cybersecurity certification framework (European Commission Citation2020a, 6; Kohler Citation2020, 8). Whether these ICT products include (automated) vehicles or parts of (automated) vehicles is at the moment of writing not clear yet. The type-approval process (Regulation (EU) 2018/858), which would include the new UN Regulations No. 155 and No. 156, could deem a separate cybersecurity certification framework for vehicles unnecessary and perhaps even undesirable (Andraško, Mesarčík, and Hamuľák Citation2021, 628). This requires further clarification. Nevertheless, the EU Cybersecurity Act could still contribute to the value or goal of preventing anyone from gaining unauthorised access to the vehicle’s systems without demanding another certification process alongside that of the type-approval of vehicles, as the EU Cybersecurity Act grows cybersecurity awareness.

5.3. NIS Directive

The Directive on security of network and information systems or NIS Directive (Directive (EU) 2016/1148) has been the first piece of EU legislation (Markopoulou, Papakonstantinou, and de Hert Citation2019) on cybersecurity matters. It fosters a cybersecurity-minded culture across different sectors, including the road transport sector. Road transport is identified as one of the sectors providing essential services (art. 5 and Annex II NIS Directive), meaning that, among others, the operators of Intelligent Transport Systems (ITS) (art. 4(1) ITS Directive (EU) 2010/40/EU) need to comply with the security and notification requirements of the NIS Directive. Article 14(1) of the NIS Directive reads: ‘Member States shall ensure that operators of essential services take appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems which they use in their operations […]’. In addition, art. 14(2) requires Member States to ensure that operators of essential services, like ITS operators, ‘take appropriate measures to prevent and minimise the impact of incidents affecting the security of the network and information systems used for the provision of such essential services (…)'. Moreover, Member States have to ensure that these operators notify the appropriate authorities of significant (art. 14(4) NIS Directive) incidents (art. 14(3) NIS Directive). Combined with other measures, these requirements should lead to a high common level of security of network and information systems within the EU (art. 1(1) NIS Directive). Because the focus of this NIS directive lies on the security of network and information systems and links to ITS operators, the Directive is mainly of in importance in relation to V2V, V2I and V2X communication. By increasing the security of these communication means, the NIS Directive contributes to prevent unauthorised access to the vehicle’s systems. In addition, the NIS Directive contributes to limiting the damage that can be done, as operators of essential services are obliged to take measures to minimise the impact of incidents. Therefore, the NIS Directive is of importance to both the first and second principles identified above (preventing unauthorised access and limiting damage, respectively). Its likely successor, the proposed EU Directive on measures for a high common level of cybersecurity across the Union or NIS 2 Directive (European Commission Citation2020b) could serve those principles as well. The proposed NIS 2 Directive is part of the new EU Cybersecurity Strategy, which also includes the proposed EU Directive on the resilience of critical entities (European Commission Citation2020c). The Annex to this proposed Directive lists, among other entities, ITS operators as a critical entity, meaning that EU Member States will have to ‘adopt […] a strategy for reinforcing the resilience’ of this entity (art. 3(1) proposed Directive on the resilience of critical entities), thereby contributing to increasing cybersecurity on public roads.

5.4. EU General Product Safety Directive

The scope of the General Product Safety Directive (Directive 2001/95/EC) or GPSD goes, like the EU Cybersecurity Act, beyond vehicles. It applies to a wide range of consumer products, including consumer vehicles (art. 2 GPSD). A dangerous product can justify the withdrawal or, as a last resort, the recall of the product from the market (art. 3(4), 5(1)(b), 8 GPSD). The Directive defines withdrawal as ‘any measure aimed at preventing the distribution, display and offer of a product dangerous to the consumer’ (art. 2(h) GPSD), and therefore aims to prevent a dangerous product from reaching the consumer. Recall sees to the situation in which a dangerous product has already made its way to the consumer; recall is defined as ‘any measure aimed at achieving the return of a dangerous product that has already been supplied or made available to consumers by the producer or distributor’ (art. 2(g) GPSD). A product is considered dangerous when it is no longer deemed safe (art. 2(c) GPSD). The GPSD states in art. 2(b) that a safe product is

any product which, under normal or reasonably foreseeable conditions of use including duration and, where applicable, putting into service, installation and maintenance requirements, does not present any risk or only the minimum risks compatible with the product's use, considered to be acceptable and consistent with a high level of protection for the safety and health of persons […].

Cybersecurity risks are not mentioned in this definition or, in fact, anywhere in the GPSD. This, perhaps, comes as no surprise; the GPSD dates back to 2001, when the cybersecurity risks of products were very limited. Whether cybersecurity is a factor playing a role in establishing whether a product is safe is therefore unclear at the moment (Fosch-Villaronga and Mahler Citation2021, 6).

The European Commission acknowledges that ‘Union product safety legislation does not generally provide for specific mandatory essential requirements against cyber-threats affecting the safety of users’ (European Commission Citation2020a, 6). In the new 2021 proposal for a new General Product Safety Regulation, however, cybersecurity is taken into account. Cybersecurity features are listed as an aspect taken into account when establishing whether a product is safe (art. 7(1)(h) proposed General Product Safety Regulation 2021; see European Commission Citation2021), whereby cybersecurity explicitly enters the realm of product safety regulation. When it comes to cybersecurity in consumer vehicles, this proposed Regulation would offer an additional opportunity to get vehicles with a cybersecurity vulnerability off the road and to prevent those vehicles from hitting the road in the first place.

The EU type-approval framework also offers the option of withdrawal of the approval, effectively bringing all vehicles of that specific type to a halt. This is the same effect as a recall under the proposed General Product Safety Regulation would have (art. 3(23)). Moreover, the refusal of type-approval has the same effect as withdrawal under the proposed Regulation (art. 3(24)): unsafe (consumer) vehicles would not hit the road. Nevertheless, the proposed General Product Safety Regulation has added value as it opens the possibility of using a consumer-minded interpretation of ‘safe’, which could prove to be a higher level of safety as that covered by the EU type-approval Regulation. This will contribute to the second identified principle of damage control by preventing, from a cybersecurity perspective, unsafe vehicles to hit the road and by taking unsafe vehicles off the road.

5.5. EU Directive on contracts for the sale of goods

Another consumer protection instrument relevant to this contribution is the EU Directive on contracts for the sale of goods (Directive (EU) 2019/771). ‘Goods’ are defined by the Directive as

(a) any tangible movable items; […]; (b) any tangible movable items that incorporate or are inter-connected with digital content or a digital service in such a way that the absence of that digital content or digital service would prevent the goods from performing their functions (“goods with digital elements”). (art. 2(5) Directive (EU) 2019/771)

The Directive applies to contracts between a consumer and a seller (art. 3(1)) and requires the seller to deliver the goods in conformity with the contract (art. 5). The Directive sets out conformity criteria in more detail. This includes the following objective requirement for conformity:

‘In the case of goods with digital elements, the seller shall ensure that the consumer is informed of and supplied with updates, including security updates, that are necessary to keep those goods in conformity, for the period of time: (a) that the consumer may reasonably expect given the type and purpose of the goods and the digital elements, and taking into account the circumstances and nature of the contract, […]. (art. 7(3)(a) Directive (EU) 2019/771)

Therefore, updates concerning cybersecurity vulnerabilities will have to be provided for a certain period of time. If the consumer does not install such an update despite clear instructions from the seller, the seller is not liable for non-conformity of the good in this respect (art. 7(4) Directive (EU) 2019/771). However, if the seller did not provide an update when he should, the seller is liable for non-conformity. Article 13 of the Directive provides remedies for non-conformity. One of those remedies is repair (art. 13(1) Directive (EU) 2019/771), which could require providing a security update. This Directive, therefore, does not provide technical requirements, but only provides clarity on the seller’s liability in relation to security updates of goods (Banasinski and Rojszczak Citation2021).

Given the definition of ‘good’, the purchase of a car by a consumer will fall within the scope of Directive (EU) 2019/771 (Morais Carvalho Citation2019, 197). Consequently, the seller has to supply security updates to the vehicle for as necessary to keep the vehicle in conformity with the contract. This includes updates relating to cybersecurity vulnerabilities. Thereby, the cybersecurity of a vehicle is being kept to a specific standard – that of conformity with the contract – during a prolonged period of time. This might not be the vehicle’s entire lifespan, but it contributes nevertheless to maintaining a ‘cybersecure’ vehicle (sixth principle). Consequently, it will be more difficult for hackers to exploit a vulnerability as the necessary security updates could improve the ‘first line of defence’, keeping the hackers out. Moreover, it can be argued that the Directive on contracts for the sale of goods can contribute to the third identified principle – restoring the state of cybersecurity – as (the exploitation of) a cybersecurity vulnerability could mean that the vehicle has become non-conform, leading to a remedy, for instance, a new security update to patch the vulnerability. Thereby, the Directive becomes a (perhaps unexpected) tool in achieving the cybersecurity principles for vehicles as identified in this contribution.

5.6. EU Product Liability Directive

Probably the best-known function of liability law is that of compensation. In addition, liability law has the function to prevent damage from occurring or deter parties from possibly harmful conduct (Förster Citation2021, Rn. 9). So, the possibility of being held liable for damage can encourage safer behaviour. This also goes in relation to liability law and cybersecurity. That way, the EU Product Liability Directive (Directive 85/374/EEC) has a role in encouraging cybersecurity in vehicles.

As the EU Product Liability Directive dates back to 1985, cybersecurity has not been taken into account. Nevertheless, the Directive could provide an incentive to keep the cybersecurity of vehicles up-to-date as the producer might be liable for damage caused by the exploitation of a cybersecurity vulnerability.

Under the EU Product Liability Directive, a producer can be held liable for damage caused by a defect in his product (art. 1). The producer has six defences at his disposal to turn the tide and avoid liability. A cybersecurity vulnerability could, depending on specific circumstances, amount to a defect within the meaning of the Directive. For example, a producer has put a vehicle on the market without a separation between the entertainment system and the safety-critical controls of the vehicle. This lack of a ‘second line of defence’ (see above) could qualify as a defect, as the vehicle does not offer the safety which a person is entitled to expect (art. 6). If this vulnerability is exploited, and a hacker causes damage making his way through the entertainment system to the safety-critical controls, the producer can be held liable for this damage caused by the hacker. That the vehicle has been granted EU type-approval (and thus meets the requirements from UN Regulations No. 155 and No. 156), and it meets other mandatory requirements is not sufficient to avoid liability: the producer is free to take more safety and security measures as he sees fit. In other words, when it comes to EU product liability, the legislator sets minimum requirements, which do not release a manufacturer from liability. The manufacturer could, therefore, under specific circumstances, be held liable for damage caused by the exploitation of a cybersecurity vulnerability of his vehicle.

If the defect is somehow due to compliance of the vehicle with mandatory regulations issued by the public authorities, the producer is not liable for the damage caused (art. 7(d) Product Liability Directive). This is one of the six defences that are at the producer’s disposal.

Another defence relevant in the cybersecurity context is that of article 7(b) of the Product Liability Directive, which reads:

The producer shall not be liable as a result of this Directive if he proves […] that, having regard to the circumstances, it is probable that the defect which caused the damage did not exist at the time when the product was put into circulation by him or that this defect came into being afterwards […].

So let’s say that a vehicle has a bug (i.e. all lights and indicators of the vehicle are turned on when the vehicle comes to a stop), which is patched by a software update issued by the producer of the vehicle. This software update neutralises the software bug, but introduces a cybersecurity vulnerability to the vehicle. If that is subsequently exploited and damage is caused, the producer could face liability claims. In such a scenario, the producer can successfully invoke the defence of art. 7(b) of the Product Liability Directive, as the exploited cybersecurity vulnerability – the defect – did not exist when the vehicle – the product – was put into circulation. Lately, this defence has been the subject of critique in literature (e.g. Vellinga Citation2020, 166–169) as this outcome has been deemed undesirable from a consumer protection perspective.

In addition, the so-called development risk defence of art. 7(e) of the Product Liability Directive could be of relevance to a producer of a hacked vehicle. To successfully invoke the development risk defence, the producer will have to prove that ‘the state of scientific and technical knowledge at the time when he put the product into circulation was not such as to enable the existence of the defect to be discovered’ (art. 7(e)). This could hold true with a zero day-attack on the producer’s vehicle. In the case of a zero day-attack, a previously unknown vulnerability is exploited for the very first time after it became known and before there was time to patch the vulnerability. As it was not known before the attack took place, it will not have been known and perhaps even impossible to discover the vulnerability when the vehicle was put into circulation. This would then lead to a successful invocation of this defence.

Overall, the producer would only in very specific circumstances be able to avoid liability under the Product Liability Directive for damage caused by the exploitation of a cybersecurity vulnerability present in the vehicle when it was put into circulation. Therefore, there is a genuine liability risk for the producer of a vehicle and thus an incentive to keep the cybersecurity ecosystem of his vehicle up-to-date. This, however, does not necessarily mean that those who exploited the vulnerability are avoiding liability.

5.7. National legal frameworks

Whether the person causing damage by exploiting a cybersecurity vulnerability faces a claim for compensation depends on the domestic liability framework and on whether this hacker can actually be identified. In addition to the hacker, other parties could also face a claim for damages. This will depend on domestic liability law as well as the specific circumstances at hand. For instance, the owner or user of a vehicle might have ignored the notification that an important software update should immediately be installed. If this update could have prevented the hack, the ignoring of the notification could amount to negligence. Consequently, the owner or the user will need to compensate the damage. How this would exactly pan out depends, again, on national legislation. It is this national legislation that can ensure the compensation of those suffering damage from a hacked vehicle. That way, the national legal framework forms an indispensable link, in combination with the Motor Insurance Directive and its domestic implementations, in the indemnification of the injured party (fourth principle). Moreover, the incentive provided by domestic liability law can have the same prevention incentive as mentioned in relation to the Product Liability Directive, thereby providing an incentive for, for instance, the owner or user of a vehicle to install that important update (first principle) (Förster Citation2021, Rn. 9). The national legal framework can thus contribute to realising principles one and four as identified above.

Another principle that the national legal framework can contribute to, is the fifth principle: an important condition for a comprehensive legal framework on cybersecurity in vehicles is that those exploiting a cybersecurity vulnerability should face the legal consequences of their actions. Whether such hackers face legal consequences and what these legal consequences are, depends overwhelmingly on domestic criminal law relating to cybercrime.

There is a strong international awareness for cybercrime, illustrated by the Council of Europe’s Convention on Cybercrime from 2001 (CETS No.185). The Convention is an essential instrument in ‘a common criminal policy aimed at the protection of society against cybercrime’ (preamble Convention on Cybercrime). Those signing the Convention on Cybercrime have committed themselves to, among other things, ‘adopt such legislative and other measures as may be necessary to establish as criminal offences under its domestic law, when committed intentionally, the access to the whole or any part of a computer system without right […]’ (art. 2 Convention on Cybercrime). A similar approach is applied in the EU Directive on attacks against information systems (Directive 2013/40/EU). This Directive describes ‘information systems’ as

a device or group of inter-connected or related devices, one or more of which, pursuant to a programme, automatically processes computer data, as well as computer data stored, processed, retrieved or transmitted by that device or group of devices for the purposes of its or their operation, use, protection and maintenance. (art. 2(a))

Therefore, the notion of ‘information system’ from Directive 2013/40/EU potentially includes a vehicle’s system. Similar to the Convention on Cybercrime, the Directive requires EU Member States, to

take the necessary measures to ensure that, when committed intentionally, the access without right, to the whole or to any part of an information system, is punishable as a criminal offence where committed by infringing a security measure, at least for cases which are not minor. (art. 3 Directive 2013/40/EU)

Member States should also take measures to insure that, among other things, Illegal data interference (art. 5) and Illegal interception (art. 6) are punishable. National criminal law is thus the vocal point for criminal offences concerning the hacking of vehicles. The fulfilment of the last identified principle (those exploiting a cybersecurity vulnerability should face the legal consequences of their actions) lies therefore with the domestic legislator.

6. Legal developments – a look at the future

6.1. The road ahead

As already briefly touched upon above, the (near) future will bring us some new standards, laws and regulations relevant to cybersecurity in vehicles. Among other things, there is a new draft Regulation for the General Product Safety Directive in the pipeline, as well as the ISO/SAE standard on cybersecurity in vehicles. In addition, the EU has set an important step towards harmonising the regulation of artificial intelligence (AI). As vehicles are becoming more and more automated, this proposed Regulation on AI will become relevant to the automotive field, also in relation to cybersecurity.

6.2. EU proposed regulation on AI

Spring 2021, the European Commission presented a proposal for a regulation on AI (European Commission Citation2021). This proposed AI Regulation provides, among other things, ‘harmonised rules for the placing on the market, the putting into service and the use of artificial intelligence systems (“AI systems”) in the Union’ (art. 1(a) AI Regulation). If the proposed Regulation on AI will come into effect, it will not have an immediate impact on the automotive sector. For high-risk AI systems falling within the scope of the EU Regulation on Type-approval (Regulation 2018/858) and the EU General Safety Regulation (Regulation 2019/2144), only art. 84 of the proposed AI Regulation shall apply. This article concerns the evaluation and review of the AI Regulation. Furthermore, the proposed AI Regulation introduces a new paragraph to each of these Regulations. In relation to the Type-approval Regulation (Regulation 2018/858), the Commission can adopt delegated acts ‘in order to take into account technological and regulatory developments by introducing and updating references to the regulatory acts that contain the requirements with which vehicles, systems, components and separate technical units have to comply’ (art. 5(3) Regulation 2018/858). The proposed AI Regulation adds that requirements set out in Title III, Chapter 2 of the AI Regulation should be taken into account when adopting these delegated acts (art. 80 AI Regulation, new art. 5(4) Regulation 2018/858). A similar construction can be seen with regard to the General Safety Regulation (Regulation 2019/2144). Article 11 of the GSR gives the Commission the option to, by means implementing acts, adopt provisions on uniform procedures and technical specifications for newly introduced safety systems, including the EDR, and provisions on ‘for the type-approval of automated and fully automated vehicles with regard to those systems and other items in order to ensure the safe operation of automated and fully automated vehicles on public roads’. The proposed AI Regulation would add to this, that ‘when adopting the implementing acts […], the requirements set out in Title III, Chapter 2 of that Regulation [the proposed Regulation on AI] shall be taken into account’. So, any new developments regarding the EU Type-approval Regulation and the EU General Safety Regulation require compliance with Title III, Chapter 2 on the proposed AI Regulation, whereby the regulation of AI enters the realm of the automotive field.

Title III, Chapter 2 of the proposal on Regulation of AI contains requirements for high-risk AI systems. These are requirements on, for instance, a risk management system (art. 9), data governance (art. 10) and human oversight – which could proof to be a barrier for the introduction of automated vehicles – (art. 14), but also on cybersecurity (art. 15). The AI Regulation requires high-risk AI systems to be ‘designed and developed in such a way that they achieve, in the light of their intended purpose, an appropriate level of […] cybersecurity, and perform consistently in those respects throughout their lifecycle’(art. 15(1) AI Regulation). The proposed AI Regulation thereby contributes to the sixth principle on cybersecurity in vehicles: the preservation of the state of cybersecurity throughout a vehicle’s lifetime. The AI Regulation elaborates further on cybersecurity: ‘High-risk AI systems shall be resilient as regards attempts by unauthorised third parties to alter their use or performance by exploiting the system vulnerabilities (…)’ (art. 15(4) AI Regulation). This is in line with UN Regulation No. 155 on cybersecurity in vehicles, which also aims at setting up this ‘first line of defence’. The AI Regulation, thereby, also contributes to the first identified principle on preventing unauthorised access to the vehicle’s system. The proposed AI Regulation continues:

[t]he technical solutions aimed at ensuring the cybersecurity of high-risk AI systems shall be appropriate to the relevant circumstances and the risks. The technical solutions to address AI specific vulnerabilities shall include, where appropriate, measures to prevent and control for attacks trying to manipulate the training dataset (“data poisoning”), inputs designed to cause the model to make a mistake (“adversarial examples”), or model flaws. (art. 15(4) AI Regulation)

If the AI Regulation would come into effect, its influence on vehicles’ cybersecurity will be felt through any new measures introduced in the EU Type-approval Regulation and the General Safety Regulation. This makes the AI Regulation a potential important factor on cybersecurity (and more) in the automotive field. In particular, the first and last principle on cybersecurity on vehicles identified here, are served by the proposed AI Regulation.

7. Conclusion

Important steps towards a legal framework for cybersecurity in vehicles are being made. These steps all contribute to the key principles for cybersecurity as identified in this contribution, but the fragmented approach does lead to concerns. In , the findings of this research are summarised, showing how the legal instruments discussed contribute to each of the key principles.

Table 2. An overview of the identified principles of cybersecurity in vehicles and the contributions of each of the legislative instruments discussed.

At first glance, it immediately becomes clear that the first principle on preventing unauthorised access is widely supported by almost all of the legislative acts discussed. From technical requirements to incentives from liability law – the prevention of gaining unauthorised access seems to be, rightfully so, a priority of legislators and standard organisations alike.

This is in contrast to the second principle, on the limitation of damage once unauthorised access has been acquired. The main support for this principle seems to come from the (non-binding) industry standards. Although the standard organisations behind these industry standards are well placed for developing technically intricate requirements, legislators should step in as the stakes are simply too high. It would be irresponsible to assume no hacker will ever gain unauthorised access to the vehicle’s system and disrupt society (i.e. terrorist attack). So, it is to the concern of society as a whole that the damage that can be done once access is gained is limited as much as possible. This will require numerous layers of security measures (a security onion, as it were) to make it as difficult as possible for a hacker to gain control over safety-critical features of the vehicle. Cooperation between legislators and experts from the automotive sector will be vital in setting requirements that are both technically feasible from a vehicle producer’s perspective and would raise the bar high enough to stop hackers from trying to make their way through the layers of security measures. Legal requirements are, other than the current standards, legally binding and thus enforceable. Thereby, a minimum level of vehicle cybersecurity would be guaranteed throughout the entire vehicle fleet on public roads, increasing road safety as well.

Part of these legal requirements could also be the restoration of the state of cybersecurity after an incident (principle 3). At the moment, this is a principle that is barely supported by legislation, even though it is crucial in keeping public roads safe. Once a vulnerability has been discovered, this vulnerability should be patched by, for instance, a software update. This is not just a matter of consumer protection. It is a core part of vehicle security and thus of road safety. Therefore, the restoration of the state of cybersecurity should make its way into vehicle safety regulation and the accompanying mechanisms of the type-approval process. This would further embed cyber resilience in the vehicle safety requirements.

Principles 4 and 5 – compensation for injured party and legal consequences for a hacker – are both supported by traditional, non-vehicle related, legislative instruments. This does not have to be a problem: liability law as well as criminal law are fields that have both proven to be able to cope with new technical developments. It is essential, though, that these existing laws are frequently reviewed so as to identify and address any legal gaps in time. This also holds true for the Motor Insurance Directive.

Lastly, principle 6 sees to upholding cybersecurity during a vehicle’s entire lifetime. This would require the continuously monitoring of the vehicle’s state of security, as well as frequent updates to patch (newly discovered) vulnerabilities. This is supported by art. 15(1) of the proposed EU AI Regulation. The task of the vehicle approval authority will shift in order to ensure the enforcement of the sixth principle: not only will the approval authority approve vehicles for use on public roads, but it will also have to monitor those vehicles throughout their lifetime. If the state of cybersecurity is deemed insufficient, the approval authority can withdraw the type approval. Consequently, approval authorities will have to develop processes to routinely monitor vehicles’ cybersecurity well past the initial phase of approval.

Overall, important steps towards a legal framework for cybersecurity in vehicles are being made. Nevertheless, the level of fragmentation in the cybersecurity legal framework is in itself worrying, leading to legal uncertainty of the parties involved. This fragmentation risks principles not being dealt with adequately, such as the second principle identified here on damage limitation. A patchwork legal framework can also lead to different levels of cybersecurity in different vehicles. Not just traditional vehicle legislation attributes to a cybersecurity framework for vehicles; EU Regulation and Directives from a consumer protection perspective also contribute to the realisation of the cybersecurity principles identified in this contribution. It should be ensured, however, that non-consumer vehicles are at least just as ‘cybersecure’ as their counterparts for the consumer market. To ensure the realisation of the vehicle cybersecurity principles in all vehicles, more and better coordinated legislative steps are necessary. This requires the cooperation between lawyers, cybersecurity experts and other parties.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Funding

This research is part of the Cybersecurity Noord Nederland project.

References

  • Andraško, J., M. Mesarčík, and O. Hamuľák. 2021. “The Regulatory Intersections Between Artificial Intelligence, Data Protection and Cyber Security: Challenges and Opportunities for the EU Legal Framework.” AI & Society 36: 623–636.
  • Banasinski, C., and M. Rojszczak. 2021. “Cybersecurity of Consumer Products Against the Background of the EU Model of Cyberspace Protection.” Journal of Cybersecurity 7 (1): 1–15.
  • Coole, M., J. Corkill, and A. Woodward. 2012. “Defence in Depth, Protection in Depth and Security in Depth: A Comparative Analysis Towards a Common Usage Language.” 5th Australian Security and Intelligence Conference, Novotel Langley Hotel, Perth, Western Australia, December 3–5, 2012.
  • Craigen, D., N. Diakun-Thibault, and R. Purse. 2014. “Defining Cybersecurity.” Technology Innovation Management Review 4: 10.
  • ENISA and JRC. 2021. Cybersecurity Challenges in the Uptake of Artificial Intelligence in Autonomous Driving. Luxemburg: European Union.
  • European Commission. 2020a. Report from the Commission to the European Parliament, the Council and the European Economic and Social Committee: Report on the safety and liability implications of Artificial Intelligence, the Internet of Things and robotics (Brussels, 19.2.2020 COM(2020) 64 Final).
  • European Commission. 2020b. Proposal for a Directive of the European Parliament and of the Council on Measures for a High Common Level of Cybersecurity Across the Union, Repealing Directive (EU) 2016/1148 (Brussels, 16.12.2020 COM(2020) 823 Final).
  • European Commission. 2020c. Proposal for a Directive of the European Parliament and of the Council on the Resilience of Critical Entities (Brussels, 16.12.2020 COM(2020) 829 final). https://ec.europa.eu/home-affairs/sites/default/files/pdf/15122020_proposal_directive_resilience_critical_entities_annex-1_com-2020-829-1_en.pdf.
  • European Commission. 2021. Proposal for a Regulation of the European Parliament and of the Council on General Product Safety, Amending Regulation (EU) No 1025/2012 of the European Parliament and of the Council, and repealing Council Directive 87/357/EEC and Directive 2001/95/EC of the European Parliament and of the Council (Brussels, 30.6.2021 COM(2021) 346 Final).
  • Fosch-Villaronga, E., and T. Mahler. 2021. “Cybersecurity, Safety and Robots: Strengthening the Link Between Cybersecurity and Safety in the Context of Care Robots.” Computer Law and Security Review 41: 1–13.
  • Förster, C. 2021. “BGB § 823 Schadensersatzpflicht.” In BeckOK BGB Hau/Poseck. 58th ed. Beck online.
  • Fuster, G. G., and L. Jasmontaite. 2020. “Cybersecurity Regulation in the European Union: The Digital, the Critical and Fundamental Rights.” In The Ethics of Cybersecurity: The International Library of Ethics, Law and Technology, vol. 21, edited by M. Christen, B. Gordijn, and M. Loi, 97–115. Springer.
  • Kohler, C. 2020. “The EU Cybersecurity Act and European Standards: An Introduction to the Role of European Standardization.” International Cybersecurity Law Review 1: 7–12.
  • Malik, S., and W. Sun. 2020. “Analysis and Simulation of Cyber Attacks Against Connected and Autonomous Vehicles.” In Proceedings of the 2020 International Conference on Connected and Autonomous Driving (MetroCAD).
  • Markopoulou, D., V. Papakonstantinou, and P. de Hert. 2019. “The New EU Cybersecurity Framework: The NIS Directive, ENISA's Role and the General Data Protection Regulation.” Computer Law and Security Review 35 (6): 1–11.
  • Mills, K. 2021. “PAVE’s Virtual Panel ‘AVs at Work: National Security’,” June 16. https://youtu.be/YuQpF5UuhBA.
  • Morais Carvalho, J. 2019. “Sale of Goods and Supply of Digital Content and Digital Services – Overview of Directives 2019/770 and 2019/771.” Journal of European Consumer and Market Law 8: 194–201.
  • Möller, D. P. F., and R. E. Haas. 2019. Guide to Automotive Connectivity and Cybersecurity: Trends, Technologies, Innovations and Applications. Cham: Springer.
  • Oxford English Dictionary. Online. www.oed.com/.
  • Reichenbach, M. 2015. “Onion Model.” ATZ Worldwide 117: 3.
  • SAE. 2021. “ISO/SAE 21434 Road Vehicles — Cybersecurity Engineering.” https://www.iso.org/standard/70918.html.
  • Schmittner, C., and G. Macher. 2019. “Automotive Cybersecurity Standards – Relation and Overview.” In Computer Safety, Reliability, and Security. SAFECOMP 2019. Lecture Notes in Computer Science, vol. 11699, edited by A. Romanovsky, E. Troubitsyna, I. Gashi, E. Schoitsch, and F. Bitsch, 153–165. Springer.
  • Taeihagh, A., and H. Si Min Lim. 2019. “Governing Autonomous Vehicles: Emerging Responses for Safety, Liability, Privacy, Cybersecurity, and Industry Risks.” Transport Reviews 39 (1): 103–128.
  • Vellinga, N. E. 2020. “Legal Aspects of Automated Driving: On Drivers, Producers, and Public Authorities.” Diss., University of Groningen. doi:https://doi.org/10.33612/diss.112916838.